La cifra más interesante del último experimento de Copilot de GitHub no es una puntuación de calidad, sino una factura: un 67% menos en un banco de pruebas exigente de terminal, y con 4,9 puntos porcentuales más de acierto que Claude Opus 5. Ese es el resultado destacado que GitHub ha publicado sobre Project HydraFusion, una vista previa de investigación que dejó de preguntarse qué modelo debía resolver una tarea de programación y empezó a preguntarse cuántos deben intervenir, y en qué orden.
Claves del anuncio
- HydraFusion superó en 4,9 puntos porcentuales la referencia de Claude Opus 5 en TerminalBench 2.1 con un coste estimado un 67% menor, y la igualó prácticamente en otras dos baterías con un 36% y un 65% menos.
- En lugar de derivar la petición a un solo modelo, arma un plan por solicitud que puede redactar, escalar o incorporar a un crítico de solo lectura procedente de una familia de modelos rival.
- Cualquier plan de Copilot puede activarlo desde la CLI de Copilot, sin pagar nada más allá de la tarifa habitual por tokens de los modelos que el plan acabe invocando.
Por qué la línea del coste pesa más que la de la calidad
La programación con agentes arrastra un problema económico que las tablas de benchmarks suelen tapar. Los equipos que entregan tareas largas y cargadas de herramientas a un modelo de frontera pagan precios de frontera en cada tramo del bucle, incluidos los tramos que un modelo más barato habría resuelto igual de bien. HydraFusion es el intento de GitHub de tarificar cada tramo por separado.
Las pruebas publicadas proceden de ejecuciones sin conexión sobre tres baterías agénticas, con Opus 5 y GPT-5.6 Sol como referencias y todos los modelos fijados en razonamiento medio. Dos de los tres resultados son en esencia el mismo rendimiento a menor precio: DeepSWE, que exige trabajo transversal en el repositorio, quedó a menos de 1,5 puntos de Opus 5 con un 36% menos de gasto, y CheckpointBench se situó a 0,1 puntos con un 65% menos. Solo TerminalBench 2.1 arrojó una mejora neta de calidad, y GitHub apunta que esa batería está comparativamente saturada, que es parte del motivo por el que ejecutó las otras dos.
CheckpointBench merece una segunda mirada porque es de cosecha propia. La compañía la construyó a partir de trayectorias reales de sesiones de Copilot, anclando cada conversación a un repositorio público en un commit inmutable para poder reproducir la ejecución, y después la equilibró por lenguajes, tipos de tarea y dificultad. Se acerca más al tráfico de producción que una tabla de clasificación pública y, a la vez, resulta imposible de auditar desde fuera de GitHub.
El registro de desarrollo incluye una nota al pie inusualmente franca: entre el 11 y el 25 de agosto, dos fallos operativos en el entorno de evaluación produjeron ejecuciones inválidas que se descartaron antes de trazar la línea de tendencia.
Cómo un solo prompt se convierte en un plan multimodelo
HydraFusion lee señales de capacidad —profundidad de razonamiento, generación de código, depuración y uso de herramientas— y elige la más barata de las tres formas con las que cree que superará el listón. Puede que un único modelo responda sin más. O que un modelo rápido redacte y una compuerta de calidad decida si ese borrador se entrega o se escala a algo más potente. O, en el patrón que GitHub compara con la revisión del patito de goma, un redactor produce un artefacto, un crítico de una familia de modelos distinta lo lee sin ninguna herramienta acoplada y el redactor recibe exactamente una revisión estructurada para responder.
Esos umbrales no se fijaron a mano. GitHub ejecutó una búsqueda en haz sobre las puntuaciones por capacidad frente a una referencia congelada, ajustando las tres baterías a la vez en lugar de perseguir una sola: una decisión que importa cuando el benchmark del titular es precisamente el saturado.
Hasta ahora, la capacidad de razonamiento y de resolución de tareas [de HydraFusion] está a la altura de Opus o por encima.
El veredicto procede de un ingeniero de software principal de Microsoft que probó el sistema internamente.
Lo que GitHub tuvo que blindar primero
Apuntar varios modelos a un mismo árbol de trabajo abre modos de fallo que un bucle de un solo modelo nunca tiene: un revisor que edita el código que debía juzgar, una ejecución cancelada que deja un parche a medio aplicar, una factura que nadie sabe imputar porque se repartió entre seis tramos. La respuesta de GitHub es un conjunto de restricciones duras: los críticos se ejecutan sin herramientas y no pueden escribir; los parches se descartan por completo, y no se aplican parcialmente, cuando media una validación fallida o una cancelación; cada tramo lleva un tiempo límite y un mecanismo de cancelación; los enlaces a los modelos se verifican antes de ejecutar nada; y el gasto en tokens se agrega entre redacción, crítica, revisión, escalado, reintento y repliegue, de modo que todo el flujo queda asociado a una única cifra.
Cómo activarlo y qué sigue sin poder hacer
El acceso pasa por la CLI de Copilot: actualiza el cliente, habilita la opción experimental y HydraFusion aparece en el selector de modelos. La salvedad es que una tarea que escale dos veces o dispare una pasada de crítica costará más que la misma tarea resuelta de una tacada, porque la facturación sigue a los modelos realmente invocados.
GitHub está orientando a los primeros usuarios hacia trabajos grandes, bien acotados y de un solo prompt, y señala que las sesiones iterativas largas son el próximo objetivo de ingeniería. Reconoce de entrada una aspereza: la vista previa retiene los borradores intermedios hasta tener una respuesta coherente, con el argumento de que el trabajo descartado no debería parecer terminado, lo que en la práctica se traduce en mirar un indicador de progreso sin saber apenas qué está ocurriendo. Los comentarios se recogen en el hilo de la comunidad de Copilot.
Perspectivas
Conviene tomar las cifras como una hipótesis y no como un resultado. Son de ejecuciones sin conexión, atadas a un conjunto concreto de modelos y a unos supuestos de precios, y la vista previa existe precisamente para averiguar si se sostienen cuando desarrolladores reales le lanzan trabajo desordenado. Si aguantan, la pregunta competitiva se desplaza de quién tiene el modelo más potente a quién reparte mejor el trabajo, un giro que favorece bastante más a un proveedor de plataforma con acceso a muchos suministradores que a cualquier laboratorio por separado. Además llega mientras GitHub absorbe un aumento de volumen impulsado por agentes en su propia infraestructura, algo que tratamos en nuestro informe sobre el crecimiento de commits de la plataforma.
Preguntas frecuentes
¿Project HydraFusion está disponible fuera de la CLI de GitHub Copilot?
Todavía no. Solo se distribuye dentro de la CLI de Copilot, tras activar la configuración experimental. GitHub no ha dado plazos para llevarlo a las extensiones del IDE o a la aplicación de Copilot.
¿Supone un coste adicional sobre la suscripción de Copilot?
No hay cargo aparte. Se paga la tarifa habitual de tokens por cada modelo que el flujo invoque, de modo que el precio de una tarea varía según cuántos tramos necesite para completarse.
¿Qué modelos utiliza HydraFusion?
GitHub no ha revelado el conjunto y se limita a describirlo como repartido entre varios proveedores, además de indicar que el crítico procede deliberadamente de una familia distinta a la del redactor. Opus 5 y GPT-5.6 Sol sirvieron como referencias de evaluación, no necesariamente como integrantes del conjunto.
