GitHub avisó el 2 de julio de 2026 que Gemini 2.5 Pro y Gemini 3 Flash serán retirados de todas las experiencias de GitHub Copilot el 31 de julio de 2026. La lista incluye Copilot Chat, inline edits, ask mode, agent mode y code completions.

El reemplazo sugerido es directo: Gemini 3.1 Pro por Gemini 2.5 Pro y Gemini 3.5 Flash por Gemini 3 Flash. Pero para un equipo que usa Copilot como parte de flujos agentic, el trabajo real no termina en escoger el nuevo nombre del modelo.

Matriz editorial de políticas de Copilot con modelos Gemini actuales, alternativas y estados de aprobación por equipo

La fecha que sí importa

El 31 de julio no es una fecha decorativa. Si tienes prompts, instrucciones de equipo, automatizaciones, agentes personalizados o documentación interna que dicen “usa Gemini 2.5 Pro para investigación” o “usa Gemini 3 Flash para tareas rápidas”, esa referencia queda vieja en menos de un mes.

GitHub también advierte que los administradores de Copilot Enterprise pueden necesitar habilitar las alternativas en políticas de modelos. Ese punto es clave: no basta con que GitHub sugiera el reemplazo si la organización todavía no permite ese modelo.

Por qué esto afecta más a agentes que a chat

Cuando una persona usa chat, puede notar rápido que el modelo cambió. En un agente, el cambio puede quedar escondido en:

una sesión de cloud agent;
una tarea desde CLI;
un flujo que crea PRs;
una revisión automática;
o una política de organización.

Si el modelo alternativo responde distinto, usa más créditos, falla más en edición o cambia latencia, el síntoma puede aparecer como “el agente se volvió menos confiable” aunque la causa sea una migración de modelo.

Checklist de migración antes del 31 de julio

No esperaría al último día. Haría una migración pequeña con evidencia:

inventariar dónde se usa Gemini dentro de Copilot;
confirmar si Gemini 3.1 Pro y Gemini 3.5 Flash están habilitados por política;
correr tres tareas reales con el modelo viejo y el nuevo;
medir calidad de diff, costo en créditos, latencia y retrabajo humano;
actualizar instrucciones internas, prompts y docs de onboarding;
dejar una nota de rollback si el modelo alternativo falla en una tarea crítica.

Mesa editorial con ejecuciones comparadas, resultados de pruebas y revisión humana para migrar modelos de Copilot

Qué probaría en concreto

Para Gemini 3.1 Pro, probaría tareas de debugging y cambios con contexto amplio: leer un bug, tocar dos o tres archivos y explicar por qué la solución pasa tests. No lo evaluaría con una pregunta suelta.

Para Gemini 3.5 Flash, probaría tareas repetitivas y rápidas: explicar código, proponer cambios pequeños, completar snippets y responder preguntas de documentación. La pregunta es si mantiene suficiente precisión a menor costo o menor latencia.

La documentación de GitHub ya organiza modelos por áreas de tarea: coding general, tareas rápidas, razonamiento profundo, trabajo con visuales y desarrollo agentic. Esa tabla no reemplaza tus evals, pero sirve como punto de partida para no comparar modelos con una prueba equivocada.

La lectura útil para equipos

Esta noticia no dice que Gemini deje de servir para Copilot. Dice algo más operativo: el selector de modelos es una dependencia viva. Si tus agentes dependen de un modelo específico, también dependen de su calendario de disponibilidad, sus políticas y su facturación.

La demanda de búsqueda se infiere por la fecha límite, el alcance sobre todas las superficies de Copilot y las consultas obvias que vendrán de admins y builders: Gemini 2.5 Pro Copilot deprecation, Gemini 3 Flash Copilot, Copilot model policy Gemini y GitHub Copilot Gemini 3.1 Pro.

Mi recomendación: trata la migración como un cambio de runtime. Hazla con pruebas pequeñas, evidencia y comunicación interna. Si todavía estás diseñando cómo evaluar agentes antes de confiarles cambios reales, empieza por el curso gratis y cruza esta nota con benchmarks de IA para elegir modelo de agente.