Cursor's BYOK blocks its own Composer model, sparking backlash
Cursor supports BYOK (Bring Your Own Key), letting users plug in their own API keys from providers like OpenAI or Anthropic. But when an external BYOK key is active and a user explicitly selects Cursor's own model, the request fails with the error "This model does not support custom API keys." Cursor's stated explanation is that Composer is a proprietary model and therefore can't be served through an external API key.
Critics say this answers a question nobody asked, since no one expects an OpenAI or to cover Composer's costs. The expected behavior is straightforward routing: external models use the matching provider's key, Cursor's own models use Cursor's and the user's , and each request should route correctly based on which model is chosen.
Simply having a key present in settings shouldn't break an unrelated, Cursor-owned model. A bug report thread on the Cursor forum documents the same issue.
Key points
- Selecting Cursor's own model fails when an external BYOK key (OpenAI/Anthropic) is active
- : "This model does not support custom API keys"
- Cursor says Composer is proprietary and can't run on external keys, but critics say that misses the actual complaint
- Expected behavior is automatic routing: external models use their provider's key, Cursor models use Cursor's own
- A matching bug report thread exists on Cursor's official forum