First Calss support for Openrouter (BYOK feature for Premium Members)

Ideas Feature Requests
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I like to play with various open models via the full model zoo available through OpenRouter. To do this, I enable the “OpenAI API Key” field with my OpenRouter API key and turn on “Override OpenAI Base URL” pointed at OpenRouter .

With this configuration:

Claude models (via Anthropic) work fine

Gemini models work fine

Grok models work fine

OpenRouter-hosted models (e.g., moonshotai/kimi-k2, DeepSeek, Qwen, GLM, etc.) work fine

But Cursor’s own models (Composer 2.5 / Fast) and OpenAI models fail with the error:

Bad Request — This model does not support custom API keys. Copy Request (ca7e346c-6510-478e-a114-eaf2271adf34)

The error appears the moment I send any prompt while Composer 2.5 (Fast) is selected. Disabling the OpenAI key override lets Composer/OpenAI models work again, but then I lose access to the OpenRouter model zoo.

Steps to Reproduce

Steps to Reproduce

Open Cursor → Settings → Models → API Keys
Toggle on “OpenAI API Key” and paste an OpenRouter API key
Toggle on “Override OpenAI Base URL” and set it to OpenRouter
In the chat input, select model Composer 2.5 (Fast) (or any OpenAI/Cursor first-party model)
Send any message (e.g., “hi”)
Observe the “Bad Request — This model does not support custom API keys” error

Expected Behavior

Expected Behavior Cursor’s first-party models (Composer 2.5, Tab, etc.) OpenAI models to function as the rest of the built in models from Cursor

Screenshots / Screen Recordings

Screenshot 2026-05-20 at 03.52.30.png
Screenshot 2026-05-20 at 03.52.30.png1252×704 28.6 KB

Operating System

MacOS

Version Information

Version: 3.3.12
VSCode Version: 1.105.1
Commit: 75c0dfd29aecf2cc208dbaf761d5cc459c601aa0
Date: 2026-05-06T03:47:52.249Z
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: Darwin arm64 23.6.0

For AI issues: which model did you use?

Composer 2.5 (Fast). Also reproduces with OpenAI models. Does NOT reproduce with Claude, Gemini, Grok, or OpenRouter-hosted models.

For AI issues: add Request ID with privacy disabled

f9a7046a-279b-47e5-ab48-6e8dc12daba1

Additional Information

Has never worked — this is the first time I’ve tried this configuration; not a regression from a known-good state.
Workaround: disable the OpenAI base-URL override, but that defeats the purpose of using OpenRouter for open-model access.
Suggested fix: scope the OpenAI key/base-URL override to OpenAI-provider models only; route first-party Cursor models (Composer, Tab) through Cursor’s backend regardless of the OpenAI override setting.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Thanks for the detailed report. Cursor doesn’t officially support OpenRouter as a BYOK provider today.

The “OpenAI API Key” and “Override OpenAI Base URL” settings are intended for OpenAI/OpenAI-compatible chat model routing, but they do not make Cursor-owned models like Composer 2.5 or Tab run through a custom API key or a third-party provider. Composer is served through Cursor’s infrastructure, so when a custom API key/base URL is active, the “This model does not support custom API keys” error is expected for Composer.

As a workaround you can disable your BYOK override, and then switch to Composer, and then your request will go thru. Note that you can’t have BYOK overrides in place and use Composer or other named models - you’ll need to disable BYOK first.

8

Hit the same wall and got tired of debugging Cursor’s request shapes against OpenRouter, so I shipped a small open-source gateway that puts LiteLLM between them. Cursor sees stable model names (chat, coder, vision), LiteLLM handles routing, retries, and provider quirks. Repo and the specific Cursor settings that worked for me. Happy to help anyone debug their setup.