GitHub lanza Project HydraFusion, una vista previa que reparte cada tarea de código entre varios modelos de IA

GitHub anunció Project HydraFusion, una vista previa de investigación que reparte cada tarea de programación entre varios modelos de inteligencia artificial en lugar de resolverla con uno solo, y que ya está disponible para todos los planes de GitHub Copilot a través del comando /experimental en GitHub Copilot CLI. Según el anuncio publicado por la empresa en su blog oficial, el desarrollador elige HydraFusion como elegiría cualquier otro modelo y el sistema se encarga del resto: arma un plan de ejecución, convoca modelos de distintos proveedores para redactar, criticar y revisar, o escala a uno más potente cuando el primer intento no alcanza. Para probarlo hay que ejecutar /update, después /experimental on y luego /model, y seleccionar 'HydraFusion (Research Preview)'. El uso se factura según los tokens que consuman los modelos que intervienen, al precio estándar de cada uno, y las devoluciones se reciben en la discusión abierta en GitHub Community.

Detrás de la decisión hay un objetivo que GitHub viene sosteniendo desde antes: darle al desarrollador el mejor modelo para la tarea que tiene enfrente. A comienzos de este año la compañía había lanzado Auto model selection, que revisa el pedido y lo empareja con el modelo más adecuado; HydraFusion, dice el anuncio, ocupa un lugar central en la estrategia de enrutamiento semántico automático entre modelos locales, en la nube y compuestos. La idea de fondo es que la coordinación de modelos ya existe, pero la hace el programador a mano: elige uno para resolver, le pide a otro que revise el trabajo o escala un problema difícil a un modelo más capaz. Lo que cambia ahora es que ese proceso pasa al runtime. El texto detalla tres patrones de ejecución que el sistema elige según el caso. En 'Single', un único modelo resuelve la tarea directamente, lo que preserva velocidad y eficiencia. En 'Cascade', un modelo eficiente hace el primer intento y una compuerta de calidad decide si acepta el resultado o escala a uno más fuerte. En 'Critique', un modelo redacta, un crítico independiente de otra familia de modelos revisa el trabajo en un contexto aislado y sin herramientas —con el mismo patrón de revisión que GitHub usa en Rubber Duck— y el modelo redactor hace una única corrección. La compañía sostiene que recurre a llamadas adicionales solo cuando es probable que mejoren el resultado, y que así equilibra calidad, costo y latencia.

El desarrollo se apoyó en tres conjuntos de prueba de programación con agentes: TerminalBench 2.1, DeepSWE y CheckpointBench, este último un benchmark interno construido por GitHub a partir de sesiones reales de Copilot. Cada conversación de CheckpointBench está anclada a un repositorio público y a un commit inmutable para que la sesión pueda reproducirse, y el conjunto está balanceado por lenguaje, tipo de tarea y dificultad: de las 276 tareas, 116 son de nivel fácil, 107 medio y 53 difícil, según los datos que acompañan al anuncio. Para afinar las políticas de enrutamiento, el equipo dice haberse apoyado en las puntuaciones por capacidad como base de comparación y en una búsqueda de haz (beam search) en lugar del ajuste manual de umbrales, midiendo cada candidato contra una línea de base congelada en calidad, costo y modos de falla. El recorrido, admite el propio anuncio, no fue lineal: entre el 11 y el 25 de agosto dos fallas operativas del sistema de evaluación produjeron corridas inválidas —una de ellas, el 11 de agosto, terminó con 0 de 89 tareas resueltas y errores del agente en las 89—, que fueron excluidas de la tendencia de rendimiento, corregidas y seguidas por nuevas mejoras. Para el 25 de agosto, la compañía afirma que HydraFusion había alcanzado sus mejores puntos operativos de la serie registrada.

Las mediciones que GitHub publica apuntan a un mismo eje: sostener la calidad y bajar el costo. En TerminalBench 2.1 reporta una mejora de 4,9 puntos porcentuales en calidad verificada de tareas con un costo estimado 67% menor frente a Claude Opus 5; en DeepSWE, 36% menos costo con una diferencia de -1,5 puntos; y en CheckpointBench, 65% menos costo con -0,1 puntos. Son resultados de evaluaciones offline, aclara la empresa, específicos de las revisiones de benchmark, configuraciones de flujo, conjunto de modelos y supuestos de precios evaluados, con todos los modelos corridos en el mismo nivel medio de razonamiento. Se trata, además, de cifras que la propia compañía mide sobre su propio producto y que no cuentan con verificación independiente. De esas cifras se desprende también el límite del anuncio. La vista previa está pensada, por ahora, para tareas de programación de un solo turno y un solo pedido: GitHub dice que el foco en el rendimiento multi-turno, con sesiones más largas e iterativas, viene después. La compañía advierte que HydraFusion sigue siendo un esfuerzo de investigación activo y que los resultados, modelos, flujos de trabajo, disponibilidad, nombres y comportamiento del producto pueden cambiar a medida que aprenda de la vista previa. En el plano del uso, la facturación sigue el camino habitual: se paga por los tokens que consuman los modelos convocados, al precio estándar de cada uno.

El anuncio incluye una única declaración citada, atribuida a un 'Principal Software Engineer at Microsoft' al que la fuente no le pone nombre: 'Hasta ahora, la capacidad de razonamiento y de resolución de tareas [de HydraFusion] está a la par o mejor que Opus'. El texto también está firmado por Aashna Garg (Principal Applied Scientist, Code AI), Shengyu Fu (Partner Applied Science Manager, Code AI), Carlos Castro (Partner Architect, GitHub Copilot), Siddharth Singha Roy (Research Scientist II, Code AI) y Andy Salerno (Principal Software Engineer, GitHub Copilot), y cierra con agradecimientos a los equipos de GitHub y Microsoft que trabajaron en la vista previa, incluidos los de GitHub Copilot CLI, Copilot API y VS Code.