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.