The IDE fails to route requests to explicitly selected Composer models (like Composer 2.5) if a Bring-Your-Own-Key (BYOK) OpenAI/Anthropic API key is enabled in the settings. Instead of processing the request via Cursor’s infrastructure, the backend rejects it with the error: "This model does not support custom API keys."As confirmed by a Cursor team member, this is a routing oversight rather than a technical limitation. While the backend correctly strips the BYOK key and routes the request through Cursor in “Auto mode,” it fails to apply this same logic when a Composer model is explicitly chosen.
Steps to Reproduce
Navigate to Cursor Settings > Models and enable a custom OpenAI API key.Open the Composer interface. Explicitly select Composer 2.5 (or any proprietary Composer model) from the model dropdown.Submit a prompt to the Composer.The request immediately blocks and throws the custom API key error.
Expected Behavior
When a Cursor-proprietary Composer model is explicitly selected, the backend should automatically strip/bypass the active BYOK key from the request header (matching the existing behavior of Auto mode) and route the query seamlessly through Cursor’s infrastructure.
For AI issues: add Request ID with privacy disabled
Request ID: 082cca8c-835d-4544-8237-378e5ac9370a
{“error”:“ERROR_BAD_REQUEST”,“details”:{“title”:“Bad Request”,“detail”:“This model does not support custom API keys.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“config”}},“isExpected”:true}
Bad Request This model does not support custom API keys.
Rut: Bad Request This model does not support custom API keys.
at Cqk (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36274:26826)
at lOy (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36274:25971)
at Rqk (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36275:6852)
at DNp.run (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36275:11720)
at async rge.runAgentLoop (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47623:65527)
at async _bf.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47691:12112)
at async _bf.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47691:19276)
at async Zut.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36407:17835)
at async Object.$s [as onSubmit] (vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46696:3887)
at async vscode-file://vscode-app/c:/Users/David/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:45757:103088
Additional Information
This issue introduces significant friction for developers who rely on BYOK for standard chat/tab models to manage costs, but still want to leverage Cursor’s premium Composer features. Manually toggling API keys on/off in the settings menu every time a developer switches between standard chat and Composer severely disrupts the development workflow.
Hey, thanks for the detailed report with the Request ID and logs.
One important detail: this isn’t a bug in the usual sense, it’s the current behavior by design. Composer models (1, 1.5, 2, 2.5) are proprietary Cursor models, and they don’t work with BYOK keys. When a custom OpenAI or Anthropic key is enabled and you explicitly select a Composer model, the backend rejects the request with this error.
It works in Auto mode because with default the client doesn’t send BYOK credentials for Composer routing, so the check passes. With an explicit Composer selection, the credentials still get sent, and the backend blocks them.
Workaround for now:
Turn off your custom API key in Settings > Models when using Composer models, or
Stay in Auto mode if you want to keep BYOK enabled.
What you’re asking for, automatically stripping the BYOK key for proprietary Composer models like Auto does, is a reasonable improvement and it’s on our radar. It’s not implemented yet, and I can’t share a timeline right now.
I get that toggling the key on and off is annoying, especially if you’re using BYOK for chat or Cursor Tab to control spend. I’ll follow up in this thread if there’s an update.
Just to set expectations honestly, as covered above, this is current behavior by design, not a bug. Composer models are proprietary and don’t run on BYOK keys, so an explicit Composer selection with a custom key enabled gets rejected, while Auto works because it doesn’t send the BYOK credentials for Composer routing.
The improvement you’re after, auto-stripping the BYOK key for proprietary Composer models the way Auto does, is logged on our side. It’s not implemented yet and I don’t have a timeline to share.
For now the options are the same:
Turn off the custom API key in Settings > Models when using Composer, or
Stay in Auto mode if you want to keep BYOK enabled.
The bump is noted, it helps us gauge demand. I’ll post here if there’s an update.
I want to bump this as well, we use private models and deploys for a variety of reasons (fine tuning, privacy, geographic restrictions, etc.)
Having to manage constantly toggling the api key on and off is genuinely hellish, and kinda ridiculous when we just want to make use of our ultra sub’s included usage.
Pleeeease can you support having the api key specified AND still being able to use the composer 2.5 model expliciently.
Thinking further, the ideal version of this would be being able to have multiple api keys+base urls (to cover the many-client contractor use case), and being able to select which (if any) api key to use per-model. However, short-term, we would 1000000% be happy with just being able to use the composer model.
Just to align expectations up front, this was mentioned earlier in the thread. The current behavior is expected and intentional, not a bug. The Composer models (1, 1.5, 2, 2.5) are proprietary Cursor models and don’t work with BYOK keys. Auto mode works because it doesn’t send BYOK credentials when routing to Composer. If you explicitly select Composer, those credentials still get sent, so the backend rejects the request.
What you’re asking for, automatically dropping the key when Composer is explicitly selected the same way Auto does, is logged on our side. It’s not implemented yet, and I can’t share a timeline.
The temporary workaround is the same:
Turn off the custom API key in Settings > Models when using Composer, or
Stay in Auto mode if you want to keep BYOK enabled.
I’ll also include your case with private models and deploys in the report. That helps us understand real demand.
+1 — same issue on macOS, Cursor 3.9.16.
I keep BYOK enabled for GPT/Claude/Gemini (external API key + optional base URL override). Other vendor models work fine.
When I **explicitly select Composer 2.5** in the model dropdown, every request fails with:
`This model does not support custom API keys`
Auto mode works, but I want to **choose Composer 2.5 deliberately** while keeping BYOK for other models — without toggling the API key off (`Cmd+Shift+0`) each time.
Paying Cursor subscription specifically for Composer; BYOK is for other models. Per-model routing (strip BYOK creds only for Cursor proprietary models, same as Auto) would fix this.
Please prioritize the logged QoL improvement. Happy to provide Request ID if needed.
Just to set expectations up front, this was covered earlier in the thread. The current behavior is expected and intentional, it’s not a bug. Composer models 1, 1.5, 2, and 2.5 are Cursor proprietary models and don’t work with BYOK keys. Auto works because when it routes to Composer it doesn’t send BYOK creds. When you explicitly pick Composer, the creds still get sent, and the backend rejects the request.
What you’re describing, per-model routing so BYOK creds are stripped only for proprietary models like Auto does, is logged on our side. It’s not implemented yet, and I can’t share a timeline.
For now, the workaround is the same:
Turn off the custom API key in Settings > Models when you use Composer, or
Stay on Auto if you want to keep BYOK enabled.
No Request ID needed, the cause is clear and I’ll reply here if there’s an update.
On your question, no, Auto does not route to Composer 2.5 all the time. Auto picks a model based on the task and current availability, so there’s no guarantee your request will go to Composer 2.5. If you need Composer 2.5 specifically and deterministically, you have to select it explicitly, and that runs into the current BYOK behavior.
Like others said earlier in the thread, this is by design, not a bug. Composer models are proprietary and don’t work with BYOK keys. When you explicitly select Composer, the client still sends BYOK creds, and the backend rejects the request. Auto works because when it routes to Composer, it doesn’t send creds.
For now, the workaround is the same:
turn off your custom API key in Settings > Models when using Composer, or
stay on Auto if you want to keep BYOK enabled.
The improvement you described, automatically stripping the BYOK key for proprietary Composer models like Auto does, is logged on our side. It’s not implemented yet, and I can’t share a timeline. I’ll reply in the thread if there’s an update.
I’d also like to bump this issue, because the current behavior is both confusing and unnecessarily disruptive.
I don’t understand why an enabled OpenAI BYOK key is even being considered when I explicitly select a Cursor-proprietary model such as Composer 2.5. Composer 2.5 is not an OpenAI model, so the OpenAI API key should simply be ignored and the request should be routed through Cursor’s infrastructure.
This already works correctly in Auto mode, which shows that Cursor can detect when BYOK is not applicable and bypass it automatically. Why can’t the same routing logic be used when Composer 2.5 or another Cursor-hosted model is explicitly selected?
Having to repeatedly open the settings and switch BYOK off and on whenever moving between OpenAI models and Composer creates a really poor user experience. It interrupts the workflow, is easy to forget, and makes using Cursor’s proprietary models feel unnecessarily cumbersome.
Please treat the explicitly selected model as the source of truth:
For a compatible OpenAI model, use the configured OpenAI BYOK key.
For a compatible Anthropic model, use the configured Anthropic BYOK key.
For Composer and other Cursor-hosted models, automatically bypass BYOK and route through Cursor.
Since this behavior already exists in Auto mode, this appears to be a routing consistency issue rather than a technical limitation. It would be great to see it fixed.
Like we already covered earlier in the thread, this is the current behavior by design, not a bug. Composer models 1, 1.5, 2, and 2.5 are Cursor proprietary models and don’t work with BYOK keys. Auto works because when it routes to Composer, it doesn’t send BYOK credentials. When you explicitly pick Composer, the credentials still get sent, and the backend rejects the request with This model does not support custom API keys.
What you described using the explicitly selected model as the source of truth and automatically bypassing BYOK for Cursor hosted models the same way Auto does makes sense, and we’ve logged it on our side. It’s not implemented yet, and I can’t share a timeline.
For now, the workaround is still the same:
Turn off the custom API key in Settings > Models when you’re using Composer, or
For anyone still looking for a workaround and not willing to wait: I made a patcher that stops OpenAI BYOK from being attached to Cursor-hosted models (Composer, Grok, etc.). It patches Cursor at the app level, so it’s a bit rough around the edges and only for people who really want this. Works on macOS and Windows:
Given that OpenAI is leaving Cursor, using an OpenAI API key will soon be the only way to access GPT models in the Cursor harness—making this bug more urgent than ever. I love Grok and Composer models, but I still want to use GPT models occasionally. Since an API key will be the only option, I really don’t want to constantly toggle my API key on and off just to make this work.
For AI issues: add Request ID with privacy disabled
Request ID: 22ae8985-01ed-4944-a146-a610ac230e19
{“error”:“ERROR_BAD_REQUEST”,“details”:{“title”:“Bad Request”,“detail”:“This model does not support custom API keys.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“config”}},“isExpected”:true}
Bad Request This model does not support custom API keys.
ActionRequiredError: Bad Request This model does not support custom API keys.
at YBf (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8237:145266)
at ZZs (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8237:144105)
at _3f (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8238:13645)
at Object.classify (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8238:17842)
at p3f (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8238:5924)
at async deo.run (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8238:17164)
at async Rle.runAgentLoop (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8338:34589)
at async nOo.streamFromAgentBackend (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:17791:17224)
at async nOo.getAgentStreamResponse (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:17791:36143)
at async SDe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/tmp/.mount_CursorfELgPA/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8316:4529)
Additional Information
how is this even possible now in age of AI to have such simple bugs not having fixed… T_T
Hey, thanks for the report with the Request ID. I can see the error in the screenshot, This model does not support custom API keys. Let’s figure out what’s going on.
Grok 4.6 and Composer 2.5 are Cursor-hosted models. They always run on Cursor’s infrastructure and can’t be used with a personal API key. When you add a custom model like qwen3.8-max, the OpenAI API Key toggle becomes available, and right now that key gets attached to every model except Claude and Gemini, including Grok and Composer. The server rejects those requests. This doesn’t affect your included usage.
For now, the workaround is to turn the toggle off when you want Grok or Composer:
Open Cursor Settings > Models.
In the OpenAI API Key section, turn the toggle off. You can leave the key and Base URL filled in.
Go back to chat and select Grok 4.6 or Composer 2.5. They should work again.
When you need qwen3.8-max again, turn the toggle back on.
Auto mode still works with the key enabled, since Auto never sends your personal key.
I know switching the toggle back and forth is annoying. We’re tracking a fix so Cursor-hosted models automatically ignore the custom key. I’ve shared your case with the team. I can’t promise a timeline yet, but I’ll reply in the thread if there’s an update.
