I’ve been experimenting with custom OpenAI-compatible endpoints in Cursor recently, mainly because I wanted more flexibility over which models I could use without changing the rest of my development workflow.
There are a few things I wish I had known before setting it up, so I’m sharing them here in case someone else is trying the same thing.
Why use a custom API endpoint with Cursor?
Cursor already gives developers access to several models, and for many people that’s enough.
But there are cases where using your own API endpoint makes sense.
Maybe you already have API credits somewhere else.
Maybe you’re testing several models.
Maybe you’re building against an OpenAI-compatible gateway.
Or maybe you simply don’t want your development workflow tied permanently to one model provider.
Cursor supports using a custom OpenAI-compatible endpoint for Chat and Agent, which makes this kind of setup possible.
One important detail, though: when Override OpenAI Base URL is enabled, OpenAI-family requests currently go through that custom endpoint. This can also affect Cursor-managed models, so you may need to disable the override when switching back to Cursor’s own models. Cursor staff have confirmed that this is the current behavior.
The setup itself is straightforward
The general idea is:
-
Open Cursor Settings.
-
Go to the model/API settings.
-
Add your API key.
-
Enable the OpenAI Base URL override.
-
Enter the URL of your OpenAI-compatible API.
-
Add or select the model you want to use.
-
Test it in Cursor Chat or Agent.
For my testing I’ve been working on OrvAPI, an OpenAI-compatible AI API gateway that I run.
Full disclosure: I’m the person behind OrvAPI, so I’m obviously not presenting it as an independent recommendation. I’m mentioning it because it’s the endpoint I’ve actually been testing this workflow with.
The same basic idea should apply to other compatible gateways as well.
One limitation worth knowing
There is currently an important limitation with custom endpoints.
The base URL override isn’t isolated to an individual custom model.
If the override is active, Cursor can send OpenAI-family requests through that endpoint even when you select one of Cursor’s managed models.
So the workflow may look like this:
Using your custom endpoint
Custom API → Override ON → Custom model
Using Cursor’s models again
Cursor subscription → Override OFF → Cursor model
Cursor has acknowledged requests for per-model or per-provider base URLs, but as of now the workaround is still manually switching the override.
It isn’t a deal-breaker, but it’s definitely something to know before assuming every model can have its own endpoint.
Chat and Agent vs Tab
Another detail that can be confusing is that the custom endpoint applies to Chat and Agent, not Cursor Tab/autocomplete.
Cursor staff have confirmed that Tab continues using Cursor’s own dedicated model infrastructure rather than your custom OpenAI-compatible endpoint.
That means you can use your own API for agent work while still having Cursor handle autocomplete separately.
Personally, I actually prefer that separation.
Why I like this setup
The biggest advantage for me isn’t simply having another API key.
It’s being able to experiment.
AI models are changing incredibly quickly. A model that performs best for one coding task may not be the model I want for another.
Using an OpenAI-compatible layer means the editor doesn’t necessarily have to change just because the model behind it changes.
That’s useful when comparing things such as:
-
coding models
-
reasoning models
-
cheaper models for simple tasks
-
larger models for difficult debugging
-
different providers
-
experimental models
It also makes it easier to test how the same Cursor workflow behaves across different models.
A small warning about model names
When using a custom gateway, make sure the model name you’re adding in Cursor matches the model identifier supported by your endpoint.
A surprising number of “API problems” are simply mismatched model IDs.
Before debugging Cursor itself, I normally test the API directly first and confirm that:
-
the API key works
-
the base URL works
-
the model exists
-
a basic request completes successfully
Then I configure Cursor.
That removes a lot of guesswork.
What I’d like Cursor to improve
The biggest improvement would be allowing a separate API provider or base URL for individual custom models.
Something like:
Model A → Cursor
Model B → custom provider
Model C → another provider
without manually toggling anything.
There are already other Cursor users asking for this behavior, so hopefully routing becomes more flexible in the future.
Until then, the current override system still makes it possible to experiment with OpenAI-compatible gateways—it just requires understanding how the routing works.
If anyone else is running custom OpenAI-compatible endpoints with Cursor, I’d be interested to hear what setup you’re using and what limitations you’ve run into.