GitHub prueba HydraFusion: enrutado multi-modelo para Copilot y menos coste
El research preview deja de elegir un modelo estático y monta planes de ejecución en tiempo real combinando proveedores. GitHub dice que baja el coste hasta un 67% sin perder calidad.
GitHub ha presentado Project HydraFusion, un research preview para Copilot que abandona la idea de un modelo único estático y construye planes de ejecución en tiempo real combinando modelos de varios proveedores. La premisa es tratar cada workflow como un problema de optimización: enrutar según lo que pida la tarea, no según una tabla fija.
El sistema clasifica el prompt con señales de capacidad pensadas para operaciones complejas —razonamiento en varios pasos, generación automática de código, depuración estructurada, uso avanzado de herramientas— y con eso decide entre tres patrones de ejecución.
Tres formas de resolver una petición
En el patrón Single, un modelo elegido ejecuta directamente cuando le da para resolver la tarea solo; se prioriza latencia. En Cascade, un modelo eficiente genera un borrador, una puerta de calidad lo evalúa y, si no cumple, la tarea escala a uno más capaz. En Critique, un modelo redacta, otro de una familia distinta y sin acceso a herramientas lo revisa en modo lectura, y el redactor hace una única revisión estructurada a partir de ese informe. Es el patrón rubber duck pasado a la orquestación.
Por debajo, cinco principios operativos: contabilidad completa de tokens por cada tramo (borrador, crítica, revisión, escalado, reintento y fallback), ejecución acotada con timeouts y cancelación, revisión aislada sin herramientas, rutinas fail-safe que rechazan el parche si falla la validación o se cancela la ejecución, y enrutado validado que comprueba disponibilidad y bindings antes de arrancar.
Los números y el asterisco
Las métricas salen de evaluaciones offline controladas y son de GitHub, no de un tercero. En TerminalBench 2.1, HydraFusion mejora la calidad verificada en 4,9 puntos porcentuales y recorta el coste estimado un 67% frente a Claude Opus 5. En CheckpointBench, un benchmark interno multi-turno construido con sesiones reales de Copilot ancladas a repositorios públicos y commits inmutables, la puntuación media queda prácticamente empatada con ese mismo baseline: 0,1 puntos porcentuales de diferencia, con un 65% menos de coste.
Que el benchmark sea interno importa. Un empate a 0,1 puntos contra un modelo concreto lo dice todo y nada a la vez: sin el detalle de cómo se puntúa cada sesión ni un conjunto de evaluación externo, la cifra hay que tomarla como lo que es, una medición propia sobre un terreno que también es propio.
Cómo probarlo
El preview está abierto a todos los niveles de Copilot desde el CLI. Hay que actualizar el entorno, ejecutar /experimental on y elegir HydraFusion en la interfaz de selección de /model.
El consumo se factura a las tarifas estándar de tokens de los modelos que se invoquen en cada ejecución, así que el ahorro no viene de un precio distinto sino de invocar modelos más baratos cuando la tarea no necesita el caro.
Ahí está lo interesante para quien opera esto: el coste por token deja de ser el único eje de decisión y aparece el coste por tarea resuelta, con la contabilidad por tramo como requisito para poder auditarlo. Lo que falta por ver es si el ahorro aguanta fuera de los benchmarks internos y con cargas reales, donde la distribución de tareas no la elige quien mide.
