GitHub eliminó Gemini 2.5 Pro y Gemini 3 Flash de todas las experiencias de Copilot el viernes. Los reemplazos son Gemini 3.1 Pro y Gemini 3.6 Flash.

El intercambio no es simétrico

Gemini 2.5 Pro era un modelo estable, generalmente disponible. Su sucesor designado, Gemini 3.1 Pro, está etiquetado como Preview. Los equipos que estandarizaron en un modelo estable están siendo trasladados a uno que lleva una etiqueta de vista previa, lo que, en la propia taxonomía de GitHub, significa que puede cambiar o desaparecer sin el aviso que recibe un modelo GA.

Qué cubre realmente el «no hace falta hacer nada»

El changelog dice que no hace falta hacer nada, y para la retirada eso es correcto: nada se rompe, los modelos simplemente dejan de aparecer. La misma entrada señala luego que los administradores de Copilot Enterprise pueden necesitar habilitar el acceso a los modelos alternativos a través de sus políticas de modelos. Esas dos frases no describen la misma situación. En una organización con una política de modelos restrictiva, los antiguos modelos Gemini desaparecen y los nuevos no quedan permitidos automáticamente, lo que deja a los desarrolladores con ninguna opción de Gemini en absoluto hasta que alguien con permisos de administrador se da cuenta.

El otro cambio publicado el mismo día

GitHub también puso en vista previa pública la asignación de políticas de modelos a enterprise-team: una empresa puede definir un conjunto base de modelos y conceder otros adicionales a equipos individuales, resuelto de la forma menos restrictiva. La mayoría de los clientes obtienen la opción de activarlo el 3 de agosto, por lo que el anuncio precede a su disponibilidad. Oculta en él hay una consecuencia que merece leerse dos veces: una vez habilitada la asignación a nivel de empresa, los ajustes de modelos a nivel de organización dejan de aplicarse. Las restricciones existentes de un administrador de la organización quedan anuladas silenciosamente por la política de empresa.

Por qué merece la pena leer una entrada del changelog

La disponibilidad de modelos dentro de una herramienta de programación es ahora una decisión de suministro tomada por el proveedor de la herramienta, no por el desarrollador. Qué modelos puede alcanzar un equipo, y en qué nivel de estabilidad, se decide dos niveles más arriba —por la plataforma y luego por un administrador de empresa— y cambia mediante entradas del changelog que nadie está obligado a leer.