Custom base URLs for each custom model

Feature request for product/service

Cursor IDE

Describe the request

When adding custom models, we should be able to set specific base URLs for each model. I recently tried adding GLM-4.7 to the custom models and needed to override the base URL to z.ai’s endpoint but in setting that override, the ability to use all of the others models broke. I would like to be able to create a new model and base URL such that I can use that custom model successfully but if I switch to GPT-5.2, those calls will continue to work without having to disable the openAI base url override.

Hey, thanks for the request. This is a known limitation. A few users have hit the same issue when trying to use multiple custom models with different endpoints at the same time.

A similar request was posted 8 days ago:

This feature is in progress. The team is working on fixing how “Override OpenAI Base URL” behaves with custom models. For now, the only workaround is to manually switch the Override Base URL in settings when you switch models.

I’ll add your use case to the existing thread so the team can see the demand.

I swore I looked for this and didn’t see it (it’s late, I may be misremembering) and then I saw tons of related posts about the same. Glad to see the team is looking into this, thx Dean

I have the same issue.

@deanrie I found another issue.

If I turn OpenAI API Key on, I won’t use selected internal models (auto mode seems fine)

Request ID: 0163c08f-3540-443b-8a8d-c448ab340ec5
{"error":57,"details":{"title":"Provider Error","detail":"We're having trouble connecting to the model provider. This might be temporary - please try again in a moment.","isRetryable":true,"additionalInfo":{},"buttons":[],"planChoices":[]},"isExpected":true}
[resource_exhausted] Error
LTe: [resource_exhausted] Error
    at kmf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:9095:38337)
    at Cmf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:9095:37240)
    at $mf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:9096:4395)
    at ova.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:9096:8170)
    at async qyt.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34190:57047)
    at async Wpc.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34239:7695)
    at async Wpc.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34239:8436)
    at async FTe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:9170:14575)
    at async Oi (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32991:3808)

Hey Dean any update on this?

Hey, thanks for the ping. There hasn’t been any public progress on this since December. We’re tracking the issue on our side, but it hasn’t moved into active development yet, so I can’t share an ETA. I over-promised in December, sorry about that.

The workaround is still the same: manually switch Override Base URL when you change models. If we make progress on proper per-model endpoints, We’ll post an update in this thread.

Thanks for the feedback, really glad its still in the pipeline! Would love to drop vscode all together haha

Please bump this one up the queue! I love Cursor, but I might have to go back to VSCode so I can run my local LLM alongside frontier models.

Hey, thanks for flagging this, I can see the request is still relevant.

Honestly, there’s been no public progress on per-model base URL since May, so I can’t give an ETA. We’re tracking this request, and once there’s anything to share, I’ll reply in this thread.

For now, the only workaround is the same: manually switch Override OpenAI Base URL in settings when you change models. It’s annoying, I get it, but right now it’s the only working way to run a local LLM alongside frontier models without breaking everything else.

IDK if it needs to be per-model, but per provider would make loads of sense.

What brought me to this issue is the simple peeve that “OpenAI API key” bricks Cursor models. I simply wanted to BYOK for OpenAI’s models - GPT Sol, etc.

The obvious alternate would be to route all my model traffic to something like OpenRouter, but again this bricks cursor models, which (it would seem to me) should be allowed to completely ignore everything about custom api keys and just operate with the subscription on the subscription endpoint.

My interim absurd-hack workaround may be to throw together my own kludgey model router which does what I want.

I have a paid Cursor subscription and I also use an OpenAI-compatible custom endpoint through Override OpenAI Base URL.

When I explicitly select GPT-5.6 Luna from Cursor’s built-in model picker, I expect that request to use Cursor’s managed GPT-5.6 Luna and my Cursor subscription.

Instead, Cursor sends gpt-5.6-luna to my custom OpenAI endpoint.

I confirmed this conclusively using my proxy logs. As an additional test, I excluded gpt-5.6-luna from my proxy. Immediately afterwards, explicitly selecting GPT-5.6 Luna in Cursor fails with:

The requested model is not available.

