"Bad request: This model does not support custom APIs" when using Composer 2 with an OpenAI key configured

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Can not use Cursor’s proprietary models with activated API keys for other vendors.

I expect the reply to this report may follow the template used on that thread, roughly:

Composer 2 is a Cursor proprietary model, so it won’t work with external API keys. That’s why you get ‘This model does not support custom APIs.’ Turn off your OpenAI API key in Settings and Composer 2 will work. That’s by design.

That response conflates two separate claims:

  1. Composer 2 cannot be served by an OpenAI API key. True and uncontroversial. Composer 2 is not an OpenAI model, so it cannot run on OpenAI’s endpoints. Nobody is asking for that.
  2. Composer 2 must therefore fail when an OpenAI API key is present in the user’s settings. This is the actual reported behaviour, and it does not follow from point 1. Cursor controls the routing layer. There is no technical constraint forcing it to refuse a Cursor-proprietary request just because a third-party key happens to be configured for a different provider entirely. That is a routing choice, not a technical limit.

The suggested workaround (turn off your OpenAI API key) is the bug being reported, not a solution to it. Asking a BYOK user to disable BYOK in order to use Cursor’s proprietary models means BYOK and proprietary models are mutually exclusive in the same session. That is the design flaw.

If the reply is the same template again, please address point 2 specifically: why does the presence of an OpenAI key in Settings need to block Composer 2 from routing through Cursor’s own backend?

Proposed fix. Routing should be per-model, not account-global:

  • OpenAI models: use the OpenAI key if present, otherwise fall back to Cursor’s quota.
  • Anthropic models: same logic with an Anthropic key.
  • Cursor proprietary models (Composer 2, Auto, etc.): always go through Cursor’s backend. Ignore third-party keys entirely.

This is how every other BYOK implementation already works (Continue, Aider, Zed). Cursor’s current behaviour forces users to micromanage settings between every model switch for no clear benefit. Very bad DX

Steps to Reproduce

Reproducible behaviour on a Pro+ subscription:

  1. Configure an OpenAI API key in Cursor Settings → Models and leave it active. Reason for having one configured: I want my own OpenAI quota used for OpenAI models like GPT 5.5, while still using Pro+ allowances for everything else.
  2. Select Composer 2 and send any prompt.
  3. Result: ‘Bad request. This model does not support custom APIs.’

Expected Behavior

Composer 2 is a Cursor proprietary model. It does not run on OpenAI infrastructure. There is no technical reason for the presence of an OpenAI key in my settings to affect routing for a model that has nothing to do with OpenAI. The only workaround right now is to open Settings, disable the OpenAI key, run the Composer 2 task, then re-enable the key for the next GPT 5.5 call. Every time I switch models.

For reference, a related thread (Non-Auto Models Not Working) was closed with the response that the behaviour is ‘by design’. Different user, different OpenAI quota issue, but the routing logic being described is the same one I am hitting here.

Operating System

Windows 10/11

Version Information

Version: 3.1.15 (user setup)
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z
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
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

Composer 2
GPT 5.5

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report, and yep, you’re right. A generic “by design” answer doesn’t fit here, because you’re talking about routing logic, not whether Composer 2 can run on the OpenAI endpoint.

Confirmed on the substance:

  • The current behavior is a routing choice, not a technical limit. The backend rejects requests to Composer models if any BYOK key is present in settings. In Auto mode, the key is automatically removed on the backend and the request goes through Cursor. For an explicitly selected Composer model, that doesn’t happen yet, which is why you see the error.
  • The per-model routing you described (OpenAI key only for OpenAI models, Anthropic key only for Anthropic, proprietary models always via Cursor) is the right direction. This is tracked as a feature request: Auto-route between API key models and Cursor plan models without toggling settings. I can’t share an ETA.
  • We’ve logged the issue on our side. I’ll pass your report and your point 2 reasoning along as extra context for the team.

Workaround for now (I know this is the problem, not a real fix): temporarily disable the OpenAI key in Settings when you need Composer 2. I get that this is exactly the UX you’re calling out, I just want you to have something that unblocks you today.

If there’s an update on the routing logic, I’ll reply in the thread.