GitHub anunció el 28 de octubre de 2026 el paso a disponibilidad general de Copilot Fusion, una opción del selector de modelos que ya no fija un único modelo por tarea, sino que reparte cada petición entre varios modelos según el nivel de esfuerzo elegido. El objetivo declarado es equilibrar rendimiento y coste sin dejar esa decisión en manos del desarrollador en cada instrucción.
El problema que Fusion busca resolver
Elegir un modelo potente para una tarea de razonamiento complejo y luego olvidar volver a un modelo más ligero para el trabajo rutinario es una fuente de sobrecoste silencioso bien documentada entre los equipos que usan asistentes de código a diario. Fusion traslada esa decisión del desarrollador a la herramienta: en cada petición, el sistema analiza la naturaleza de la tarea y elige por sí mismo la combinación de modelos más adecuada.
Tres estrategias de orquestación
Hay tres flujos de trabajo disponibles según el nivel de esfuerzo elegido en el selector (Standard, High, Max):
| Flujo de trabajo | Funcionamiento | Caso de uso típico |
|---|---|---|
| Single | Un único modelo resuelve la petición de principio a fin | Tarea sencilla y bien definida |
| Cascade | Un modelo económico redacta una respuesta; un control de calidad la acepta o la escala a un modelo más capaz | Tarea de dificultad incierta |
| Critique | Un modelo redacta, un segundo modelo revisa, el primero corrige | Tarea de razonamiento o refactorización sensible |
GitHub no publica la lista exacta de modelos que orquesta Fusion: la función combina el enfoque multimodelo de su proyecto interno HydraFusion con la selección automática de modelos ya integrada en Copilot, y solo recurre a los modelos habilitados en la política de modelos de la organización o la empresa.
Resultados comparados con Claude Code
En el Artificial Analysis Coding Agent Index, GitHub sitúa a Fusion Max en una puntuación de 60, a solo dos puntos de Claude Code ejecutado con Opus 5.5 Max, usado como referencia del mercado. La cifra más destacada tiene que ver con el coste: GitHub reivindica este resultado con aproximadamente la mitad del coste medio de API por tarea, con cerca de la mitad de tokens consumidos y casi un 40 % menos de tiempo de procesamiento por tarea.
Fusion traslada el equilibrio entre potencia y coste del desarrollador a la herramienta, petición a petición.
Despliegue, facturación y control de administración
Fusion está disponible en todos los planes de pago de Copilot, en Visual Studio Code, la app de Copilot que recientemente sumó control de ordenador, el CLI de GitHub Copilot y los IDE de JetBrains; otros clientes llegarán más adelante. Las cuentas que participaban en la vista previa de investigación bajo auto, HydraFusion o HydraFusion Max pasan automáticamente al nivel de esfuerzo Fusion equivalente.
En cuanto a la facturación, cada modelo que invoca Fusion se factura a su tarifa estándar, pero GitHub aplica, por tiempo limitado, un descuento del 30 % sobre el coste de los modelos usados a través de Fusion para las cuentas con un plan de Copilot de pago. Los administradores de organización o empresa pueden activar o desactivar modelos para Fusion, e imponer Fusion, con un nivel de esfuerzo determinado, como modelo predeterminado mediante la configuración gestionada de la empresa.
Qué cambia para un equipo de desarrollo web
Para un equipo que ya gestiona el coste de correcciones agénticas en producción, Fusion ofrece un ajuste predeterminado razonable sin necesidad de afinar modelo por modelo. Sigue siendo conveniente fijar el nivel de esfuerzo predeterminado a nivel de organización en lugar de dejarlo a elección individual, para evitar que una tarea rutinaria acabe sistemáticamente en Max.
Lo que hay que recordar
Copilot Fusion generaliza una orquestación multimodelo ya probada en vista previa, con tres estrategias claramente definidas y la promesa de un coste menor con calidad comparable. Su disponibilidad en todos los planes de pago y en los principales IDE lo convierte en un ajuste que conviene probar cuanto antes, sin perder de vista la facturación por modelo invocado más allá de la tarifa de Fusion que se muestra en pantalla.
Sigo siendo cauto con las comparativas de puntuación que publica el propio proveedor: una diferencia de dos puntos en un índice compuesto dice poco sobre el comportamiento en un proyecto real. Lo que me parece más sólido es el propio principio de escalada condicional, que coincide con lo que ya hago manualmente al pasar de un modelo ligero a otro más capaz solo cuando la primera pasada falla. Automatizar ese reflejo tiene sentido, siempre que se mantenga el control sobre el nivel de esfuerzo predeterminado. — Simon Janvier
Para saber más: el detalle completo del funcionamiento y las condiciones de facturación de Copilot Fusion está disponible en el changelog oficial de GitHub.
