GitHub ha incorporado a GitHub Copilot una capa experimental capaz de construir flujos de ejecución con modelos de distintos proveedores, en lugar de limitarse a elegir uno para cada petición. Project HydraFusion decide en tiempo de ejecución si una tarea puede resolverse directamente, necesita escalarse a un modelo más potente o se beneficiará de una revisión independiente. El cambio importa porque traslada al asistente parte de la complejidad técnica y económica que supone trabajar con varios modelos de inteligencia artificial.
La propuesta amplía el enrutamiento automático que Copilot ya utilizaba para asignar un modelo según las características de la solicitud. HydraFusion planifica el proceso completo: selecciona los modelos, define qué función cumplirá cada uno y limita las llamadas adicionales a los casos en los que estima que mejorarán el resultado. Su objetivo es equilibrar calidad, coste y latencia sin obligar al desarrollador a coordinar manualmente las distintas herramientas.
La vista previa de investigación está disponible desde el 4 de septiembre de 2026 para usuarios de todos los planes de Copilot mediante las funciones experimentales de GitHub Copilot CLI. El consumo se factura según los tokens utilizados y la tarifa estándar de cada modelo que interviene. Esta fórmula hace que la decisión de enrutamiento tenga una consecuencia económica directa: una revisión, un reintento o un escalado añaden llamadas que deben contabilizarse.
De seleccionar un modelo a diseñar el flujo
HydraFusion puede aplicar tres patrones. En el más sencillo, un único modelo resuelve la tarea. En una cascada, un modelo eficiente prepara una solución y una puerta de control determina si puede aceptarse o debe pasar a otro con mayor capacidad. En el patrón de crítica, un modelo redacta el resultado, otro perteneciente a una familia diferente lo revisa sin capacidad para modificar el repositorio y el primero realiza una revisión final.
El sistema utiliza señales relacionadas con el razonamiento, la generación de código, la depuración y el uso de herramientas para escoger el flujo menos complejo que espera que alcance el nivel de calidad requerido. La selectividad es central en el planteamiento: una tarea ordinaria puede completarse con una sola ejecución, mientras que un cambio más difícil puede justificar una segunda valoración o el acceso a un modelo más costoso.
Esta evolución se apoya en una infraestructura ya desplegada. GitHub generalizó en junio de 2026 el modo automático de Copilot Chat, que escoge un modelo según la complejidad de la petición y su disponibilidad. En julio, la empresa extendió a Copilot CLI el enrutamiento basado en la tarea, la fiabilidad y las necesidades de herramientas. HydraFusion convierte esa selección individual en una planificación compuesta.
GitHub asegura que su modo automático procesó más de 9.000 millones de solicitudes durante junio y que más de la mitad de los usuarios de pago de Copilot permitieron que el sistema escogiera el modelo. Esas cifras reflejan la adopción del enrutamiento, aunque no permiten anticipar cuántas tareas necesitarán flujos multimodelo. La vista previa servirá precisamente para observar ese comportamiento fuera de las pruebas controladas.
Menor coste en las pruebas, con diferencias según la tarea
La mejor configuración evaluada de HydraFusion mejoró en 4,9 puntos porcentuales la calidad verificada en TerminalBench 2.1 y redujo un 67% el coste estimado frente a Claude Opus 5. Este banco de pruebas mide agentes de programación ante tareas complejas y de varios pasos ejecutadas en entornos de terminal. El resultado respalda la posibilidad de combinar modelos más eficientes con escalados selectivos, aunque se limita a la configuración analizada.
La ventaja en calidad no se repitió en los otros dos bancos utilizados. En DeepSWE, centrado en tareas de ingeniería sobre repositorios amplios, HydraFusion quedó 1,5 puntos por debajo de Opus 5, con un coste un 36% menor. En CheckpointBench, un benchmark interno construido a partir de sesiones reales de Copilot, la diferencia fue de 0,1 puntos menos y el ahorro estimado alcanzó el 65%.
Las evaluaciones fueron pruebas offline controladas, con los mismos datos de entrada, herramientas, límites de ejecución, hipótesis de precios y condiciones de calificación para cada alternativa. La contabilidad incluyó todas las fases invocadas, desde la redacción y la crítica hasta las revisiones, escalados, reintentos y mecanismos de respaldo. Esta medición evita presentar como coste del flujo únicamente la llamada que entrega la respuesta final.
Los porcentajes, sin embargo, dependen de las versiones de los benchmarks, el conjunto de modelos disponible, las políticas de enrutamiento y los precios asumidos. También corresponden a la mejor configuración ajustada por GitHub. La empresa quiere comprobar ahora cómo se trasladan a cargas reales, donde influyen la duración de las sesiones, la variedad de los repositorios, la latencia percibida y la necesidad de mantener el contexto durante varias interacciones.
Control del repositorio y visibilidad para el desarrollador
La orquestación añade exigencias que no aparecen cuando un único modelo ejecuta toda la tarea. HydraFusion registra el papel, el resultado, el coste, la latencia y los diagnósticos de cada fase. También establece tiempos máximos y mecanismos de cancelación, valida antes de empezar la disponibilidad de los modelos y sus alternativas de respaldo, y evita aplicar cambios cuando el flujo se cancela o no supera la validación.
Las revisiones se realizan en contextos aislados y sin herramientas, de modo que el modelo crítico pueda evaluar el trabajo sin modificar el repositorio. Las fases encargadas de resolver la tarea sí operan sobre el espacio compartido y mantienen el sistema habitual de permisos. Al finalizar, el desarrollador recibe una respuesta coherente y un único conjunto de cambios, aunque internamente hayan intervenido varios modelos y pasos.
Ese diseño reduce la exposición de borradores incompletos, pero también limita la visibilidad durante la ejecución. La versión actual muestra las etapas del flujo y retiene los resultados intermedios hasta completar el proceso. GitHub reconoce que la espera con información limitada puede afectar a la experiencia y utilizará la prueba para estudiar formas más útiles de comunicar el progreso sin presentar como definitivo un código que aún puede descartarse.
La compañía recomienda comenzar con tareas sustanciales, bien delimitadas y planteadas en una sola instrucción, mientras trabaja en sesiones iterativas más largas. Para los equipos técnicos, la utilidad de la orquestación multimodelo dependerá de que el ahorro observado compense las llamadas adicionales y de que la planificación mantenga tiempos y cambios bajo control. La vista previa permite medir esa relación en repositorios reales antes de convertirla en una capacidad estable de Copilot.
