GitHub Copilot retirará cuatro modelos: cómo preparar la migración sin improvisar

El 2 de octubre de 2026, GitHub tiene previsto retirar de Copilot Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code y Claude Opus 4.7. El aviso, publicado el 3 de septiembre, abarca Chat, las ediciones en línea, el modo de preguntas, el modo agente y las sugerencias de código. No se trata, por tanto, de cambiar una opción aislada en un menú: una organización puede tener dependencias repartidas entre preferencias personales, configuraciones administrativas, automatizaciones e integraciones.

GitHub propone tres rutas: pasar de Gemini 3.5 o 3.6 Flash a Gemini 3.8 Flash, de Kimi K2.7 Code a Kimi K3 y de Claude Opus 4.7 a Claude Opus 5. Son destinos recomendados, no sustitutos cuya equivalencia esté demostrada. Pertenecer a una misma familia tampoco garantiza idéntica calidad, latencia, uso del contexto o respuesta ante instrucciones ambiguas. La decisión sensata consiste en comprobar el trabajo que de verdad se realiza, no en aceptar una correspondencia nominal.

Primero, localizar las dependencias

El inventario debe distinguir tres formas de elección. Hay una dependencia explícita cuando una integración, un procedimiento interno o una persona fija un modelo concreto. La dependencia predeterminada nace de una configuración que abre cada conversación con un modelo establecido. La implícita aparece cuando el equipo cree no haber elegido nada, pero en realidad depende de una política heredada, de la disponibilidad del plan o de la selección automática.

Conviene revisar por separado cada experiencia mencionada en el aviso. Un equipo puede usar Claude Opus 4.7 en conversaciones complejas, Gemini Flash para cambios en línea y sugerencias de código sin saber qué modelo está configurado en cada caso. GitHub indica que no será necesario eliminar manualmente los modelos antiguos después de su retirada, pero sí pide actualizar los flujos de trabajo y las integraciones antes del 2 de octubre. Esperar a que desaparezcan transforma una comprobación planificada en una incidencia con fecha conocida.

El inventario útil no termina con una lista de nombres. Para cada uso debe registrar quién lo mantiene, en qué experiencia de Copilot aparece, si la elección es explícita o heredada, qué plan y cliente intervienen y qué tarea concreta resuelve. También debe señalar cómo se reconocerá un fallo y quién puede cambiar la configuración. Así se evita que una prueba satisfactoria en Chat se interprete como validación de las ediciones en línea, del modo agente o de las sugerencias de código.

Revisar políticas y clientes antes de probar

En Copilot Business y Enterprise, la alternativa puede no estar habilitada aunque figure en la documentación de modelos compatibles. El propietario de la empresa puede imponer la configuración, delegarla a una organización o dejar que se herede de la disponibilidad predeterminada. Por eso hay que comprobar tanto el ajuste administrativo como el selector que ve una persona real. Una captura de la consola no demuestra por sí sola que el modelo sea utilizable en el flujo previsto.

Kimi K3 exige una atención adicional: pertenece al grupo de modelos de pesos abiertos, desactivados de forma predeterminada para Business y Enterprise con independencia del ajuste general de disponibilidad. Puede permitirse expresamente si no hay otras restricciones. Si se elige como destino, esa autorización forma parte de la migración; no debe descubrirse durante el despliegue.

La etiqueta de disponibilidad general tampoco garantiza acceso en todos los planes, clientes o superficies. La documentación consultada el 6 de septiembre marca como disponibles tanto los modelos que se retirarán como las alternativas, pero advierte de diferencias por plan y cliente. Además, los modelos nuevos pueden exigir versiones recientes del entorno o de sus extensiones. La tabla de versiones mínimas es provisional: para Gemini 3.8 Flash todavía presenta datos pendientes; para Kimi K3 señala VS Code 1.131 y para Claude Opus 5, VS Code 1.128.0.

Antes de comparar respuestas, el equipo debe confirmar cuatro cosas en el entorno donde trabaja: que la política permite el modelo, que el plan lo incluye, que el cliente cumple la versión requerida y que el selector realmente lo ofrece. Esta verificación separa los problemas de acceso de los problemas de calidad y evita atribuir al modelo un fallo causado por una configuración incompleta.

Comparar tareas, no demostraciones

GitHub explica que la elección del modelo influye en la calidad y la pertinencia de las respuestas, y que los modelos difieren en latencia, propensión a inventar información y adecuación a cada tarea. Es una orientación del proveedor, no una evaluación independiente ni una prueba del repositorio propio. La comparación decisiva debe hacerse con ejemplos representativos del trabajo cotidiano.

