For almost two years, the conversation around GitHub Copilot always revolved around the same question:
What models does GitHub support?
With the latest update for JetBrains, the question changes completely.
Now it becomes:
What model do you want to connect?
GitHub added support for endpoints compatible with the OpenAI API, allowing Copilot to use external models as long as they expose that interface.
It might seem like a small configuration change. In reality, it’s an architectural shift.
Copilot starts behaving more like a harness for models than like a product tied to a specific vendor.
And that opens up very interesting possibilities for teams building internal AI platforms.
What did GitHub announce?
The update for JetBrains IDEs includes several important features:
- configuration of OpenAI-compatible endpoints;
- use of your own keys (BYOK);
- plugin installation from marketplace or repositories;
- support for agents and skills;
- deeper integration with Claude as a provider.
But the feature that changes the game is the first one.
Instead of sending all requests exclusively to GitHub’s infrastructure, it’s now possible to direct them to any service that implements the same protocol.
That includes both commercial providers and your own infrastructure.
What does “OpenAI-compatible” mean?
It doesn’t mean using OpenAI models.
It simply means implementing the same API.
Today there are dozens of servers that expose that standard.
For example:
- vLLM
- Ollama
- LM Studio
- LiteLLM
- OpenRouter
- corporate gateways
- internal inference platforms
From Copilot’s perspective, they can all look exactly the same.
An example with vLLM
Suppose a company wants to use Qwen, DeepSeek, Llama, or Mistral without sending source code to an external provider.
It can deploy a server with vLLM.
vllm serve Qwen/Qwen3-Coder-480B
That server exposes an OpenAI-compatible endpoint.
In JetBrains you simply configure:
Base URL:
http://my-server:8000/v1
API Key:
xxxxxxxx
And that’s it.
Copilot starts using that model.
The developer experience doesn’t change.
The backend does.
It also works with Ollama
For small teams it’s even simpler.
Install Ollama:
brew install ollama
Download a model:
ollama pull qwen3-coder
Start the server:
ollama serve
Ollama already publishes a compatible API.
At that point JetBrains can consume the model exactly the same way it would consume GPT or Claude.
Everything stays local.
Why does this matter?
Because for a long time there were two paths:
Option 1
Use Copilot.
Get an integrated experience.
Accept the available models.
Option 2
Use your own models.
Lose integration.
Build internal tools.
Now both paths are starting to converge.
The IDE is no longer tied to the model
That’s probably the most important conceptual change.
Until now we chose an IDE and automatically inherited the available models.
With this update the opposite happens.
We choose the model.
And the IDE simply consumes it.
The relationship starts to reverse.
Cases where this makes a lot of sense
1. Open Weights
Many organizations want to run their own models.
Not necessarily for cost reasons.
Sometimes for privacy.
Or regulatory compliance.
Or simply because the specialized model delivers better results.
Now they can do it without abandoning Copilot.
2. Regional providers
Not all companies want to depend exclusively on US providers.
There are European providers.
Asian ones.
Latin American ones.
Private services.
All of them can be exposed through a compatible API.
3. Intelligent routing
Here one of the most interesting scenarios appears.
A gateway can automatically decide:
- Claude for architecture.
- Qwen for fast generation.
- DeepSeek for refactoring.
- Llama for documentation.
- GPT for complex reasoning.
Copilot doesn’t even need to know that’s happening.
It simply talks to an endpoint.
Credentials remain under control
Many organizations don’t want to distribute multiple API keys to hundreds of developers.
They prefer a single internal gateway.
That gateway:
- authenticates users;
- logs audit trails;
- applies limits;
- controls costs;
- decides which model to use.
The developer only knows one URL.
Everything else stays centralized.
Reduces lock-in
This point deserves attention.
It doesn’t completely eliminate lock-in.
You’re still using Copilot.
You’re still using JetBrains.
But the most expensive component of the stack—the model—is no longer fixed.
Switching providers can become simply changing a URL.
That greatly reduces the cost of experimenting.
What about agents?
The update isn’t limited to changing the model.
It also includes a richer experience for:
- agents;
- plugins;
- skills;
- shared instructions.
That means an organization can build a platform where:
- the model is yours;
- the instructions are internal;
- the plugins are corporate;
- the policies live in the gateway.
All within the same IDE.
Especially interesting for Java and Kotlin teams
For quite some time many AI innovations appeared first in VS Code.
Users of IntelliJ, Rider, or Android Studio had to wait.
This update significantly reduces that gap.
Especially for companies where JetBrains remains the standard.
The interesting part isn’t the API
It’s easy to focus on the technical detail:
“Now it accepts OpenAI-compatible endpoints.”
But that’s not the news.
The news is that GitHub starts separating two concepts that were previously joined.
The developer experience.
And
The model that generates the responses.
They’re distinct layers.
And now they can start evolving separately.
Are we entering the era of model-agnostic IDEs?
A few years ago we chose an editor.
Then we chose an assistant.
Now we’re starting to choose an inference stack.
The IDE stops being the place where the model lives.
It becomes the interface from which we consume any model that makes sense for each organization.
That’s probably the direction we’ll see over the coming years.
Because the real value no longer lies solely in having the best model.
It lies in being able to switch it when a better one appears.