HydraFusion: cómo evaluar orquestación multimodelo

Cuando una tarea de ingeniería se atasca, resulta tentador sumar otro modelo: uno redacta, otro critica y un tercero resuelve lo difícil. Esa composición puede mejorar la cobertura, pero también duplica contexto, añade latencia, consume más presupuesto y crea nuevos estados intermedios. Si el crítico revisa una versión distinta de la que terminó modificando el repositorio, o si una escalación repite herramientas con efectos, la aparente redundancia puede reducir la confiabilidad en lugar de aumentarla.

GitHub anunció el 30 de septiembre de 2026 que HydraFusion, antes limitado a Copilot CLI, ya está disponible como research preview en Visual Studio Code y la app de GitHub Copilot. El sistema elige por solicitud entre tres patrones: Single, Cascade y Critique. La novedad central es la expansión a superficies de uso cotidiano, publicada un día calendario antes de este artículo en Lima. No es un modelo nuevo ni una promesa de que toda tarea recibirá varios pases.

Single entrega la tarea a un modelo. Cascade empieza con un modelo eficiente y aplica un gate de calidad que acepta el resultado o lo escala a otro más capaz. Critique separa roles: un modelo produce el borrador, un crítico de otra familia lo revisa sin herramientas y el primer modelo hace una única revisión. HydraFusion usa señales de razonamiento, generación de código, depuración y uso de herramientas para elegir el patrón que espera suficiente para alcanzar su barra de calidad.

La diferencia con Auto es importante. Auto selecciona un modelo por solicitud; HydraFusion puede seleccionar además la topología de ejecución dentro del turno. Esa decisión ligera no genera la respuesta, pero condiciona qué contexto se comparte, cuántos pases se facturan y cuánto tarda el resultado. La documentación indica que el pool de modelos puede cambiar y que el usuario no elige sus integrantes. Por eso una evaluación empresarial debe observar el comportamiento del flujo, no depender de una combinación nominal que mañana puede ser distinta.

El router solo puede parecer inteligente si la tarea tiene un resultado comprobable. Define el commit inicial, archivos permitidos, herramientas, permisos, timeout, pruebas obligatorias y criterios de rechazo. Separa tareas simples, bugs multiaarchivo, cambios con migración y solicitudes ambiguas; sus necesidades de revisión no son equivalentes. Incluye casos que deben terminar sin parche, como credenciales faltantes, requisitos contradictorios o una acción que exige aprobación humana. Así puedes comprobar si Single evita trabajo innecesario y si Cascade o Critique aparecen cuando realmente aportan valor.

Mantén fijos el prompt, el repositorio, las dependencias y los jueces al comparar políticas. Registra el patrón elegido y los modelos solo como evidencia del recorrido, no como definición permanente del producto. Ejecuta repeticiones cuando el riesgo lo justifique, porque una selección correcta en una sola muestra no demuestra estabilidad. El objetivo no es forzar una distribución ideal de flujos: es saber qué clases de tarea llegan a un resultado aceptado, cuáles se escalan y cuáles deberían detenerse antes de tocar el workspace.

En Cascade, el componente decisivo no es el modelo fuerte sino el gate que permite evitarlo. Mide falsos aceptados: borradores que cruzan el gate y luego fallan pruebas, alcance o revisión. Mide también falsas escalaciones: soluciones correctas que consumen otro pase sin cambiar la decisión final. Segmenta estos errores por tipo de tarea y severidad. Un gate conservador puede elevar calidad y costo a la vez; uno permisivo puede mostrar buena latencia mientras deja pasar fallos raros pero críticos.

No reduzcas el gate a una autoevaluación textual del mismo sistema. Combina checks deterministas, como compilación, pruebas y lista de archivos, con jueces específicos y revisión humana muestreada. Para un cambio de API, por ejemplo, exige contrato compatible, pruebas negativas y ausencia de secretos; una explicación convincente no compensa romperlos. Conserva la razón de escalación y el artefacto rechazado. Sin esa evidencia solo sabrás que se usó más cómputo, no si el router detectó una carencia real.

GitHub factura cada modelo que HydraFusion usa a su tarifa estándar y no aplica el descuento de Auto. El costo correcto incluye ruteo, borrador, crítica, revisión, escalación, reintentos y fallbacks. La latencia debe medirse desde la solicitud hasta el artefacto aceptable, incluyendo herramientas y checks. Reporta medianas y colas, no solo promedios: una ruta Critique puede ser razonable en el centro y aun incumplir el SLA cuando el repositorio o la conversación son grandes.

