GitHub Copilot Fusion ya está disponible: una elección, muchos modelos

GitHub puso Copilot Fusion a disposición de todos el 28 de octubre de 2026. En lugar de elegir un solo modelo de IA para una tarea de programación, los desarrolladores pueden elegir Fusion y dejar que Copilot escoja los modelos por sí mismo, y a veces los combine. Según el changelog de GitHub, su nivel más alto queda a dos puntos o menos del mejor agente de programación en un benchmark, por cerca de la mitad del coste.

Copilot es el asistente de programación con IA de GitHub. Hasta ahora, la mayoría de los usuarios elegía un modelo a mano o dejaba que un ajuste «auto» eligiera un modelo por tarea.

Qué hace Copilot Fusion

Fusion es la versión final de Project HydraFusion, que GitHub lanzó como vista previa de investigación el 4 de septiembre. GitHub dice que el producto combina la orquestación multimodelo de HydraFusion con la selección automática de modelos que Copilot ya tenía.

Un enrutador se sitúa delante de los modelos. Para cada prompt, decide qué modelo o modelos deben encargarse del trabajo. Fusion tiene tres niveles de esfuerzo, llamados Standard, High y Max.

Está disponible en VS Code, la app GitHub Copilot, la Copilot CLI y los IDE de JetBrains. Los administradores deciden qué modelos puede usar Fusion mediante políticas de modelos. También pueden hacer de Fusion la opción predeterminada de su organización.

Cómo funciona el enrutamiento

Según GitHub, Fusion envía cada tarea por uno de tres caminos.

Patrón	Qué ocurre
Single	Un modelo resuelve la tarea directamente.
Cascade	Un modelo más barato redacta una respuesta. Un control de calidad la acepta o la escala a un modelo más potente.
Critique	Un modelo redacta, un segundo modelo revisa y el primer modelo corrige.

TechTarget explicó cómo elige el enrutador. Se basa en HyDRA, un framework existente de GitHub que califica las tareas según razonamiento, generación de código, depuración y uso de herramientas. Esas calificaciones deciden qué patrón recibe cada tarea.

El patrón Critique tiene un detalle que conviene conocer. Durante la vista previa, InfoQ informó de que el revisor no tiene acceso a herramientas y procede de otra familia de modelos. Ese diseño reduce la probabilidad de que dos modelos parecidos coincidan en el mismo error.

Las cifras de benchmark y coste

La cifra principal de GitHub procede del Artificial Analysis Coding Agent Index, una clasificación externa de agentes de programación con IA. Fusion Max obtuvo 60. Según GitHub, eso queda a dos puntos o menos de Claude Code con Opus 5.5 Max.

GitHub dice que Fusion lo logró «por cerca de la mitad del coste medio de API por tarea, usando cerca de la mitad de tokens y tardando cerca de un 40 % menos de tiempo por tarea». Son cifras propias de GitHub para un solo índice. No son una prueba independiente de Fusion con su código.

La vista previa había hecho afirmaciones similares en otras pruebas. InfoQ informó de que en TerminalBench 2.1, HydraFusion mejoró la calidad de las tareas verificadas en 4,9 puntos porcentuales. También redujo el coste estimado un 67 % frente a Claude Opus 5. En CheckpointBench, una prueba interna de GitHub construida con sesiones reales de Copilot, su puntuación quedó a 0,1 puntos o menos de Opus 5, con un coste estimado un 65 % menor.

Los primeros clientes señalan el mismo beneficio. Hari Pokhrel, ingeniero de software principal en AT&T, dijo que Fusion Standard «mejoró la eficiencia de tokens en todo AT&T» al elegir el modelo adecuado para cada tarea.

Cómo funciona la facturación

Fusion no tiene una tarifa plana. «Cuando usas Copilot Fusion, se te cobra por cada modelo que utiliza, a la tarifa estándar de cada modelo», dice el changelog.

Eso importa en los patrones Cascade y Critique, donde una sola tarea puede pasar por dos o tres modelos. Por tiempo limitado, los usuarios de planes de pago de Copilot obtienen un 30 % de descuento en los costes de los modelos. GitHub no dijo cuándo termina el descuento.

La elección de modelos dentro de Copilot ha cambiado rápido. GitHub retiró seis modelos de Copilot a principios de este mes, lo que obligó a los equipos con nombres de modelos fijados a cambiar.

Qué significa para los desarrolladores

La propuesta es sencilla: dejar de elegir modelos y que GitHub lo haga. Si eso ahorra dinero depende de su trabajo, así que mídalo en lugar de confiar en el benchmark.

• Haga una prueba comparativa. Elija una semana de tareas típicas y compare Fusion Standard con el modelo que usa ahora. Registre los tokens, el tiempo y con qué frecuencia acepta el resultado.
• Vigile la factura, no la lista de precios. Fusion cobra cada modelo al que llama. Una ejecución Critique puede costar más que un solo modelo potente en una tarea corta, aunque de media cueste menos.
• Defina primero las políticas de modelos. Los administradores deberían decidir a qué modelos puede enrutar Fusion antes de hacerlo predeterminado. Así se mantienen intactas las reglas de datos y las aprobaciones de proveedores.
• Aproveche el descuento para aprender. El descuento del 30 % es temporal. Reúna sus propios datos de costes mientras dure, para conocer sus cifras reales cuando termine.
• Espere fijar menos modelos. Con listas de modelos que cambian cada pocas semanas, el enrutamiento reduce el trabajo de actualizar scripts y configuraciones. Ese beneficio es fácil de pasar por alto y difícil de medir.

Los analistas llevan tiempo defendiendo esta dirección. «Estamos aprendiendo rápidamente que la economía de usar LLM para cada tarea de programación a menudo no funciona», dijo Torsten Volk, de Omdia, a TechTarget. Fusion es la respuesta de GitHub a ese problema, y sus datos de uso mostrarán si encaja con su equipo.