GitHub fijó para el 2 de octubre de 2026 la retirada de cuatro modelos de GitHub Copilot: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code y Claude Opus 4.7. GitHub indica que el cambio se aplica a las experiencias de Copilot que enumera, entre ellas Chat, ediciones inline, modos ask y agent y completions. Para evitar una sustitución de último momento, la migración debe abordarse en dos frentes: elegir el reemplazo adecuado para el tipo de tarea y confirmar que el nuevo modelo está permitido por las políticas de la organización o empresa.
El anuncio del 3 de septiembre ya ofrece un reemplazo recomendado para cada modelo: Gemini 3.8 Flash para las dos versiones Gemini que se retiran, Kimi K3 para Kimi K2.7 Code y Claude Opus 5 para Claude Opus 4.7. GitHub también advierte que los administradores de Copilot Business y Copilot Enterprise pueden tener que habilitar los modelos alternativos en las políticas de modelos. La referencia principal es el changelog oficial de retirada de GitHub.
Qué modelos se retiran y qué migración recomienda GitHub
| Modelo retirado | Fecha | Alternativa sugerida por GitHub | Escenario de uso más cercano |
|---|---|---|---|
| Gemini 3.5 Flash | 02/10/2026 | Gemini 3.8 Flash | Respuestas rápidas, pequeñas ediciones, dudas de sintaxis y tareas ligeras o repetitivas |
| Gemini 3.6 Flash | 02/10/2026 | Gemini 3.8 Flash | Respuestas rápidas, pequeñas ediciones, dudas de sintaxis y tareas ligeras o repetitivas |
| Kimi K2.7 Code | 02/10/2026 | Kimi K3 | Flujos agentic de varios pasos y trabajo de contexto largo en bases de código más grandes |
| Claude Opus 4.7 | 02/10/2026 | Claude Opus 5 | Razonamiento profundo, depuración compleja y análisis de problemas de varios pasos |
La columna de escenarios no se basa solo en los nombres. La propia documentación comparativa de Copilot clasifica Gemini 3.8 Flash como opción de ayuda rápida para tareas simples o repetitivas; Kimi K3 como modelo de programación agentic y contexto largo; y Claude Opus 5 como modelo de razonamiento profundo y debugging. Conviene revisar la comparación oficial de modelos antes de estandarizar una elección para todo el equipo.
Gemini 3.5 y 3.6 Flash: la migración más directa es a Gemini 3.8 Flash
Para quienes usan Gemini 3.5 Flash o Gemini 3.6 Flash en tareas cortas, el reemplazo sugerido por GitHub es la migración más directa del grupo. GitHub lanzó Gemini 3.8 Flash en Copilot el 3 de septiembre y lo describe en su documentación comparativa como apropiado para respuestas rápidas y tareas ligeras. Encaja con flujos que priorizan baja latencia: pequeños cambios, funciones utilitarias, preguntas de sintaxis, explicaciones breves y prototipos rápidos.
En Copilot Business y Enterprise, Gemini 3.8 Flash puede estar ya disponible cuando la política de habilitación predeterminada de modelos publicados está activa. En el anuncio de disponibilidad del modelo, GitHub explica que los modelos nuevos se habilitan automáticamente con la configuración predeterminada, salvo que un administrador desactive esa regla global o bloquee explícitamente el modelo. Por eso, la tarea del admin no siempre es “activar” Gemini 3.8 Flash, sino confirmar su estado real de política antes del plazo.
Kimi K2.7 Code: Kimi K3 exige atención especial de los administradores
La migración de Kimi K2.7 Code a Kimi K3 requiere una precaución adicional. GitHub posiciona Kimi K3 para programación agentic de varios pasos y trabajo de contexto largo en grandes bases de código. Puede ser una evolución natural para flujos que dependen de explorar repositorios, planificar cambios conectados y ejecutar tareas que atraviesan varios archivos.
Sin embargo, existe una diferencia importante de gobernanza. En la política de disponibilidad predeterminada de Copilot, GitHub incluye a los modelos de pesos abiertos, entre ellos Kimi K3, entre los que quedan deshabilitados por defecto y no se activan automáticamente solo porque esté habilitada la política “Default availability for released models”. En una organización o enterprise, el administrador debe revisar la página de Models y habilitar Kimi K3 explícitamente cuando la política de nivel superior lo permita. La documentación relevante es About default availability of Copilot models.
GitHub también publica consideraciones específicas sobre Kimi K3 y recomienda que las empresas evalúen capacidades, limitaciones y salvaguardas según sus propios requisitos. Por eso, una migración corporativa no debería limitarse a sustituir el nombre del modelo: conviene probar tareas reales, comportamiento agentic, encaje con políticas de seguridad y compatibilidad con los clientes que utiliza el equipo.
Claude Opus 4.7: Claude Opus 5 mantiene el foco en razonamiento profundo
Para Claude Opus 4.7, GitHub recomienda Claude Opus 5. Ambos se sitúan en el área que GitHub asocia con razonamiento profundo y depuración: problemas complejos, grandes refactorizaciones, decisiones de arquitectura, análisis de varios archivos e investigación del comportamiento de sistemas.
Eso no significa que las respuestas sean idénticas. Un cambio de generación puede modificar estilo, latencia, consumo de créditos, uso de herramientas y resultados de prompts que ya estaban afinados. Si el equipo tiene prompts, instrucciones de repositorio, agentes o automatizaciones calibrados para Opus 4.7, conviene ejecutar un conjunto de regresión con tareas representativas antes de establecer Opus 5 como modelo predeterminado.
Qué debe cambiar el usuario antes del 2 de octubre
- Inventariar todos los lugares donde el modelo está fijado. Revisar selectores de modelo en Chat, configuraciones de completions, instrucciones de agentes, automatizaciones, integraciones y cualquier flujo con referencia explícita a uno de los cuatro modelos.
- Cambiar al reemplazo sugerido y probarlo en el mismo cliente. La disponibilidad varía por plan y superficie. La tabla de modelos compatibles en Copilot es la referencia para comprobar plan, cliente y estado.
- No asumir que cambiar el modelo de Chat cambia las sugerencias inline. GitHub documenta estas selecciones por separado. Cambiar el modelo de Chat no cambia el modelo de sugerencias inline; cuando el cliente lo permite, el modelo de completions se configura en su propio selector.
- Actualizar clientes y extensiones. GitHub exige versiones compatibles del IDE y de la extensión de Copilot para cambiar modelos de sugerencias inline.
- Comparar calidad, latencia y coste. Diferentes modelos pueden consumir créditos de manera distinta. Un reemplazo técnicamente compatible puede no ser la mejor elección económica para todas las tareas.
Checklist para administradores de Copilot Business y Enterprise
- Abrir la configuración de Copilot de la organización o enterprise y revisar el área de Models.
- Confirmar que Gemini 3.8 Flash, Kimi K3 y Claude Opus 5 aparecen como opciones compatibles con el plan y con los clientes usados por el equipo.
- Comprobar si algún modelo está impuesto como Enabled o Disabled en el nivel enterprise; una organización no puede sobrescribir una decisión superior.
- Para Gemini 3.8 Flash y Claude Opus 5, verificar si la política de disponibilidad predeterminada o una configuración explícita ya concede acceso.
- Para Kimi K3, hacer una comprobación explícita: al estar listado entre los modelos de pesos abiertos, no participa en la habilitación automática predeterminada.
- Si los usuarios necesitan elegir modelos manualmente, confirmar que la política de la organización permite esa selección en las superficies relevantes.
- Revisar la configuración de modelo predeterminado en entornos gestionados. Desde el 2 de septiembre, GitHub permite establecer cualquier modelo compatible como predeterminado mediante enterprise-managed settings; un valor que aún apunte a un modelo que se retirará debe actualizarse.
- Hacer una prueba piloto con usuarios representativos y documentar un fallback si un modelo no está disponible en un cliente concreto.
Las instrucciones oficiales de gobernanza están en Managing the availability of models in an organization y Configuring access to AI models in GitHub Copilot.
Cómo probar la migración sin romper el flujo
Use un pequeño conjunto de pruebas que represente el trabajo real del equipo. Para Gemini 3.8 Flash, mida si las pequeñas ediciones, respuestas de sintaxis y generación de código utilitario siguen siendo rápidas y correctas. Para Kimi K3, pruebe navegación por repositorios más grandes, tareas agentic de varios pasos y cambios distribuidos entre múltiples archivos. Para Claude Opus 5, priorice bugs difíciles, decisiones de arquitectura, refactorizaciones y análisis de logs o comportamiento sistémico.
Además de la calidad de salida, registre latencia, frecuencia de reprompt, consumo de créditos, uso de herramientas y diferencias de comportamiento con instrucciones existentes. El objetivo es descubrir antes del 2 de octubre si el reemplazo sugerido por GitHub es suficiente o si hay que adaptar prompts y procedimientos.
Auto puede reducir la dependencia de un modelo fijo, pero sigue sujeto a políticas
Para flujos que no exigen un proveedor específico, el selector Auto puede reducir la dependencia de un nombre de modelo. GitHub afirma que la selección automática tiene en cuenta la tarea y la disponibilidad y puede evitar modelos degradados o no disponibles. Aun así, Auto solo elige entre modelos compatibles con el plan y permitidos por las políticas administrativas. No evita un bloqueo ni garantiza que se use una familia concreta.
Antes de adoptar Auto como respuesta universal a la retirada, compruebe si el flujo depende de comportamiento reproducible, coste predecible, una familia de modelo específica o requisitos de compliance. La referencia oficial es About Copilot auto model selection.
Qué ocurre después del plazo
GitHub afirma que no es necesario hacer nada para eliminar los modelos después de que sean retirados. La acción necesaria es la contraria: actualizar flujos e integraciones a modelos compatibles antes del 2 de octubre de 2026. En organizaciones con políticas restrictivas, el paso crítico es no esperar a que los usuarios descubran la indisponibilidad el mismo día del cambio.
En resumen: migre Gemini 3.5/3.6 Flash a Gemini 3.8 Flash, Kimi K2.7 Code a Kimi K3 y Claude Opus 4.7 a Claude Opus 5; pruebe cada reemplazo en el cliente realmente usado; y, en Business o Enterprise, valide las políticas con atención especial a Kimi K3. Esa secuencia convierte la retirada de modelos en un cambio controlado, en lugar de una interrupción del workflow.
