HydraFusion Max de GitHub no elige un modelo para su tarea: planifica quién redacta, juzga y repara

La primera generación del enrutamiento de modelos hacía una pregunta por solicitud: ¿qué modelo debería responder a esto? La actualización del 14 de octubre que GitHub hizo de HydraFusion, su orquestación multi-modelo para Copilot, plantea una distinta: ¿qué modelo debería hacer qué parte del trabajo, y con cuánta intensidad debería pensar cada uno?

HydraFusion ahora se nutre de un grupo de Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol y GPT-6 Luna, y GitHub añadió una opción Max ajustada para las tareas más exigentes, con mayor esfuerzo de razonamiento donde importa la profundidad, mientras que la orquestación sigue sopesando la eficiencia de tokens. Ambas permanecen en preview de investigación, para los planes Copilot Pro, Pro+, Business y Enterprise con funciones experimentales o de preview habilitadas, y sujetas a las políticas de modelos de la organización.

Qué cambió en los flujos de trabajo

Se reelaboraron dos patrones de orquestación, y muestran hacia dónde va el diseño.

1. Redacción con esfuerzo de razonamiento medio
2. Un juez inspecciona el trabajo inicial
3. Reparación solicitada solo si es necesario

Gasto en producirGasto en verificar

Cascade solía dejar que un modelo inicial intentara una tarea y escalara a uno más potente cuando era necesario. Ahora añade un paso de juicio que inspecciona el trabajo inicial y solicita una reparación solo si es necesario. Critique dependía en gran medida de resúmenes de texto del trabajo; ahora utiliza herramientas que inspeccionan el espacio de trabajo real y ejecuta varios modelos críticos en paralelo. Y el esfuerzo de razonamiento ya no es el predeterminado de cada modelo: HydraFusion establece un esfuerzo medio para los borradores iniciales y un esfuerzo alto para la revisión.

Cada una de esas decisiones traslada el gasto de producir a verificar. Los borradores se abaratan; el juicio recibe más atención. Es una estrategia de ejecución, no una elección de modelo.

Por qué importan los críticos que leen el espacio de trabajo

Un revisor que solo lee un resumen de un cambio revisa la versión del autor sobre el trabajo, no el trabajo. Los críticos que inspeccionan archivos, ejecutan herramientas y ven el repositorio pueden detectar lo que el resumen omitió. Es la misma distinción entre una afirmación y una evidencia que atraviesa una buena revisión humana de código, y es una mejora real en un sistema que se revisa a sí mismo.

Sigue siendo el sistema revisándose a sí mismo. Los críticos paralelos extraídos del mismo grupo de modelos son una verificación más fuerte que un solo crítico, pero no son independientes en el sentido en que lo es una prueba determinista o un responsable humano. Trate la revisión interna de HydraFusion como una mejora de calidad antes del pull request, no como un sustituto de la revisión posterior.

Cómo evaluarlo

Más llamadas a modelos por tarea pueden elevar la calidad, el costo o ambos. El changelog de GitHub no ofrece precios ni una comparación de costos para la opción Max, por lo que la economía debe medirse en su propio trabajo:

1. Elija un conjunto fijo de tareas reales de sus repositorios, con resultados correctos conocidos, y ejecútelas con su configuración actual predeterminada, HydraFusion y Max.
2. Mida el costo por cambio aceptado, no el costo por solicitud. Una ejecución que cuesta tres veces más y se fusiona sin retrabajo puede ser más barata que tres intentos baratos y un revisor frustrado. Defendimos este argumento para la inferencia con precio por tarea completada.
3. Registre el tiempo hasta un cambio fusionable, porque la orquestación multi-etapa añade latencia incluso cuando ahorra revisión.
4. Decida dónde se permite Max. Un nivel diseñado para las tareas más difíciles se usará para las fáciles si es el predeterminado. Conviértalo en una elección explícita por repositorio o tipo de tarea.

Un avance de cómo funcionarán los portafolios de modelos

HydraFusion es una función de codificación, pero el patrón se generaliza. Argumentamos que las empresas ejecutarían un portafolio de modelos con roles distintos y que la propia guía de OpenAI apunta hacia el enrutamiento por tarea. GitHub da el siguiente paso: enrutamiento por etapa dentro de una tarea, con un presupuesto para pensar en cada una.

Para los equipos de plataforma, eso cambia lo que la política debe expresar. “Qué modelos están aprobados” ya no es suficiente. Las preguntas pasan a ser qué modelos pueden redactar, cuáles pueden juzgar, cuánto razonamiento puede gastar cada etapa y quién ve la factura. Resuélvalas mientras la función sigue en preview, y el primer despliegue en producción no las resolverá por usted.