If I simultaneously enable an Anthropic key and an OpenAI key overridden with OpenRouter, either the Anthropic or the OpenRouter models stop working. Is there a conflict when enabling multiple API keys?
Steps to Reproduce
Enable both api keys for OpenAI and Anthropic keys.
Override openai: OpenRouter
Hey, thanks for the report. This is a known limitation. OpenRouter isn’t officially supported in Cursor as a BYOK provider. When you enable Override OpenAI Base URL with OpenRouter, Cursor sends requests to that endpoint in the wrong format. Also, the override is global and breaks the direct path to Anthropic, so you get a conflict when both keys are enabled at the same time.
Supported BYOK providers right now:
OpenAI
Anthropic
Google
Azure OpenAI
AWS Bedrock
The most reliable option is to not keep both enabled at once. Use either a direct Anthropic connection, or an OpenAI key with Override OpenAI Base URL set to OpenRouter, but not both.
Proper support for custom OpenAI compatible endpoints is something the team is working on, but there’s no specific timeline yet. Let me know if you’ve got any questions.
How to use OpenRouter in Cursor and compare its results with Cursor’s AI models.
The two rules to make this work are :-
1. use Ask mode (not Agent)
OpenRouter models only work reliably in Ask mode.
Agent mode routes requests through Cursor’s backend instead of your OpenRouter base URL. That causes errors such as “Unauthorized User API key” even when your key, base URL, and model ID are all correct.
Before sending a prompt:
Open new chat
Switch the mode dropdown from Agent to Ask
Select your OpenRouter model (e.g. deepseek/deepseek-v4-pro)
Send your message
2. start a new chat (not just switch mode/model)
OpenRouter often works in a fresh chat but fails again in an existing one.
Cursor can “lock” a chat thread to the routing path used on the first message (Agent backend, Composer, or a Cursor-built-in model). Changing the mode dropdown or model picker mid-thread does not always switch the backend — you still get Unauthorized User API key or similar errors even in Ask mode.
Reliable workflow — do this every time:
New chat : start fresh — do not reuse a thread that ever used Agent or Composer
Set Ask mode before your first message
Select your OpenRouter model before your first message
Send your prompt
Start a new chat again when:
You switch from one OpenRouter model to another (DeepSeek → Kimi → Qwen)
You previously used Agent or Composer in that thread
Ask mode + correct model still fails — the thread is likely stuck; don’t retry in place
Rule of thumb: one OpenRouter model, one Ask-mode chat thread. Don’t mix Cursor models and OpenRouter models in the same chat.
If that works but Cursor fails, the problem is probably not the key itself. It is more likely Cursor’s mode/model routing, especially when mixing built-in providers, Anthropic keys, OpenAI override URLs, Agent mode, or Composer.
Disclosure: I maintain Inferflow, so this is a biased test endpoint. I am sharing it because it gives a simple OpenAI-compatible text/chat baseline for isolating whether the failure is the API route or Cursor’s routing behavior.
Hey @inferflow.dev, the approach is useful. Isolating endpoint validity from Cursor routing with a direct curl test is the right move when debugging BYOK.
One request: as a baseline, let’s use a neutral OpenAI-compatible endpoint, not your own commercial service. Dropping your product into someone else’s troubleshooting thread, even with disclosure, goes beyond the community guidelines. Keep the diagnostic tip curl to check what’s failing, the key or Cursor routing, since that part is solid.
For context on the original request: OpenRouter isn’t officially supported as a BYOK provider, and you shouldn’t keep an Anthropic key together with an OpenAI override on OpenRouter at the same time. That’s what causes the conflict. More details are above in the thread.
Thanks, I appreciate it. A neutral curl test to separate key vs routing is a really useful troubleshooting trick, so feel free to share tips like that in threads.
On the original request, everything still applies. OpenRouter still isn’t supported as a BYOK provider, and you shouldn’t keep an Anthropic key together with an OpenAI override on OpenRouter at the same time. That’s what causes the conflict. If another user runs into something similar, you can safely point them to this thread.