GitHub anunció el 4 de septiembre de 2026 Project HydraFusion, un proyecto disponible como vista previa de investigación dentro de GitHub Copilot para coordinar modelos de inteligencia artificial de varios proveedores durante la ejecución de tareas de programación. En lugar de seleccionar previamente un solo modelo, HydraFusion crea un plan de ejecución y determina si la tarea requiere una solución directa, una revisión independiente o una escalada a un modelo más capaz.
El paso llega después de la función Auto model selection, que GitHub lanzó a principios de año para elegir el modelo más adecuado para cada tarea. Sin embargo, HydraFusion amplía la idea: pasa de seleccionar un modelo a construir un flujo de trabajo completo que equilibra la calidad del resultado, el costo y el tiempo de respuesta, mientras mantiene oculta la complejidad operativa para el desarrollador, que elige HydraFusion como elegiría cualquier otro modelo en Copilot.
Tres rutas para ejecutar la tarea
El sistema evalúa señales relacionadas con el razonamiento, la generación de código, la depuración y el uso de herramientas, y después selecciona uno de tres modos de ejecución:
- Single: un solo modelo se encarga de resolver directamente la tarea cuando su capacidad es suficiente.
- Cascade: un modelo más eficiente comienza redactando la solución; después, una puerta de calidad decide si se acepta o si la tarea se deriva a un modelo más potente.
- Critique: un modelo redacta una solución inicial; después, un modelo independiente de una familia diferente la revisa en un contexto de solo lectura, antes de que el primer modelo realice una única revisión de la solución.
GitHub afirma que el objetivo de la selección es utilizar llamadas adicionales solo cuando se prevea que mejorarán el resultado. De este modo, la ruta directa conserva la velocidad y la eficiencia, mientras que las otras dos añaden revisión o escalada para las tareas que se benefician de ellas.
Lo que mostraron las pruebas
GitHub evaluó políticas fijas de HydraFusion en tres pruebas para agentes de programación: TerminalBench 2.1, DeepSWE y el CheckpointBench interno, basado en sesiones reales de GitHub Copilot. Los resultados se compararon con dos líneas base: Claude Opus 5 y GPT-5.6 Sol, utilizando entradas, herramientas, límites de ejecución, supuestos de precios y condiciones de evaluación idénticos.
En TerminalBench 2.1, HydraFusion logró una mejora de 4,9 puntos porcentuales en la calidad de las tareas verificadas, con una reducción del costo estimado del flujo de trabajo del 67 % frente a Claude Opus 5. En DeepSWE, que se centra en tareas de ingeniería de software a nivel de repositorio y en la comprensión de las dependencias entre archivos, el sistema quedó cerca de Opus 5, con una diferencia de 1,5 puntos porcentuales y un costo un 36 % menor. En cuanto a CheckpointBench, la diferencia de calidad fue de solo 0,1 puntos porcentuales, frente a una reducción del costo del 65 %.
El cálculo del costo incluye todas las etapas de ejecución, entre ellas la redacción, la revisión, la modificación, la escalada, los reintentos y los planes de reversión. No obstante, GitHub describe estos resultados como pruebas sin conexión, limitadas por las versiones de las pruebas, la configuración de los flujos de trabajo, el conjunto de modelos y los supuestos de precios utilizados.
Controles de operación y límites de la vista previa
GitHub diseñó HydraFusion con controles que incluyen el registro del costo y el uso de cada etapa, la definición de tiempos de espera para la cancelación y la ejecución, y el aislamiento de los pasos de revisión en contextos que no tienen herramientas ni modifican el repositorio. El sistema también verifica previamente las definiciones de los flujos de trabajo, la vinculación de modelos, el comportamiento de las alternativas y la disponibilidad de los modelos, y no aplica ninguna corrección si se cancela la operación o falla el proceso de verificación.
Actualmente, GitHub recomienda comenzar la prueba con tareas de programación grandes y bien definidas, enviadas en una sola solicitud a Copilot en modo automático. Más adelante, la empresa se centrará en mejorar el rendimiento de las sesiones de varios turnos y de mayor duración. También advierte que los modelos, los flujos de trabajo, los nombres, la disponibilidad y el comportamiento del producto pueden cambiar durante el periodo de vista previa.
Lectura editorial: del modelo elegido al diseño del flujo de trabajo
El cambio más importante no es la incorporación de un nuevo modelo, sino el traslado de la decisión de ejecución del desarrollador a una capa de coordinación que decide cuándo basta con un solo intento y cuándo la tarea merece el costo de una revisión o una escalada. Si los resultados de las pruebas se reflejan en el uso real, esto podría proporcionar a los desarrolladores una calidad cercana a la de los modelos más potentes en algunas tareas sin pagar su costo en cada solicitud.
Sin embargo, las cifras todavía no demuestran una superioridad general en todos los patrones de programación; están vinculadas a pruebas específicas, políticas controladas y resultados sin conexión. Siguen abiertas las preguntas sobre el tiempo de respuesta, la fiabilidad, el comportamiento del sistema en sesiones largas, la eficiencia de la caché y la seguridad, aspectos que GitHub afirma que medirá durante la vista previa.