This means the selected Cursor model is not being used as the source of truth for provider routing.

Expected behavior:

  • User-added/OpenAI-compatible models → BYOK / custom Base URL
  • Cursor-managed models selected from Cursor’s model picker → Cursor infrastructure / Cursor subscription
  • Auto already performs similar credential stripping, so explicit model selection should follow the same routing logic.

I should not have to disable BYOK every time I want to use a model included with the Cursor subscription I am already paying for.


Request ID: 5e466056-a8a2-4b1e-b437-bb91234259fb
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“The requested model is not available. Please try a different model.”,“isRetryable”:false,“additionalInfo”:{“providerStatusCode”:“400”},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error The requested model is not available. Please try a different model.
NonRetriableError: Provider Error The requested model is not available. Please try a different model.
at mAf (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9278:6590)
at zYi (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9278:5410)
at mTp (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9279:11972)
at Object.classify (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9279:16501)
at vAf (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9279:5856)
at async lYo.runWithSharedTurnRunner (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9279:15853)
at async YH.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:15854:72761)
at async q1a.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:15882:14489)
at async q1a.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:15882:24576)
at async eDe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9452:2491)
at async yi (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:14961:83665)

Hey, thanks for the detailed report, especially for confirming it via proxy logs and the Request ID. That really helps.

What you’re describing is a known limitation of how Override OpenAI Base URL works right now. When override is enabled, all requests go through the custom endpoint, including Cursor-managed models from the built-in picker. So even if you explicitly select GPT-5,6 Luna, the request still gets sent to your endpoint. And when you excluded gpt-5.6-luna from the proxy, the request fails with The requested model is not available. This isn’t something wrong with your setup. This is expected behavior in the current implementation.

We’re tracking this, but I can’t share an ETA yet. The only working workaround for now is to turn off Override OpenAI Base URL when you want to use models from your Cursor subscription, then turn it back on for your custom endpoint. I know it’s annoying.

One more quick housekeeping ask. This thread started as a feature request (a separate base URL per model), but your case is specifically about routing (Cursor models being sent to the custom endpoint). If you can create a separate thread for this routing report with the same details (proxy logs, Request ID, steps), I’ll link it to our internal tracking separately. That makes it easier to get this specific issue in front of the team without mixing it with the feature request.

I’ll post an update here when I have one.

I’m using an OpenAI-compatible custom endpoint and would like to use it for specific models only.

Ideally, each custom model should have its own:

  • Base URL
  • API key
  • Model ID

For example:

  • Cursor-managed models → Cursor infrastructure
  • GPT models → OpenAI
  • Internal/self-hosted models → our OpenAI-compatible endpoint

Having a single global “Override OpenAI Base URL” makes this difficult because it affects the other models as well.

Per-model (or even per-provider) endpoint configuration would make BYOK and self-hosted models much more practical.

By now, almost nine or ten months after the initial request, and since they already knew about this feature and it’s supposedly in progress, I think what they’re doing is a deliberate move to avoid it and basically force users to always use the cursor API. Otherwise, it just doesn’t make sense. It’s really frustrating.

Hey, I get that waiting this long with no progress is frustrating, especially when the request looks obvious.

On the accusation, I want to be clear: there’s no intentional stalling here, and we’re not trying to lock anyone into the Cursor API. BYOK via Override OpenAI Base URL is an officially supported setup, and we’re not removing it. The reason there hasn’t been progress is simpler and less conspiratorial: per-model and per-provider routing affects how model selection and routing work overall, and that area hasn’t been in active development yet. I still don’t have an ETA, and I won’t make one up.

We’re tracking the request and it’s still on our radar. When we have something concrete, I’ll reply here.

For now, the workaround is the same: turn off Override OpenAI Base URL when you need models from your Cursor subscription, then turn it back on for your own endpoint. I know that’s inconvenient.

One more thing: if your case is specifically about routing, where Cursor-managed models get sent to your custom endpoint, not about a separate base URL per model, that’s being handled in a separate thread: Cursor-managed models are routed through Override OpenAI Base URL. Please share routing details there so we don’t mix it up with the feature request.