GitHub confirmó el 1 de julio de 2026 la fecha que cambia el calendario de cualquier prototipo conectado a GitHub Models: el servicio se retirará por completo el 30 de julio. No es solo el playground. Desaparecerán el catálogo de modelos, la API de inferencia, los endpoints de bring your own key (BYOK) y la interfaz asociada. El retiro también afecta a clientes existentes con uso activo.

La urgencia es operativa: GitHub programó interrupciones breves, o brownouts, para el 16 y el 23 de julio. El primero ya pasó; el segundo todavía sirve como prueba de fallo controlado antes del apagado definitivo.

Mapa editorial de una migración de agente desde un endpoint de GitHub Models hacia una ruta de inferencia alternativa

Qué se rompe exactamente

GitHub Models era una superficie cómoda para experimentar con modelos desde el ecosistema de GitHub: un catálogo para elegir, un playground para comparar respuestas y una API para convertir el experimento en código. La comunicación oficial dice que los cuatro componentes quedarán fuera de servicio después del 30 de julio, incluso para organizaciones que ya los usen.

Eso puede afectar más cosas de las que aparecen en el package.json. Un agente puede tener una variable como GITHUB_TOKEN, un endpoint construido en código, un secret de CI, un notebook de evaluación o un prompt guardado en el repositorio que todavía asume que el catálogo existe. Si solo buscas la cadena models.inference.ai.azure.com, puedes dejar fuera configuraciones, documentación interna y pruebas manuales.

La primera tarea es hacer inventario:

busca URLs, hosts, SDKs y variables relacionadas con GitHub Models en el código y en los workflows de GitHub Actions;
revisa secretos y variables de entorno usados por entornos de preview, no solo producción;
identifica evaluaciones que hayan fijado un modelo o un multiplicador de costo del catálogo;
separa inferencia de desarrollo, pruebas automáticas y tráfico de usuario.

La migración no es cambiar una URL

GitHub recomienda mirar Microsoft Foundry para acceso a un catálogo de modelos y GitHub Copilot para flujos de IA dentro de GitHub. Son destinos distintos. Foundry puede servir como capa de inferencia para una aplicación propia; Copilot no es un reemplazo transparente de una API que tu backend llama durante una conversación.

Antes de escoger, documenta el contrato que tu agente necesita:

identificador de modelo y proveedor;
formato de mensajes y llamadas a herramientas;
límites de contexto y tamaño de respuesta;
streaming, structured output y reintentos;
autenticación, región, cuotas y retención de datos;
costo por tarea completa, no solo por millón de tokens.

La prueba mínima debe ejecutar una muestra de tareas reales: una consulta simple, una llamada de herramienta, un caso largo y un fallo de proveedor. Guarda la respuesta estructurada, latencia, tokens y errores. Si tu agente usa tool calling, no aceptes la migración solo porque el modelo respondió texto: valida que los argumentos sigan el esquema y que el sistema no cambie silenciosamente de proveedor en mitad de una sesión.

Checklist editorial para probar brownouts, cuotas, autenticación y llamadas de herramientas durante una migración de modelos

Qué probar antes del 30 de julio

Usaría el 23 de julio como ensayo de continuidad: apunta un entorno de staging al flujo actual, registra cada error y confirma que tu fallback se activa sin repetir acciones peligrosas. El fallback debe ser idempotente; un reintento después de un timeout no puede crear dos tickets, dos cobros ni dos despliegues.

También revisaría las evaluaciones. Si solo mediste calidad dentro del playground, exporta los casos y ejecútalos contra el reemplazo. La comparación debe incluir exactitud, selección de herramientas, costo, latencia y necesidad de intervención humana. Un modelo puede verse parecido en conversación y comportarse distinto cuando recibe JSON, contexto largo o permisos limitados.

Si mantienes un prototipo de GitHub Models para aprendizaje, puedes dejarlo archivado con una nota de fecha. Si alimenta un agente compartido, una demo pública o una tarea de CI, trátalo como dependencia con fecha de caducidad y no como una integración “temporal”.

No hay SEO tooling conectado en esta corrida, así que no invento volumen. La demanda se infiere de la alerta oficial, la fecha límite, las búsquedas probables como GitHub Models retirement, GitHub Models API migration y Microsoft Foundry models, y el riesgo concreto para builders que ya tienen código ejecutable.

Si todavía estás ordenando herramientas, permisos y validaciones antes de conectar un modelo nuevo, puedes empezar por el curso gratis. La regla para esta migración es simple: primero descubre dónde vive la dependencia; después cambia el proveedor; por último demuestra que el agente falla de forma segura.