El selector de modelos se está convirtiendo en un selector de orquestación

GitHub sacó HydraFusion de la línea de comandos y lo llevó al editor el 30 de septiembre. La vista previa de investigación ahora funciona en VS Code 1.140 y versiones posteriores, y en la aplicación de GitHub Copilot, lo que pone una idea bastante inusual frente a los desarrolladores comunes: deja de elegir un modelo, elige un flujo de trabajo.

HydraFusion no es un modelo. Es una capa que decide, para cada turno, cuántos roles de modelo necesita la tarea.

Tres formas para una misma solicitud

Single es el caso conocido. Un solo modelo gestiona la solicitud, tal como ya funciona Copilot Auto.

Cascade empieza barato. Un modelo eficiente escribe un primer borrador, y una puerta de calidad lo acepta o escala el trabajo a un modelo más potente. La idea es mantener las ediciones rutinarias en modelos económicos y reservar los caros para problemas que realmente los necesitan.

Critique gasta más para ser más seguro. Un modelo redacta, un segundo modelo de una familia distinta actúa como crítico de solo lectura, y el modelo redactor revisa una vez a partir de esa retroalimentación. El crítico nunca toca el código, lo que evita que el bucle se convierta en dos modelos discutiendo.

La diferencia con Auto es arquitectónica. Auto decide qué modelo único debe recibir tu prompt. HydraFusion decide cuántos roles necesita el turno y cómo interactúan. Eso es un cambio significativo en dónde vive el control de la inteligencia. Históricamente elegías un modelo porque era mejor para tu tipo de trabajo. Aquí eliges una política de optimización y dejas que la plataforma componga los modelos por debajo.

La economía es real y también autoinformada

El problema está en la facturación. GitHub cobra por tokens a la tarifa estándar de cada modelo seleccionado. Una ejecución de Critique llama al menos a dos modelos, así que puede costar más por solicitud que una llamada única. Cascade está diseñado para costar menos empujando el trabajo fácil hacia abajo. El ahorro no es un descuento en ningún modelo. Es una apuesta a que la mayoría de los turnos no necesitan el mejor.

Las evaluaciones controladas del propio GitHub reportaron reducciones de costo de flujo de trabajo de entre 36 y 67 por ciento frente a su línea base de Claude Opus 5 en tres benchmarks de agentes de código, con una calidad 4.9 puntos porcentuales superior en TerminalBench 2.1, 1.5 puntos inferior en DeepSWE y 0.1 puntos inferior en CheckpointBench. Son cifras producidas por el proveedor sobre la propia configuración de pruebas de GitHub. Son una hipótesis sobre tu repositorio, no una garantía, y el conjunto de modelos que participa en HydraFusion no se ha publicado por completo. Cualquier cosa construida sobre la vista previa debería tratar el comportamiento de enrutamiento como algo que puede cambiar sin aviso.

También hay un costo de latencia evidente. Un borrador más una revisión tardan más que una sola respuesta. Los equipos con planes Business y Enterprise tienen que vigilar de cerca los paneles de uso, porque el sistema decide cuándo escalar y esa decisión no es gratuita.

Una optimización que no puedes inspeccionar es difícil de confiar

La parte incómoda del enrutamiento es que quien toma la decisión es la plataforma, no el desarrollador. Puedes ver qué modelo respondió después de los hechos, pero no puedes ver fácilmente por qué el sistema eligió un flujo de trabajo, qué midió la puerta de calidad ni qué tan cerca estuvo una ejecución de Cascade de escalar. Las afirmaciones de benchmark de GitHub describen un promedio sobre su propio conjunto de pruebas, y los promedios ocultan los casos que importan.

Esa brecha convierte la orquestación en un problema de gobernanza más que puramente técnico. Un equipo de ingeniería que tiene que explicar por qué un pull request concreto fue revisado por dos familias de modelos y facturado en consecuencia necesita telemetría de enrutamiento, y la vista previa todavía no la expone. El remedio no es evitar la función. Es probarla como probarías cualquier dependencia cuyas entrañas están ocultas: sobre un conjunto fijo y aburrido de tareas del repositorio, midiendo el costo por tarea completada frente a un único modelo de frontera, y observando los reintentos y el esfuerzo de revisión en lugar del precio de etiqueta de una selección.

