AIREITERUna tarea de programación puede parecer sencilla hasta que aparece una dependencia entre varios archivos. Project HydraFusion selecciona el flujo que, según sus cálculos, debería superar un umbral de calidad, pero la versión preliminar de investigación todavía oculta la ruta exacta y no garantiza el mismo ahorro en todos los repositorios.
La decisión de enrutamiento, de un vistazo
Project HydraFusion es una capa de orquestación en tiempo de ejecución integrada en GitHub Copilot CLI, no un nuevo modelo fundacional. Tú seleccionas HydraFusion (Research Preview) y el sistema decide qué modelos utilizar y cómo ejecutar la tarea.
| Flujo | Secuencia en tiempo de ejecución | Ventaja principal | Principal contrapartida |
|---|---|---|---|
| Single | Un único modelo seleccionado resuelve la tarea directamente. | Menor sobrecoste del flujo y la ruta de latencia más sencilla. | No incluye escalado ni revisión independiente. |
| Cascade | Un modelo eficiente prepara un borrador; un filtro de calidad acepta el resultado o lo escala a un modelo más potente. | Evita recurrir al modelo más potente cuando la primera pasada es suficiente. | Si el filtro falla, puede añadir llamadas al modelo, tokens y tiempo de espera. |
| Critique | Un modelo prepara el borrador; un crítico independiente de otra familia de modelos lo revisa en modo de solo lectura y el solucionador hace una revisión. | Aporta una segunda perspectiva para cambios propensos a errores. | Añade trabajo secuencial y el crítico no puede ejecutar herramientas ni editar el repositorio. |
Para probar la versión preliminar, ejecuta /update, después /experimental on y, por último, /model; selecciona HydraFusion (Research Preview). GitHub documenta esta secuencia en su anuncio oficial de HydraFusion. La versión preliminar está disponible en todos los planes de Copilot, aunque el acceso gestionado por una organización puede depender de la política de Copilot CLI activada por el administrador.
Estos son patrones de ejecución, no tres interruptores públicos para forzar manualmente una solicitud. El material de lanzamiento explica que hay que seleccionar HydraFusion y dejar que el sistema equilibre rendimiento, coste y latencia.
Qué intenta predecir el sistema
GitHub afirma que HydraFusion utiliza señales de capacidad relacionadas con el razonamiento, la generación de código, la depuración y el uso de herramientas. Elige el patrón de ejecución más eficiente que, según sus previsiones, alcanzará el umbral de calidad de la solicitud, pero GitHub no ha publicado los umbrales ni una regla determinista como «tres archivos significa Cascade».
Por tanto, el tipo de tarea sirve como orientación, no como garantía de enrutamiento: una edición acotada con una ruta de pruebas evidente encaja conceptualmente con Single; una solicitud potencialmente complicada, con la escalada selectiva de Cascade; y un cambio que se beneficie de una revisión independiente, con Critique. El anuncio no ofrece una lista fija de modelos para cada solicitud ni una traza legible de la ruta.
¿Puedes forzar Single, Cascade o Critique?
GitHub documenta la selección de HydraFusion y deja que el sistema escoja el flujo; no documenta ningún comando público para forzar uno de los tres patrones. Si necesitas un enrutamiento predecible, utiliza un modelo fijo de Copilot.
Cuándo compensa cada flujo su llamada adicional
Single: ejecución directa cuando la ruta está clara
Single envía la tarea a un único solucionador dentro del ciclo de agente habitual de Copilot, que respeta los permisos. Es adecuado para una edición pequeña y bien definida, una explicación breve o una corrección con una implementación y una ruta de pruebas claras.
Su ventaja es un perfil de coste y latencia más sencillo. El flujo no añade deliberadamente un filtro de calidad ni una segunda opinión, así que el desarrollador sigue siendo el revisor principal si el solucionador interpreta mal la tarea.
Cascade: escalar solo cuando la primera pasada no basta
Cascade comienza con un modelo eficiente. Un filtro de calidad evalúa el resultado y puede escalar la tarea a un modelo más potente si la propuesta no supera el umbral.
La lógica económica es condicional:
- El primer modelo se ocupa del trabajo que puede completar de forma adecuada.
- El filtro de calidad descarta las propuestas débiles o inciertas.
- Solo las tareas que necesitan más capacidad siguen la ruta del modelo más potente.
Esto puede reducir el coste medio del flujo frente a enviar todas las tareas a un modelo de frontera. Una escalada, un reintento o una ruta alternativa también pueden generar una cola más cara y lenta, y GitHub no ha publicado una tasa de escalada universal para la planificación específica de cada repositorio.
Critique: pagar por una segunda perspectiva
Critique funciona como un ciclo de borrador, revisión y corrección. El primer solucionador crea el resultado; un crítico de otra familia de modelos lo revisa en un contexto aislado, sin herramientas y de solo lectura; después, el solucionador original hace una revisión.
El crítico no puede ejecutar las pruebas del proyecto, inspeccionar un archivo generado mediante un comando ni aplicar una reparación por su cuenta. Critique aporta diversidad en la revisión, no una implementación independiente de principio a fin.
El balance de los benchmarks: menor coste no equivale a una única promesa de calidad
GitHub evaluó políticas fijas de HydraFusion frente a Claude Opus 5 en tres benchmarks de programación agéntica. Las siguientes cifras proceden del anuncio oficial de GitHub.
| Benchmark | Calidad de HydraFusion frente a Claude Opus 5 | Coste estimado del flujo frente a Claude Opus 5 | Lectura práctica |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 puntos porcentuales | 67% menos | Mayor calidad verificada de las tareas con un coste estimado inferior en esta evaluación. |
| DeepSWE | −1.5 puntos | 36% menos | Un ahorro relevante con una concesión de calidad medible en tareas difíciles de repositorio. |
| CheckpointBench | −0.1 puntos | 65% menos | Calidad prácticamente equivalente con un coste estimado sustancialmente menor. |
La mezcla de resultados de calidad es precisamente lo importante: HydraFusion pretende añadir inferencia cuando la mejora de calidad prevista justifica el coste y la latencia, no utilizar más modelos en todas las solicitudes.
GitHub afirma que la evaluación mantuvo constantes las entradas, las herramientas, los límites de ejecución, los precios y la evaluación, y que contabilizó las fases de borrador, crítica, revisión, escalada, reintento y ruta alternativa. Siguen siendo estimaciones controladas sin conexión, vinculadas a las políticas evaluadas, al conjunto de modelos, a las revisiones de los benchmarks y a los supuestos de precios.
Estas cifras no demuestran que una tarea normal de Copilot vaya a costar un 67% menos ni que HydraFusion vaya a superar a Claude Opus 5 en una base de código concreta. GitHub recomienda comenzar con tareas de programación sustanciales, bien acotadas y de primer turno que quepan en un único prompt mientras se prueba la versión preliminar con cargas de trabajo reales.
La ecuación del coste tiene tres partes
Al evaluar HydraFusion, separa el coste esperado de tokens, el coste de los casos extremos y el tiempo de espera.
| Factor | Single | Cascade | Critique |
|---|---|---|---|
| Trabajo inicial | Un solucionador | Primero, un solucionador eficiente | Primero, el solucionador que prepara el borrador |
| Trabajo adicional | Ninguno por diseño | Modelo más potente después de que falle el filtro | Crítico más una revisión del solucionador |
| Perfil de coste | Más predecible | Condicional; aumenta con una escalada o un reintento | Estructuralmente superior al de un borrador directo |
| Perfil de latencia | Ruta más sencilla | Corta si se acepta el resultado; más larga después de una escalada | La revisión y la corrección adicionales alargan la ruta |
| Mecanismo de calidad | Capacidad del solucionador | Filtro de calidad más escalada | Revisión independiente más corrección |
Un coste estimado del flujo más bajo no implica automáticamente una respuesta más rápida: Cascade puede ralentizar los casos escalados, Critique añade una revisión secuencial y Single responde antes, pero deja más validación en manos del desarrollador.
La documentación de uso de Copilot CLI de GitHub indica que /usage muestra la duración de la sesión, los créditos de IA consumidos, las líneas editadas y el desglose del uso de tokens por modelo. Estos datos ayudan a comparar tareas reales, pero no explican todas las decisiones de enrutamiento ni muestran los borradores intermedios descartados.
La caja negra entre el prompt y el parche
GitHub describe un registro completo de las distintas fases del flujo, una ejecución acotada con comportamiento de tiempo de espera y cancelación, revisiones aisladas, enrutamiento validado y aplicación segura del parche después de flujos inválidos o cancelados. Estos controles reducen el riesgo operativo, pero no demuestran que la ruta ni el código final sean correctos.
GitHub también afirma que la versión preliminar retiene los borradores intermedios hasta poder devolver un único resultado coherente. Esto dificulta saber si una tarea permaneció en Single, escaló mediante Cascade o pasó por Critique y una revisión.
Un usuario real señaló directamente esta carencia de observabilidad:
«La siguiente función del producto que me gustaría ver es una traza legible de qué modelo hizo cada cosa y por qué el enrutador cambió de modelo». — @_Mazzana en X
Sin un recibo de la ruta, los desarrolladores no pueden relacionar por completo el coste, la latencia y el parche final de una tarea con el flujo que los produjo.
Cómo usar la versión preliminar sin sacar conclusiones precipitadas
Trata HydraFusion como un experimento antes de convertirlo en la opción predeterminada del equipo:
- Crea una rama o un worktree limpio y anota el commit inicial.
- Prueba una corrección rutinaria, un cambio entre varios archivos y una tarea ambigua con una comprobación de aceptación reproducible.
- Incluye el comportamiento esperado, las restricciones y los comandos de prueba en el primer prompt.
- Inspecciona el diff final, comprueba que no haya cambios en archivos ajenos y ejecuta tú mismo las pruebas pertinentes.
- Registra la duración de la sesión, el uso visible de créditos de IA o tokens, el resultado de las pruebas y cualquier señal visible de reintento o escalada.
- Repite el proceso con varias tareas antes de comparar HydraFusion con un modelo fijo.
No intentes deducir el modo oculto solo por la longitud de la respuesta. Una respuesta larga puede reflejar la complejidad del repositorio y no necesariamente el uso de Critique. Mantén una alternativa con un modelo fijo para trabajos largos, con varias interacciones, sensibles a la latencia o de alto impacto: GitHub recomienda tareas de primer turno para la versión preliminar actual e identifica un mejor rendimiento en conversaciones de varios turnos como objetivo futuro en sus indicaciones de lanzamiento.
Preguntas frecuentes sobre HydraFusion
¿Puedo seleccionar manualmente Single, Cascade o Critique?
No mediante un comando de modo de HydraFusion documentado. El control disponible actualmente consiste en seleccionar HydraFusion y dejar que el sistema elija; utiliza un modelo fijo cuando necesites un enrutamiento determinista.
¿Cómo se factura HydraFusion?
GitHub afirma que el uso se basa en los tokens consumidos por los modelos que utiliza HydraFusion, facturados según la tarifa estándar de cada modelo, tal como se explica en el anuncio oficial. Una reducción observada en un benchmark no equivale a un descuento universal para los clientes, y los flujos con varias fases pueden consumir más que una solicitud directa.
HydraFusion resulta especialmente interesante cuando una tarea es lo bastante importante como para beneficiarse de una escalada o una revisión selectivas, pero también lo bastante estructurada como para poder verificarse. Para trabajos rápidos, la sencillez de Single puede pesar más; en tareas largas o críticas, un comportamiento predecible con un modelo fijo puede seguir siendo la mejor opción operativa hasta que la evidencia del repositorio justifique añadir esa orquestación.