El contexto también forma parte de la economía. HydraFusion conserva el modelo principal cuando puede para aprovechar tokens cacheados y entrega al crítico solo lo necesario, pero cada pase obedece el límite de contexto de su modelo. Si el sistema exige compactar una conversación, registra qué evidencia se perdió y si cambió el resultado. Compara contra Auto y contra un modelo fijo en la misma unidad: tarea aceptada. Un ahorro por token carece de valor si aumenta las correcciones humanas o repite efectos externos.

Critique promete una mirada independiente: el revisor pertenece a otra familia de modelos y opera sin herramientas. Ese aislamiento reduce la posibilidad de que modifique el repositorio, pero no garantiza una crítica útil. Comprueba si recibe el contrato, el diff, los resultados de pruebas y solo el contexto necesario; si ve demasiado poco, inventará problemas, y si hereda toda la narración del solver puede repetir sus supuestos. Clasifica observaciones válidas, irrelevantes y omitidas en fallos que sembraste deliberadamente.

Revisa también cómo el solver usa la observación. Aceptar toda crítica puede degradar una solución correcta; ignorarla vuelve decorativo el segundo pase. El registro debería enlazar hallazgo, decisión de aplicar o rechazar y cambio resultante. Incluye casos de permisos, seguridad, concurrencia y compatibilidad, no solo estilo. La diversidad de proveedor o familia es una señal arquitectónica, pero la independencia real se demuestra cuando el crítico encuentra fallos diferentes y mejora la aceptación completa sin introducir deriva.

La documentación advierte un límite operativo clave: si HydraFusion descarta un borrador, los cambios que ese borrador ya hizo en el workspace no se revierten automáticamente. Por eso el artefacto final no puede validarse solo contra la respuesta visible. Captura estado inicial, comandos ejecutados, archivos tocados y diff final. Ejecuta cada caso en un checkout aislado y decide qué ocurre cuando hay cancelación, timeout o fallo del gate. Un resultado cancelado debe quedar identificable y nunca mezclarse silenciosamente con el siguiente intento.

Extiende el mismo principio a herramientas externas. Usa claves idempotentes, entornos de prueba y permisos mínimos; el crítico sin herramientas no deshace un ticket, despliegue o mensaje creado por el solver. Exige que la orquestación aplique el parche solo después de validar el flujo completo, o que produzca un cambio revisable en vez de mutar el sistema objetivo. GitHub describe fail-safe application como principio interno, pero tu proceso todavía debe verificar el estado material que quedó alrededor del agente.

Supongamos un servicio que pierde eventos al reintentar una migración de esquema. El contrato fija un commit, seis archivos permitidos, una base efímera y tres pruebas: duplicado, rollback y concurrencia. Single debería resolver casos directos. Cascade escala cuando el primer parche no supera una prueba determinista. Critique resulta útil si el parche pasa pruebas pero necesita una lectura separada de idempotencia y compatibilidad. El crítico recibe contrato, diff y resultados; no recibe credenciales ni acceso al workspace.

El equipo aprueba la política solo si cruza cinco gates: corrección completa, alcance respetado, costo total dentro del presupuesto, latencia dentro del SLA y workspace limpio tras fallos o cancelaciones. Compara aceptación y costo contra Auto y un modelo fijo. Si Critique encuentra más problemas pero añade cambios laterales al aplicar sugerencias, falla alcance. Si Cascade escala casi todos los casos, el gate o la segmentación requieren ajuste. El ejemplo es ilustrativo; no describe una implementación ni resultados de Wasyra.

GitHub publicó resultados offline favorables para configuraciones seleccionadas de HydraFusion en tres benchmarks, pero el artículo de investigación original es del 4 de septiembre y funciona aquí como contexto, no como la noticia. Los resultados dependen de revisiones de benchmark, pool de modelos, políticas ajustadas y supuestos de precio. CheckpointBench es interno, y el propio proveedor dice que la preview servirá para comprobar la traducción a cargas reales. No reproducimos esos benchmarks ni presentamos sus ahorros como expectativa transferible.

La decisión útil es más pequeña: habilita la preview en un grupo acotado, usa tareas sustanciales y bien definidas, captura patrón, pases, costo, latencia y estado, y mantén un control con Auto o modelo fijo. Reevalúa cuando cambien los modelos o el comportamiento de HydraFusion. La documentación aclara que no existe SLA y que no está destinado a producción durante la research preview. Eso lo convierte en objeto de evaluación, no en un default para workflows críticos.

La orquestación multimodelo vale cuando compra aceptación verificable, no cuando simplemente acumula opiniones. Si necesitas diseñar un piloto con contratos de tarea, permisos, trazas y gates de release, el servicio de agentes a medida de Wasyra puede ayudar a construir esa capa. Es un servicio de implementación separado del producto disponible en agents.wasyra.com.