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:
- 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.
- 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:
- 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.
- Select Composer 2 and send any prompt.
- 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