Durante quase dois anos, a conversa em torno do GitHub Copilot sempre girou em torno da mesma pergunta:
Que modelos o GitHub suporta?
Com a última atualização para JetBrains, a pergunta muda completamente.
Agora passa a ser:
Que modelo você quer conectar?
GitHub adicionou suporte para endpoints compatíveis com a API do OpenAI, permitindo que o Copilot utilize modelos externos desde que exponham essa interface.
Pode parecer uma pequena mudança de configuração. Na verdade, é uma mudança de arquitetura.
Copilot começa a se comportar mais como um harness para modelos do que como um produto atado a um provedor específico.
E isso abre possibilidades muito interessantes para equipes que estão construindo plataformas internas de IA.
O que o GitHub anunciou?
A atualização para os IDEs do JetBrains incorpora várias novidades importantes:
- configuração de endpoints compatíveis com OpenAI;
- uso de chaves próprias (BYOK);
- instalação de plugins desde marketplace ou repositórios;
- suporte para agentes e skills;
- integração mais profunda com Claude como provedor.
Mas a característica que muda as regras do jogo é a primeira.
Em vez de enviar todas as solicitações exclusivamente para a infraestrutura do GitHub, agora é possível direcioná-las para qualquer serviço que implemente o mesmo protocolo.
Isso inclui tanto provedores comerciais quanto infraestrutura própria.
O que significa “compatível com OpenAI”?
Não significa utilizar modelos do OpenAI.
Significa apenas implementar a mesma API.
Hoje existem dezenas de servidores que expõem esse padrão.
Por exemplo:
- vLLM
- Ollama
- LM Studio
- LiteLLM
- OpenRouter
- gateways corporativos
- plataformas internas de inferência
Do ponto de vista do Copilot, todos podem se parecer exatamente iguais.
Um exemplo com vLLM
Suponha que uma empresa queira utilizar Qwen, DeepSeek, Llama ou Mistral sem enviar código-fonte para um provedor externo.
Pode implantar um servidor com vLLM.
vllm serve Qwen/Qwen3-Coder-480B
Esse servidor expõe um endpoint compatível com OpenAI.
No JetBrains simplesmente configura-se:
Base URL:
http://meu-servidor:8000/v1
API Key:
xxxxxxxx
E pronto.
Copilot passa a utilizar esse modelo.
Não muda a experiência do desenvolvedor.
Muda o backend.
Também funciona com Ollama
Para equipes pequenas é ainda mais simples.
Instalar Ollama:
brew install ollama
Baixar um modelo:
ollama pull qwen3-coder
Levantar o servidor:
ollama serve
Ollama já publica uma API compatível.
Nesse momento o JetBrains pode consumir o modelo exatamente da mesma forma que consumiria GPT ou Claude.
Tudo permanece local.
Por que isso é importante?
Porque durante muito tempo existiram dois caminhos:
Opção 1
Usar Copilot.
Obter uma experiência integrada.
Aceitar os modelos disponíveis.
Opção 2
Usar modelos próprios.
Perder integração.
Construir ferramentas internas.
Agora ambos os caminhos começam a convergir.
O IDE deixa de estar atado ao modelo
Esse é provavelmente a mudança conceitual mais importante.
Até agora escolhíamos um IDE e automaticamente herdávamos os modelos disponíveis.
Com essa atualização ocorre o contrário.
Escolhemos o modelo.
E o IDE simplesmente o consome.
A relação começa a se inverter.
Casos onde isso faz muito sentido
1. Open Weights
Muitas organizações querem executar modelos próprios.
Não necessariamente por custo.
Às vezes por privacidade.
Ou conformidade regulatória.
Ou simplesmente porque o modelo especializado oferece melhores resultados.
Agora podem fazer isso sem abandonar o Copilot.
2. Provedores regionais
Nem todas as empresas querem depender exclusivamente de provedores norte-americanos.
Existem provedores europeus.
Asiáticos.
Latino-americanos.
Serviços privados.
Todos podem ser expostos por meio de uma API compatível.
3. Roteamento inteligente
Aqui aparece um dos cenários mais interessantes.
Um gateway pode decidir automaticamente:
- Claude para arquitetura.
- Qwen para geração rápida.
- DeepSeek para refatoração.
- Llama para documentação.
- GPT para raciocínio complexo.
Copilot nem precisa saber que isso está acontecendo.
Simples fala com um endpoint.
As credenciais permanecem sob controle
Muitas organizações não querem distribuir múltiplas chaves de API entre centenas de desenvolvedores.
Prefem um único gateway interno.
Esse gateway:
- autentica usuários;
- registra auditoria;
- aplica limites;
- controla custos;
- decide qual modelo utilizar.
O desenvolvedor apenas conhece uma URL.
Tudo mais permanece centralizado.
Reduz o lock-in
Este ponto merece atenção.
Não elimina completamente o lock-in.
Você continua utilizando Copilot.
Você continua utilizando JetBrains.
Mas o componente mais caro do stack — o modelo — deixa de ser fixo.
Mudar de provedor pode se tornar simplesmente modificar uma URL.
Isso reduz muito o custo de experimentar.
O que acontece com os agentes?
A atualização não se limita a mudar o modelo.
Também incorpora uma experiência mais completa para:
- agentes;
- plugins;
- skills;
- instruções compartilhadas.
Isso significa que uma organização pode construir uma plataforma onde:
- o modelo é próprio;
- as instruções são internas;
- os plugins são corporativos;
- as políticas vivem no gateway.
Tudo dentro do mesmo IDE.
Especialmente interessante para equipes Java e Kotlin
Durante bastante tempo muitas novidades de IA apareciam primeiro no VS Code.
Os usuários de IntelliJ, Rider ou Android Studio tinham que esperar.
Essa atualização reduz bastante essa diferença.
Especialmente para empresas onde JetBrains ainda é o padrão.
O interessante não é a API
É fácil se prender ao detalhe técnico:
“Agora aceita endpoints compatíveis com OpenAI.”
Mas essa não é a notícia.
A notícia é que o GitHub começa a separar dois conceitos que antes estavam unidos.
A experiência do desenvolvedor.
E
O modelo que gera as respostas.
São camadas distintas.
E agora começam a poder evoluir separadamente.
Estamos entrando na era dos IDEs agnósticos ao modelo?
Há alguns anos escolhíamos um editor.
Depois escolhíamos um assistente.
Agora começamos a escolher um stack de inferência.
O IDE deixa de ser o lugar onde vive o modelo.
Se torna a interface a partir da qual consumimos qualquer modelo que faça sentido para cada organização.
Provavelmente essa seja a direção que veremos durante os próximos anos.
Porque o verdadeiro valor já não está apenas em ter o melhor modelo.
Está em poder trocá-lo quando aparecer um melhor.