La muestra puede reunir correcciones pequeñas, cambios en varios archivos, explicación de código heredado, generación de pruebas, revisión de una propuesta y una tarea de agente con varias etapas. No hace falta convertirla en una competición abstracta. Sí hace falta conservar la misma entrada, el mismo contexto disponible y criterios de aceptación comparables para el modelo anterior y el candidato. Cuando una tarea admite distintas soluciones válidas, la evaluación debe centrarse en el resultado que el equipo pueda revisar y utilizar.

Cada caso necesita un desenlace observable: pruebas que pasan, modificación limitada al alcance solicitado, referencias correctas a archivos y funciones, ausencia de cambios innecesarios y explicación suficiente para revisar la propuesta. También conviene anotar el tiempo hasta obtener una respuesta aprovechable, las correcciones humanas requeridas y los casos en que hubo que repetir la instrucción. Estos datos describen mejor el coste operativo que una impresión general sobre cuál respuesta «parece más inteligente».

No deben inventarse resultados ni extrapolarse los de una superficie a otra. Si una integración usa el modelo mediante el modo agente, una prueba en Chat solo sirve como indicio. Si el riesgo está en las sugerencias de código, hay que observar esa experiencia. La prueba debe reproducir las restricciones relevantes del entorno, incluidas las políticas y la versión del cliente, porque una comparación realizada en condiciones distintas puede ocultar el problema que aparecerá después.

El precio por token no es el coste por tarea aceptada

La tabla de GitHub consultada el 6 de septiembre ofrece una fotografía concreta, no una previsión de la factura. Por cada millón de tokens, Gemini 3.5 Flash figura con 1,50 dólares de entrada, 0,15 de entrada almacenada en caché y 9 de salida. Gemini 3.6 Flash y Gemini 3.8 Flash comparten tarifas de 0,75, 0,075 y 3,75 dólares, respectivamente.

Kimi K2.7 Code aparece con 0,95 dólares de entrada, 0,19 de caché y 4 de salida; Kimi K3, con 3, 0,30 y 15 dólares. Claude Opus 4.7 y Claude Opus 5 muestran las mismas cifras: 5 dólares de entrada, 0,50 de entrada en caché, 6,25 de escritura en caché y 25 de salida. Que dos modelos tengan la misma tarifa no significa que consuman la misma cantidad de tokens ni que cuesten lo mismo para completar satisfactoriamente una tarea.

GitHub indica asimismo que un crédito de IA equivale a 0,01 dólares y que las sugerencias de código y de la siguiente edición no consumen esos créditos. Aun así, la repercusión final depende del plan, la función utilizada, el volumen de entrada y salida y el uso de la caché. Todas estas cifras pueden cambiar y deben volver a comprobarse antes de tomar una decisión o publicar un presupuesto.

La comparación económica más útil relaciona consumo y resultado. Para cada tarea de la muestra, se puede registrar cuántos intentos fueron necesarios, cuánto trabajo humano quedó pendiente y si la salida llegó a aceptarse. Un modelo con una tarifa de salida menor puede resultar más caro si obliga a repetir la consulta o a rehacer buena parte de la respuesta; uno con una tarifa mayor puede compensarlo si entrega más casos utilizables a la primera. Sin mediciones propias no hay base para afirmar ninguna de las dos cosas.

También conviene separar los usos interactivos de los automatizados. En una conversación, una persona puede detectar pronto una respuesta desviada y corregir el rumbo. En una automatización, el mismo desvío puede propagarse hasta una etapa posterior y consumir más contexto antes de fallar. El presupuesto de prueba debe reflejar esa diferencia y reservar límites claros de tiempo, consumo y reintentos.

El resultado no tiene que ser un ganador universal. Puede ser razonable asignar un candidato a cambios rápidos y otro a tareas extensas, siempre que la política, el plan y el cliente permitan esa elección. Lo importante es documentar qué evidencia respalda cada decisión y en qué condiciones dejaría de ser válida.

Auto puede ayudar, pero no reproduce una selección fija

La selección automática elige un modelo según la disponibilidad, el estado de los sistemas y la complejidad de la tarea, dentro de los límites del plan y de las políticas aplicables. En las interfaces compatibles puede consultarse qué modelo se utilizó. Eso permite incluir Auto en la prueba como posible opción de respaldo, pero no tratarlo como garantía de continuidad para un flujo que antes fijaba un modelo concreto.

