Durante casi dos años, la conversación alrededor de GitHub Copilot giró siempre sobre la misma pregunta:
¿Qué modelos soporta GitHub?
Con la última actualización para JetBrains, la pregunta cambia por completo.
Ahora pasa a ser:
¿Qué modelo querés conectar vos?
GitHub incorporó soporte para endpoints compatibles con la API de OpenAI, permitiendo que Copilot utilice modelos externos siempre que expongan esa interfaz.
Puede parecer un cambio pequeño de configuración. En realidad, es un cambio de arquitectura.
Copilot empieza a comportarse más como un harness para modelos que como un producto atado a un proveedor específico.
Y eso abre posibilidades muy interesantes para equipos que están construyendo plataformas internas de IA.
¿Qué anunció GitHub?
La actualización para los IDEs de JetBrains incorpora varias novedades importantes:
- configuración de endpoints compatibles con OpenAI;
- uso de claves propias (BYOK);
- instalación de plugins desde marketplace o repositorios;
- soporte para agentes y skills;
- integración más profunda con Claude como proveedor.
Pero la característica que cambia las reglas del juego es la primera.
En lugar de enviar todas las solicitudes exclusivamente a la infraestructura de GitHub, ahora es posible dirigirlas hacia cualquier servicio que implemente el mismo protocolo.
Eso incluye tanto proveedores comerciales como infraestructura propia.
¿Qué significa “compatible con OpenAI”?
No significa utilizar modelos de OpenAI.
Significa únicamente implementar la misma API.
Hoy existen decenas de servidores que exponen ese estándar.
Por ejemplo:
- vLLM
- Ollama
- LM Studio
- LiteLLM
- OpenRouter
- gateways corporativos
- plataformas internas de inferencia
Desde el punto de vista de Copilot, todos pueden verse exactamente igual.
Un ejemplo con vLLM
Supongamos que una empresa quiere utilizar Qwen, DeepSeek, Llama o Mistral sin enviar código fuente a un proveedor externo.
Puede desplegar un servidor con vLLM.
vllm serve Qwen/Qwen3-Coder-480B
Ese servidor expone un endpoint compatible con OpenAI.
En JetBrains simplemente se configura:
Base URL:
http://mi-servidor:8000/v1
API Key:
xxxxxxxx
Y listo.
Copilot pasa a utilizar ese modelo.
No cambia la experiencia del desarrollador.
Cambia el backend.
También funciona con Ollama
Para equipos pequeños incluso resulta más simple.
Instalar Ollama:
brew install ollama
Descargar un modelo:
ollama pull qwen3-coder
Levantar el servidor:
ollama serve
Ollama ya publica una API compatible.
En ese momento JetBrains puede consumir el modelo exactamente igual que consumiría GPT o Claude.
Todo permanece local.
¿Por qué esto es importante?
Porque durante mucho tiempo existieron dos caminos:
Opción 1
Usar Copilot.
Obtener una experiencia integrada.
Aceptar los modelos disponibles.
Opción 2
Usar modelos propios.
Perder integración.
Construir herramientas internas.
Ahora ambos caminos empiezan a converger.
El IDE deja de estar atado al modelo
Ese es probablemente el cambio conceptual más importante.
Hasta ahora elegíamos un IDE y automáticamente heredábamos los modelos disponibles.
Con esta actualización ocurre lo contrario.
Elegimos el modelo.
Y el IDE simplemente lo consume.
La relación empieza a invertirse.
Casos donde esto tiene mucho sentido
1. Open Weights
Muchas organizaciones quieren ejecutar modelos propios.
No necesariamente por costo.
A veces por privacidad.
O cumplimiento regulatorio.
O simplemente porque el modelo especializado ofrece mejores resultados.
Ahora pueden hacerlo sin abandonar Copilot.
2. Proveedores regionales
No todas las empresas quieren depender exclusivamente de proveedores estadounidenses.
Existen proveedores europeos.
Asiáticos.
Latinoamericanos.
Servicios privados.
Todos pueden exponerse mediante una API compatible.
3. Routing inteligente
Aquí aparece uno de los escenarios más interesantes.
Un gateway puede decidir automáticamente:
- Claude para arquitectura.
- Qwen para generación rápida.
- DeepSeek para refactoring.
- Llama para documentación.
- GPT para razonamiento complejo.
Copilot ni siquiera necesita saber que eso está ocurriendo.
Simplemente habla con un endpoint.
Las credenciales permanecen bajo control
Muchas organizaciones no quieren distribuir múltiples claves de API entre cientos de desarrolladores.
Prefieren un único gateway interno.
Ese gateway:
- autentica usuarios;
- registra auditoría;
- aplica límites;
- controla costos;
- decide qué modelo utilizar.
El desarrollador solo conoce una URL.
Todo lo demás queda centralizado.
Reduce el lock-in
Este punto merece atención.
No elimina completamente el lock-in.
Seguís utilizando Copilot.
Seguís utilizando JetBrains.
Pero el componente más caro del stack —el modelo— deja de ser fijo.
Cambiar de proveedor puede convertirse simplemente en modificar una URL.
Eso reduce muchísimo el costo de experimentar.
¿Qué pasa con los agentes?
La actualización no se limita a cambiar el modelo.
También incorpora una experiencia más completa para:
- agentes;
- plugins;
- skills;
- instrucciones compartidas.
Eso significa que una organización puede construir una plataforma donde:
- el modelo es propio;
- las instrucciones son internas;
- los plugins son corporativos;
- las políticas viven en el gateway.
Todo dentro del mismo IDE.
Especialmente interesante para equipos Java y Kotlin
Durante bastante tiempo muchas novedades de IA aparecían primero en VS Code.
Los usuarios de IntelliJ, Rider o Android Studio debían esperar.
Esta actualización reduce bastante esa diferencia.
Especialmente para empresas donde JetBrains sigue siendo el estándar.
Lo interesante no es la API
Es fácil quedarse con el detalle técnico:
“Ahora acepta endpoints compatibles con OpenAI.”
Pero esa no es la noticia.
La noticia es que GitHub empieza a separar dos conceptos que antes estaban unidos.
La experiencia del desarrollador.
Y
El modelo que genera las respuestas.
Son capas distintas.
Y ahora empiezan a poder evolucionar por separado.
¿Estamos entrando en la era de los IDE agnósticos al modelo?
Hace unos años elegíamos un editor.
Después elegíamos un asistente.
Ahora empezamos a elegir un stack de inferencia.
El IDE deja de ser el lugar donde vive el modelo.
Se convierte en la interfaz desde la que consumimos cualquier modelo que tenga sentido para cada organización.
Probablemente esa sea la dirección que veremos durante los próximos años.
Porque el verdadero valor ya no está únicamente en tener el mejor modelo.
Está en poder cambiarlo cuando aparezca uno mejor.