Bug: Composer 2.5 explicitly selected requests blocked when OpenAI BYOK key is active

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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.

Operating System

Windows 10/11

Version Information

Version: 3.6.31 (user setup)
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Composer 2.5

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.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

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.

7

bumping - would love for an update where we don’t have to toggle the API keys on and off to use Composer 2.5