Lista de verificación Grep tras la retirada de seis modelos de Copilot
Trata los nombres de modelos como dependencias: busca en el código, CI y archivos de agentes los nombres retirados, sustitúyelos por los reemplazos indicados y verifica el selector.
Un agente de Copilot puede no devolver nada un martes tranquilo porque un nombre de modelo en una configuración de CI dejó de ser seleccionable. GitHub eliminó ciertos modelos de Copilot el 1 de septiembre de 2026, afectando a la mayoría de las funciones de Copilot, incluida la chat, la edición en línea, la función ask, el agente y la autocompletado de código. Los nombres están en el código, las configuraciones de CI y las definiciones de agentes, por lo que la respuesta es una breve pasada de grep y verificación: encontrar los nombres retirados, sustituirlos por los reemplazos indicados y confirmar que el reemplazo aparece en el selector de modelos antes de que los flujos de trabajo se rompan.
Una retirada es un evento de operaciones
El modo de fallo no es glamoroso. Un desarrollador abre Copilot Chat, elige un modelo y la opción ha desaparecido. Un trabajo de CI llama a un agente con una cadena de modelo codificada en duro, y el trabajo falla después de que el código ya se ha compilado. Un compañero actualiza un archivo, pero el mismo nombre sigue en un flujo de trabajo, una plantilla de prompt o un script local. La solución es mecánica, pero solo funciona si el equipo sabe dónde buscar. La pasada debería llevar minutos, no un proyecto, y debería dejar un registro que el próximo documento de incorporación pueda usar.
La lista de verificación es el artefacto permanente. Es lo suficientemente breve para ejecutarla en un día laboral normal y lo suficientemente específica para evitar una reunión sobre qué sucesor elegir. La reunión solo es para las excepciones: un equipo que quiere un nivel de Opus diferente, un repositorio que no se puede tocar sin una congelación de liberación, o un flujo de trabajo que necesita un propietario diferente.
Una sola lista cubre el barrido, los intercambios y las verificaciones
Ejecuta los elementos en orden. El barrido tiene que ocurrir antes de los intercambios, y las verificaciones tienen que ocurrir después de los cambios de configuración. Si un nombre aparece en más de un repositorio, registra el repositorio y el archivo antes de sustituirlo.
- Busca con grep en repositorios, configuraciones de CI y definiciones de agentes los seis modelos retirados: Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6 y Raptor Mini.
- Sustituye Claude Sonnet 4.5 o Claude Sonnet 4.6 por Claude Sonnet 5.
- Sustituye Raptor Mini por MAI-Code-1-Flash.
- Sustituye Claude Opus 4.5 o Claude Opus 4.6 por Claude Opus 4.7, Claude Opus 4.8 o Claude Opus 5.
- Sustituye Gemini 3.1 Pro por Gemini 3.6 Flash.
- Confirma que el reemplazo aparece en el selector de modelos.
- Claude Sonnet 4.6 siguió siendo accesible para las suscripciones personales de GitHub Copilot con facturación anual después de la retirada del 1 de septiembre de 2026.
El barrido detecta nombres codificados en duro en prompts, scripts, pasos de CI y definiciones de agentes. Los intercambios impiden que el cambio se convierta en un juego de adivinanzas sobre qué sucesor es apropiado. Las verificaciones evitan que una compilación en verde oculte un agente roto. Si el selector muestra el reemplazo, el cambio de configuración está hecho; si no, el ticket sigue abierto.
El selector es la prueba más rápida
Un reemplazo puede estar nombrado en un documento y seguir ausente de la interfaz. Un equipo puede actualizar la configuración, ejecutar la pipeline y asumir que el modelo está disponible. Entonces el agente devuelve un error solo cuando un usuario lo prueba. El selector es el lugar más rápido para ver si el reemplazo es realmente alcanzable. También es la prueba más fácil de mostrar en una standup: una captura de pantalla, un nombre de modelo, una fecha.
Los archivos de configuración de agentes de Copilot son el lugar silencioso donde un nombre de modelo sobrevive. Una pipeline de CI puede pasar porque el código se compila, mientras que el agente sigue apuntando a un modelo retirado. El paso de verificación pertenece a la lista de verificación, no a una revisión posterior de incidentes. Colócalo junto al paso de CI que llama al agente, para que la persona que cambia el modelo también compruebe el selector.
Mantén la lista de verificación junto a los otros runbooks. Cuando un proveedor cambia el catálogo de modelos, el equipo no debería estar debatiendo si el cambio importa. Los nombres ya están en la lista, los reemplazos ya están nombrados y el paso de verificación ya está escrito. El trabajo es ejecutarlo, registrar el resultado y cerrar el ticket. Escribe el resultado en el mismo lugar donde el equipo sigue otros cambios de infraestructura: una nota breve con la fecha, los repositorios revisados y el reemplazo utilizado es suficiente.