El conjunto al que recurre Auto puede cambiar, y dos solicitudes semejantes no tienen por qué terminar siempre en el mismo modelo. Si una integración depende de características particulares, el equipo debe comprobar si acepta esa variación. Si lo importante es mantener el servicio ante una indisponibilidad, Auto puede ofrecer una flexibilidad valiosa, pero solo después de superar los mismos casos de prueba y con un método para identificar el modelo empleado cuando haya que investigar un resultado.

Desde el 2 de septiembre, las configuraciones administradas por empresas permiten establecer cualquier modelo disponible como opción predeterminada para conversaciones nuevas y modificarla por equipo empresarial. GitHub anunció esta capacidad con disponibilidad general para Business y Enterprise en la aplicación Copilot, la interfaz de línea de comandos y VS Code. Ese alcance no debe extenderse a otras superficies que el anuncio no menciona.

El modelo predeterminado, una elección expresa y Auto son dependencias distintas. Cambiar el primero no corrige necesariamente una automatización que fija un identificador ni modifica una selección que una persona ya realiza de forma explícita. La revisión debe seguir cada ruta por separado y confirmar el comportamiento desde la cuenta y el cliente que se usarán en producción.

Desplegar por etapas y conservar una salida

Una migración prudente comienza con un grupo pequeño y tareas de bajo impacto. Antes de ampliarla, conviene comparar los resultados con los criterios definidos, revisar errores y confirmar que el consumo permanece dentro del límite previsto. El despliegue puede avanzar por equipo, repositorio o tipo de tarea, según dónde estén las dependencias y quién pueda observarlas con claridad.

La alternativa de respaldo debe estar lista antes del cambio, no solo anotada en un documento. Eso implica que esté permitida por las políticas, disponible en el plan, visible en el cliente y probada con una muestra suficiente. También hace falta una instrucción operativa breve: quién decide volver atrás, qué señal activa esa decisión, qué configuración debe cambiar y cómo se comprueba que el servicio ha recuperado un estado aceptable.

Volver atrás no siempre significará regresar al modelo que se retira, sobre todo cuando llegue el 2 de octubre. Puede consistir en pasar al otro candidato ya validado, usar Auto dentro de límites conocidos o suspender temporalmente una automatización de riesgo. Preparar esa salida evita depender de una opción que dejará de existir y obliga a resolver con antelación permisos, versiones y responsables.

Durante el despliegue deben observarse tanto los fallos evidentes como el deterioro gradual: más repeticiones, respuestas que requieren una revisión mayor, demoras que interrumpen el flujo o un aumento del coste por tarea aceptada. Ninguna métrica aislada basta. El objetivo es detectar si el nuevo comportamiento sigue siendo útil en las condiciones reales para las que se aprobó.

Una ruta práctica hasta el 2 de octubre

En la primera fase, el equipo identifica todos los usos de los cuatro modelos, asigna responsables y clasifica cada dependencia como explícita, predeterminada o implícita. A continuación verifica políticas, planes, versiones y selectores. Solo entonces elige candidatos y prepara una muestra que cubra cada experiencia afectada.

La segunda fase ejecuta las comparaciones con entradas y criterios coherentes. Registra calidad utilizable, latencia observada, correcciones humanas, reintentos y consumo, sin presentar la documentación comercial como si fuera un resultado propio. Las tarifas se conservan con fecha, porque son una instantánea y no una promesa.

La tercera fase habilita el destino elegido para un grupo limitado y deja preparada una opción de respaldo. Los responsables revisan los indicadores acordados y amplían el cambio únicamente cuando la evidencia lo justifica. Las integraciones y los procedimientos internos se actualizan antes de la fecha límite; no se espera a que GitHub retire los modelos para descubrir qué seguía dependiendo de ellos.

Al cerrar la migración, conviene guardar el inventario, los casos de prueba, la decisión y sus límites. Ese registro servirá cuando cambien la disponibilidad, las políticas, las versiones mínimas o las tarifas. También permite distinguir una nueva incidencia de una suposición antigua que ya no se cumple.

El 2 de octubre es una fecha de retirada prevista, no la prueba de que los modelos ya hayan desaparecido. Hasta que llegue, la formulación y el plan deben reflejar ese carácter futuro, y el aviso debe comprobarse de nuevo antes de actuar. La ventaja de empezar ahora no es adivinar cuál alternativa será mejor, sino llegar con una decisión ensayada, un despliegue controlado y una salida viable.