Model picker offers models that always fail with "This model does not support custom API keys" — the catalog ships no flag for it

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

With a custom API key enabled (OpenRouter base URL), some models are rejected server-side with:

{"error":"ERROR_BAD_REQUEST","details":{
  "title":"Bad Request",
  "detail":"This model does not support custom API keys.",
  "isRetryable":false,
  "analyticsMetadata":{"actionRequired":"config"}}}

Two things make this a bug rather than a policy:

1. This is not a blanket “custom key disables Cursor models” rule. In the same window, on the same day, with the same key active, Cursor’s own first-party models work fine. It is a per-model restriction, and the set of affected models is not documented anywhere I can find.

34 Agent requests in one window today, 27 ok / 7 rejected, split purely by model:

Model Requests Result
deepseek/deepseek-v4.1-flash ~20 all ok
claude-opus-5-5 4 all ok
grok-4.7 4 all rejected
grok-4.6 1 rejected
openrouter/auto 1 rejected

claude-opus-5-5 succeeded at 15:30 local, six minutes before grok-4.7 was
rejected at 15:36. Same window, same key, same session.

2. The client cannot know which models are affected. The model catalog in
state.vscdb (availableDefaultModels2) carries no supportsCustomApiKey flag
or equivalent. The rejected and accepted models are indistinguishable locally:

{"name":"grok-4.7",        "supportsAgent":true, "degradationStatus":0, "clientDisplayName":"Grok 4.7"}
{"name":"claude-opus-5-5", "supportsAgent":true, "degradationStatus":0, "clientDisplayName":"Claude Opus 5.5"}

So the picker has no way to grey out or annotate the unsupported ones. You find
out only after composing a prompt and sending it, and the error is
isRetryable: false, so the turn is simply lost.

3. There is no per-model escape hatch. useOpenAIKey is a single global
boolean. aiSettings.modelOverrideEnabled does not gate this either —
grok-4.6 is in that list and is rejected, while claude-opus-5-5 is not in it
and works. The only workaround is toggling the custom key off globally, which
means choosing between OpenRouter models and Grok rather than using both.

Steps to Reproduce

  1. Settings → Models: enable a custom API key with base URL
    https://openrouter.ai/api/v1/cursor.
  2. Start a new chat, select claude-opus-5-5, send a prompt → works.
  3. In another new chat select grok-4.7, send a prompt → immediately fails with
    “This model does not support custom API keys.”

Both models look identical and equally available in the picker.

Expected Behavior

Any of these would fix it:

  • Ship a supportsCustomApiKey (or equivalent) flag in the model catalog, and
    disable / annotate those entries in the picker while a custom key is active.
  • Or fall back to normal Cursor billing for models the key cannot serve,
    ideally with a one-time confirmation.
  • At minimum, make the error name the models that do work, and don’t consume
    the turn — isRetryable:false currently just discards the message.

Ideally a per-model choice of “use my key” vs “use Cursor”, since the
restriction is already per-model on the server.

Operating System

Windows 10/11

Version Information

Cursor 3.21.18, commit c4730f7d93d787d9ab120af715999f0345ee5bc0
Windows 11 + WSL Ubuntu 24.04 remote, multi-root workspace.

For AI issues: add Request ID with privacy disabled

Rejected:

  • 2c5fdc4c-f18c-4d30-a6e1-7c3c52110d14 — grok-4.7, 15:36 local
  • 42fd29ce — grok-4.7, 15:36
  • 7b976f45 — grok-4.7, 15:29
  • fd30be6b — grok-4.7, 08:33
  • 004549f8 — grok-4.6, 14:58
  • b0d58850 — openrouter/auto, 10:34

Succeeded in the same window with the same key active:

  • 66136665 — claude-opus-5-5, 15:30
  • 6a945981 — claude-opus-5-5, 15:21
  • 61d7897c — deepseek/deepseek-v4.1-flash, 15:26

Additional Information

The failure is fast and clean, not a hang: rpc.run completes in 192 ms with
error=true, and the whole request finishes in 461 ms. Unrelated to the
context-gathering hangs in thread 171663.

I could not determine why openrouter/auto itself was rejected at 10:34 — that
error bubble was cleared from history on resend, so I can’t confirm whether it
returned the same message.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey @thibauld, thanks for the report, and your read of it is right.

When the OpenAI API key toggle is on, Cursor sends that key (and your base URL) with every model except the Claude and Gemini ones. Cursor’s own models (Composer, Grok 4.6 and Grok 4.7) can’t run on a custom key, so they get rejected. Claude Opus 5.5 works because it uses the separate Anthropic key slot, which you don’t have enabled. This is a known issue we’re already tracking, and I’ve added your report to it, including your suggestion to mark these models in the picker and route them through your Cursor plan automatically.

In the meantime:

  1. Auto keeps working with your key enabled, since it doesn’t send your key for Cursor’s models.
  2. For Grok 4.7 specifically, you’ll need to switch the OpenAI API key off in Cursor Settings > Models while you use it, then back on for your OpenRouter models.

The openrouter/auto failure was a different case. That request was rejected by OpenRouter itself, which said no models matched your account’s model restrictions. It’s worth checking the allowed models and provider settings on your OpenRouter account.

8

thanks @kevinn glad to hear you’re already on it.
I’ll close this thread using your answer as “Solution” then. Looking forward to a proper fix :saluting_face: