GitHub Copilot Fusion: cuándo activarlo y cómo aprovecharlo

Verificado con la documentación y los anuncios oficiales de GitHub disponibles el 29 de octubre de 2026. Esta evaluación se basa en la documentación; no es una prueba comparativa de uso real.

¿Qué cambia con GitHub Copilot Fusion?

GitHub Copilot Fusion se encarga de elegir el modelo y, cuando resulta útil, de coordinar varios modelos. Funciona como un responsable técnico que decide si un cambio necesita una implementación rápida, una revisión o una intervención adicional. Tú sigues definiendo el trabajo y decidiendo si el código resultante es aceptable.

GitHub lanzó Fusion para disponibilidad general el 28 de octubre de 2026, combinando la orquestación de Project HydraFusion con la selección automática de modelos de Auto. Las opciones existentes de Auto, HydraFusion y HydraFusion Max pasan a los niveles de esfuerzo correspondientes de Fusion. La versión preliminar de investigación de octubre es, por tanto, su predecesora, no un producto independiente que necesites usar junto con Fusion. Anuncio de Fusion de GitHub.

Los patrones de ejecución describen cómo se organiza el trabajo:

• Single: un modelo resuelve la tarea directamente.
• Cascade: un juez evalúa el borrador y decide si lo acepta o escala el trabajo.
• Critique: el borrador recibe una crítica independiente antes de que su autor lo revise.

Estos patrones proceden de la investigación de GitHub sobre HydraFusion. La documentación actual de Fusion describe modelos que revisan en paralelo y cuyos comentarios se combinan. Eso no significa que cada prompt active todos los patrones. Funcionamiento de Fusion.

Corregir una etiqueta e investigar una condición de carrera, por ejemplo, no deberían recibir automáticamente el mismo tratamiento. Fusion reparte ese esfuerzo dentro de la sesión. La guía sobre enrutadores de modelos explica la idea de fondo: asignar al trabajo la capacidad adecuada y después comprobar si esa elección sirvió de algo.

¿Dónde está disponible y cómo se activa?

Puedes usar Fusion en la aplicación Copilot, Visual Studio Code, Copilot CLI y los IDE de JetBrains. GitHub enumera estos entornos y su disponibilidad en los planes de Copilot. Eso no implica que todas las cuentas tengan acceso a los mismos niveles de esfuerzo: los modelos siguen sujetos al plan y a las políticas de cada cuenta. Disponibilidad actual.

Actualiza tu cliente antes de seguir estas instrucciones. Las opciones que activaban la versión preliminar de HydraFusion ya no son el procedimiento para configurar Fusion.

Aplicación GitHub Copilot

Haz clic en el nombre del modelo que aparece debajo del campo del prompt, activa Copilot Fusion y elige uno de los niveles de esfuerzo disponibles. Para volver a un modelo concreto, desactiva la opción y selecciona ese modelo. La aplicación recuerda tu elección para futuras sesiones. Selección de modelos en la aplicación.

Visual Studio Code

En la configuración, comprueba que chat.copilot.dynamicAutoTiers.enabled esté activado. Abre un chat nuevo con el Copilot harness, el entorno de ejecución que conecta el modelo con las herramientas del agente. Selecciona Copilot Fusion en el selector de modelos y elige uno de los niveles disponibles. Activar el ajuste no concede acceso por sí solo: el selector puede seguir mostrando Auto si tu cuenta no tiene ningún nivel de Fusion habilitado. Configuración en VS Code.

GitHub Copilot CLI

En una sesión interactiva, escribe /model, elige Fusion y su nivel de esfuerzo, y confirma. Para una primera prueba acotada, GitHub documenta la siguiente estructura de comando; este ejemplo solicita un análisis sin modificar archivos:

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

Es la opción actual de Fusion y no requiere el antiguo indicador experimental de HydraFusion. Selección de modelos en la CLI.

¿Qué modelos puede usar Fusion?

La lista de modelos Claude y GPT refleja un momento concreto; no es un compromiso permanente sobre el enrutamiento. La actualización de HydraFusion del 14 de octubre de 2026 mencionaba expresamente estos modelos:

• Claude Opus 5.5, de Anthropic.
• GPT-6 Astra, de OpenAI.
• GPT-6.1 Sol, de OpenAI.
• GPT-6 Luna, de OpenAI.

Esa actualización también presentó HydraFusion Max y un mayor esfuerzo de razonamiento para elaborar y revisar borradores. Estos son los nombres verificados en el anuncio de la versión preliminar. Actualización de octubre sobre los modelos disponibles.

La descripción actual de Fusion no publica una lista fija y exhaustiva de modelos en la nube. Indica que el conjunto cambia y que puedes ver los modelos utilizados al pasar el cursor sobre la etiqueta de esfuerzo que aparece debajo de una respuesta. El catálogo completo de modelos de Copilot no garantiza que Fusion vaya a utilizar todos los que figuran en él. Funcionamiento actual del conjunto de modelos.

Para quien dirige un equipo de ingeniería, lo que cuenta es la lista de modelos permitidos en su cuenta. Los propietarios de cuentas Enterprise pueden abrir AI controls → Copilot → Models → Configure Copilot Fusion models. Estas selecciones también están sujetas al resto de las políticas de modelos del usuario. Controles de modelos para Enterprise.

Existe, además, una versión preliminar independiente para el enrutamiento a modelos locales. Admite configuraciones específicas con MAI Code 1.1 Flash o Qwen3.8 Flash Next en el nivel Standard. Añadir cualquier otro modelo local no lo habilita para Fusion, y la inferencia local tampoco permite usar Fusion sin conexión: el enrutamiento sigue realizándose en la nube. Límites del uso de modelos locales.

Empieza con Standard y aumenta el esfuerzo cuando haga falta

Empieza con Standard; antes de elegir High o Max, define qué debe aportar la revisión adicional. GitHub presenta Standard como la opción para la programación cotidiana, High para tareas difíciles y un razonamiento más profundo, y Max para el trabajo más exigente. Definición de los niveles de esfuerzo.

Las tareas propuestas a continuación son recomendaciones editoriales, no afirmaciones de rendimiento medido:

Pedir de forma imprecisa que mejore toda una aplicación es una mala prueba de Max. Si no has definido qué constituye un buen resultado, no podrás saber si el razonamiento adicional ayudó. Acota la tarea a un problema observable, como eliminar una ruta de solicitudes duplicada sin alterar el comportamiento de los reintentos.

Fusion Max es un nivel de esfuerzo, no el nombre de una suscripción obligatoria. También existe Fusion Fast, pero el usuario no puede seleccionarlo y su uso se limita al chat integrado en el editor de VS Code. Opciones de esfuerzo.

¿Cómo consume Fusion los créditos de IA?

El costo depende del trabajo que realizan los modelos seleccionados. Los tokens de entrada, salida y caché se facturan según el modelo, con cargos por escritura en caché cuando corresponda, y después se convierten en créditos de IA. No hay un cargo fijo publicado en créditos por tarea de Fusion. Cómo calcula GitHub la facturación.

Fusion no cobra una tarifa adicional por la orquestación. Los planes de pago de Copilot reciben actualmente un descuento del 30% en los costos de los modelos de Fusion hasta el 30 de noviembre de 2026. Facturación de Fusion. Para comparar los planes y el consumo incluido en cada uno, consulta la guía de precios de GitHub Copilot.

Elaborar un borrador, someterlo a crítica y revisarlo son pasos que suman consumo. También influyen el esfuerzo de razonamiento, el tamaño del contexto, la actividad de las herramientas y el uso de caché. Por eso, una ejecución con varias pasadas puede gastar más créditos que una solicitud a un solo modelo, aunque el enrutamiento funcione según lo previsto. Explicación de VS Code sobre el consumo de créditos de IA.

En tu prueba, cuenta también los intentos fallidos y los prompts de corrección. Un borrador barato que exige arreglos reiterados puede salir peor que una ejecución más cara que produce un cambio aceptable. A la inversa, pagar una revisión crítica para un cambio de nombre sencillo puede no aportar nada útil. Compara el trabajo terminado, no la respuesta individual más barata.

¿Qué demuestra el benchmark de GitHub y qué queda por comprobar?

GitHub comunica un resultado prometedor, pero eso no demuestra cuánto ahorrarás en tu repositorio. En su anuncio de Universe, GitHub afirma:

La evaluación citada es el Artificial Analysis Coding Agent Index. Se trata de un resultado de benchmark comunicado por GitHub, no de una prueba independiente realizada para este artículo. Anuncio de GitHub Universe.

El registro detallado de cambios precisa que la comparación se hizo con Claude Code usando Opus 5.5 Max y que la métrica de costo es el costo promedio de API por tarea. Esa afirmación es más concreta que decir que Fusion reduce a la mitad una factura de Copilot. Contexto del benchmark de GitHub.

Lo que sí se puede inferir es que la orquestación podría lograr buenos resultados con mayor eficiencia que elegir siempre una configuración de máxima capacidad. Lo que no tiene respaldo es concluir que corregir cualquier error será más rápido o más barato. Que el resultado se reproduzca en tu caso depende de las tareas, los criterios de aceptación y las correcciones necesarias. Además, la promoción temporal de facturación y la comparación del benchmark son afirmaciones distintas: no las combines para prometer un ahorro.

Qué aporta a desarrolladores, responsables de equipo y compradores

Los desarrolladores pueden simplificar la elección del modelo. Si interrumpes el trabajo a menudo para decidir qué modelo debería abordar la siguiente tarea, merece la pena hacer una prueba acotada con Fusion. Deja claros la descripción del problema, el comportamiento esperado y los criterios de revisión. Delegar la selección debería quitarte una distracción sin restar precisión a la tarea.

Los responsables de ingeniería necesitan criterios para elegir el esfuerzo y un registro de los cambios aceptados. Una regla inicial útil es usar Standard para el trabajo habitual, High para cambios acotados que necesitan revisión y Max cuando haya un motivo concreto. Registra por qué ayudó aumentar el esfuerzo. De lo contrario, elegir el nivel más alto puede convertirse en una costumbre sin pruebas de que mejore el trabajo que se entrega.

Quienes comparan Copilot con Claude Code o Cursor antes de comprar deberían probar el flujo de trabajo que adoptarían. Un benchmark da motivos para evaluar una opción, no para migrar toda una organización. Valora la carga de revisión, la adaptación al repositorio y los resultados terminados junto con los créditos consumidos. La comparativa de Claude Code y GitHub Copilot aborda la decisión general; Fusion cambia una parte de ella.

Qué se exagera y cuándo conviene dejarlo desactivado

Que intervengan más modelos no te exime de revisar los cambios del código. GitHub documenta una limitación especialmente relevante: los borradores descartados pueden dejar modificaciones en los archivos. Fusion tampoco tiene una ventana de contexto combinada propia ni inicia subagentes. Limitaciones de Fusion.

Deja Fusion desactivado cuando necesites un modelo específico para una comparación controlada, una investigación reproducible o un flujo de trabajo aprobado expresamente. Fija el modelo para que el enrutamiento no añada otra variable. Esto no vuelve determinista a un modelo de lenguaje; simplemente elimina una fuente de variación.

Si la configuración de un modelo concreto que ya conoces resuelve tu tarea acotada con pocas correcciones, no necesitas cambiar nada mientras una prueba no muestre una mejora práctica. No hay obligación de cambiar.

También conviene esperar si necesitas trabajar sin conexión o no puedes definir y revisar un cambio aceptable. Para solicitudes rutinarias muy pequeñas, quizá baste con mantener Standard y prescindir de los niveles que recurren más a la orquestación. «Dejar Max desactivado» y «dejar Fusion desactivado» son decisiones distintas.

Tutorial de GitHub Copilot Fusion: pruébalo en un repositorio esta semana

Acota la prueba lo suficiente para poder revisar cada resultado. Elige un repositorio que conozcas y compara Fusion con la configuración de modelos que ya utilizas.

Esta semana, asigna un desarrollador y un revisor a ese repositorio, acuerda las comprobaciones de aceptación y decide la configuración predeterminada después de examinar los cambios resultantes. Un registro claro de la decisión es más útil que una captura de pantalla de la respuesta más rápida.

Suscríbete al boletín para recibir guías prácticas sobre cómo elegir y utilizar herramientas de IA para el desarrollo de software.