Análisis / Desarrollo y agentes
Copilot Fusion elige y combina modelos de IA para programar
Elegir manualmente un modelo de IA para cada tarea de programación consume tiempo y puede llevar a utilizar opciones caras cuando no hacen falta. GitHub Copilot Fusion automatiza esa decisión, pero el nivel de esfuerzo sigue condicionando el consumo.
Copilot Fusion merece la pena para tareas de desarrollo habituales cuando no necesitas fijar un modelo concreto. Selecciona y coordina modelos automáticamente, mientras tú decides cuánto esfuerzo debe dedicar a cada petición. Para un equipo pequeño, lo razonable es comenzar con Standard, utilizar High cuando la tarea lo justifique y reservar Max para problemas especialmente exigentes.
GitHub anunció su disponibilidad general el 28 de octubre de 2026, durante GitHub Universe. Según el changelog oficial de GitHub, está disponible en todos los planes de Copilot y funciona en Visual Studio Code, la aplicación de GitHub Copilot, Copilot CLI y los IDE de JetBrains.
Fusion sustituye la elección manual por una decisión automática
Hasta ahora, una forma habitual de trabajar con asistentes de programación consistía en seleccionar un modelo antes de empezar y cambiarlo manualmente cuando la tarea requería más capacidad.
Copilot Fusion introduce otra opción. Al seleccionarlo en el menú de modelos, GitHub decide qué modelo utilizar y si conviene combinar varios para resolver la petición.
El usuario mantiene el control sobre el nivel de esfuerzo, pero deja de decidir qué modelo debe intervenir en cada paso.
Esto puede resultar útil cuando las tareas cambian constantemente entre modificaciones sencillas, depuración y desarrollo de funcionalidades. También evita mantener seleccionado por costumbre un modelo más caro del necesario.
Single, Cascade y Critique resuelven las tareas de forma distinta
GitHub describe tres patrones de ejecución que Fusion puede utilizar automáticamente, según la complejidad de la petición.
- Single: un modelo realiza la tarea directamente. Es el recorrido más sencillo, sin incorporar revisiones adicionales de otros modelos.
- Cascade: un modelo eficiente prepara una primera solución. Un mecanismo de evaluación decide si es suficiente o si debe pasar el trabajo a otro modelo más potente.
- Critique: un modelo genera la solución inicial y otros modelos la revisan. Después, el modelo original puede corregirla utilizando esas observaciones.
Estos mecanismos aparecen en la documentación de lanzamiento de GitHub.
Cascade resulta interesante para controlar el gasto porque permite intentar resolver una petición sin recurrir directamente al modelo más potente. Sin embargo, una tarea que necesita escalar puede consumir recursos de varios modelos.
Critique incorpora una revisión adicional, útil cuando hay aspectos de la solución que conviene contrastar. Esa revisión tampoco garantiza que el código resultante esté libre de errores.
El usuario selecciona el nivel de esfuerzo; Fusion decide qué patrón aplicar.
Standard, High o Max según el trabajo
Fusion ofrece tres niveles de esfuerzo. La elección determina qué capacidad prioriza el sistema, pero no establece un precio fijo por tarea.
| Criterio | Qué comprobar |
|---|---|
| Standard | Adecuado como punto de partida para programación cotidiana y tareas bien delimitadas. |
| High | Conviene probarlo en problemas difíciles que requieren más razonamiento o cambios relacionados entre archivos. |
| Max | Reservarlo para tareas especialmente complejas donde la profundidad del análisis pueda justificar más consumo. |
| Calidad necesaria | Comprobar el resultado mediante pruebas y revisión, independientemente del nivel utilizado. |
| Consumo | Revisar los modelos empleados y el coste real de las tareas representativas. |
| Modelo fijo | Preferirlo cuando necesites controlar expresamente el modelo utilizado o comparar resultados bajo las mismas condiciones. |
Para un equipo pequeño, una política sencilla consiste en utilizar Standard de forma habitual y subir el esfuerzo cuando la naturaleza del trabajo lo requiera. Elegir Max permanentemente elimina parte del interés de delegar la selección con criterios de eficiencia.
Fusion no tiene tarifa propia y puede utilizar varios modelos
GitHub no cobra una tarifa independiente por activar Fusion. Cada modelo utilizado se factura según su precio habitual, por lo que una petición que implique varios modelos puede tener un coste diferente al de una ejecución sencilla.
Los usuarios con planes de pago reciben un 30 % de descuento temporal sobre los costes de modelos utilizados mediante Fusion, según GitHub.
Ese descuento no debe utilizarse como referencia permanente para presupuestar el servicio.
GitHub también afirma que Fusion Max quedó a 2 puntos de Claude Code con Opus 5.5 Max en el Artificial Analysis Coding Agent Index, con aproximadamente la mitad de coste por tarea en API y un 40 % menos de tiempo.
Son resultados comunicados por el fabricante en su presentación de GitHub Universe. No demuestran que Fusion vaya a ser más económico en todos los proyectos.
Para presupuestar el uso de asistentes, conviene medir tareas propias y revisar el coste de los agentes de IA según sus precios publicados.
Cuándo conviene mantener un modelo fijo
Delegar la selección funciona mejor cuando las tareas admiten distintos caminos para alcanzar un resultado válido.
En cambio, elegir manualmente un modelo puede ser preferible si necesitas comparar ejecuciones de forma consistente, trabajar con requisitos específicos de calidad o controlar qué proveedores procesan determinado contexto.
También resulta útil mantener una referencia fija durante las pruebas de una herramienta. De lo contrario, un cambio de modelo puede confundirse con una mejora del sistema que lo utiliza.
Esta distinción está relacionada con el problema tratado en por qué el mismo modelo puede dar resultados distintos según el sistema que lo ejecuta.
GitHub permite establecer políticas sobre los modelos disponibles para Fusion. Los administradores pueden limitar cuáles utiliza y configurarlo como opción predeterminada, según su anuncio oficial.
Para un equipo, conviene definir primero qué modelos están permitidos y después decidir cuánto margen se concede a la selección automática.
Copilot projects lleva la coordinación a varios repositorios
GitHub también presentó Copilot projects, una función distinta de Fusion que permite coordinar agentes trabajando en paralelo sobre varios repositorios desde la aplicación de Copilot.
Según el anuncio de GitHub Universe, los agentes pueden continuar ejecutándose en la nube aunque el desarrollador cierre el portátil.
Esto permite separar trabajos relacionados y supervisar su progreso desde un mismo espacio. Sin embargo, coordinar más agentes exige revisar sus resultados y comprobar que los cambios encajan entre sí.
Para decidir qué trabajos delegar conviene considerar también los criterios de capacidad y fiabilidad de los agentes.
Esta semana, prueba Fusion Standard con tareas habituales, compara su consumo con un modelo fijo y establece cuándo utilizar High o Max. Si necesitas integrar agentes en un flujo de desarrollo o definir cómo controlar su coste, cuéntanos qué proceso quieres automatizar en Contrast 3D.
Fuentes
- GitHub Changelog: Route and orchestrate models with GitHub Copilot Fusion.
- GitHub Blog: GitHub Universe 2026 - Evolving every layer of the stack.
- GBHackers: GitHub Launches Copilot Fusion to Automatically Select and Combine AI Models for Coding.
- iTWire: GitHub announces new Copilot Fusion and Copilot Projects giving you smart, self-managing agentic developers with token cost control.
Comprobado el 1 de noviembre de 2026