Vale la pena aferrarse a la comparación con Auto. Auto responde a la pregunta de qué modelo se adapta mejor a un prompt. HydraFusion responde a la pregunta de cuánto proceso merece un turno, y el proceso siempre ha sido la parte cara del trabajo de software.

El efecto secundario curioso es que hace que la elección del modelo sea menos emocional. Los desarrolladores desarrollan apego por modelos concretos, y esos apegos suelen construirse sobre un puñado de éxitos memorables. Un sistema que enruta por tipo de tarea y escala ante el fallo reconoce en silencio que ningún modelo gana en todas las categorías, algo que ha sido cierto desde hace tiempo y sobre lo que rara vez se actúa.

El siguiente rincón del editor se está construyendo para esto

La compilación de Insiders ya muestra hacia dónde va después. Una función llamada Compare Agents, etiquetada Run Multiple Agents, envía un prompt a varios agentes en paralelo, cada uno en su propio git worktree, y luego hace que un agente árbitro elija un ganador o entregue la lista corta a una persona.

El detalle interesante es qué mira el árbitro. Compara archivos modificados y estadísticas de diff, resultados de pruebas, estado de compilación, diagnósticos, tiempos y diferencias arquitectónicas. Ejecuta la suite de pruebas. No le pide a otro modelo de lenguaje que lea el código y adivine. Es una decisión pequeña con consecuencias grandes, porque significa que la comparación se basa en el estado real del proyecto y no en la opinión que un modelo tiene de él.

El resto de la misma versión es infraestructura más silenciosa que solo importa cuando los agentes se ejecutan en paralelo. Las sesiones multi carpeta permiten que cada conversación de una sesión use su propia carpeta o worktree, de modo que los cambios dejan de chocar. La delegación remota entrega una tarea a un host de agente remoto conectado. Las carpetas de worktree compartidas reutilizan directorios ignorados para evitar reinstalar dependencias en cada rama. Los Dev Containers ahora se detienen tras cinco minutos de inactividad y se reinician a demanda.

La gobernanza sigue llegando en los mismos commits que las funciones

La mitad de la versión orientada a TI no es un añadido posterior. Cuando las funciones de IA no están disponibles, el editor ahora indica la versión mínima requerida en lugar de un aviso genérico de actualizar. Los administradores pueden establecer un nivel predeterminado para el modelo Auto. Una nueva configuración de OpenTelemetry asigna el uso de Copilot a desarrolladores individuales.

Lee esas tres cosas juntas y la forma queda clara. Una plataforma que coordina varios modelos a lo largo de varios turnos genera costos, telemetría y preguntas de permisos que el autocompletado de un solo modelo nunca generó. La atribución de costos deja de ser una curiosidad financiera y se convierte en un requisito previo para permitir que la función se acerque a producción.

La revisión con múltiples modelos ha sido práctica estándar entre equipos de ingeniería cuidadosos desde hace tiempo. Le pides a un modelo que escriba y a otro que busque errores, o pruebas primero un modelo rápido y escalas cuando el resultado decepciona. HydraFusion toma ese hábito y lo hace automático, lo cual es cómodo y también elimina una decisión que a algunos equipos les gustaba tomar a mano.

Cuánto tiempo debería permanecer una función como vista previa es una pregunta justa. Las herramientas están llegando más rápido que la política que las rodea, y la previsibilidad de precios es la primera víctima. Una ejecución de Critique que llama en silencio a dos modelos de frontera sobre un repositorio grande puede gastar dinero real antes de que nadie lo note. Que HydraFusion pase a ser predeterminado depende menos de si el enrutamiento funciona y más de si GitHub puede hacer que la factura sea lo bastante legible como para que alguien la firme.