Cursor Override OpenAI Base URL Breaks Anthropic Key: Fix
One Cursor settings toggle causes three different Anthropic API key errors. Here is the exact fix and why it can silently undo itself.
TL;DR: Cursor's "Override OpenAI Base URL" toggle routes Anthropic key requests through the wrong endpoint; turn it off in Settings > Models > API Keys, confirm it stays off, restart Cursor, and start a new chat.
Anthropic BYOK users hit this after adding a valid Claude API key and watching Cursor reject it anyway. The confusing part is that the toggle is not scoped to the OpenAI provider the way its name implies - it is a single global base URL applied to every configured key, Anthropic included, and Cursor staff have confirmed it can silently re-enable itself even after you turn it off.
Why does Override OpenAI Base URL break Anthropic keys?
The setting exists so Cursor can point OpenAI-compatible requests at a custom endpoint - a self-hosted proxy, a third-party inference provider, or a corporate gateway. Cursor's own forum confirms the scope problem in plain terms: "when you set a base URL, all your API keys see it." The override does not check which provider the outgoing request belongs to before rewriting the endpoint, so an Anthropic request gets sent to whatever URL is sitting in that field, valid key or not, as reported in a Cursor bug thread.
A second, nastier variant of the same bug adds a self-reactivation problem. Cursor staff (Dean Rie) acknowledged in a separate thread that adding a valid Anthropic API key can auto-trigger the Override OpenAI Base URL toggle back on within seconds of you disabling it, which means the fix below does not always hold on the first try.
What does this error actually look like?
The same root cause produces three different error strings depending on where the misrouted request lands, which is why searches for this bug scatter across unrelated-looking forum threads instead of converging on one fix.
1. Bad User API key / Unauthorized User API key
Symptom: Every Claude model request fails immediately with "Bad User API key / Unauthorized User API key," even though the same key works when tested directly against Anthropic's API.
Diagnostic: Open Settings > Models > API Keys and check whether Override OpenAI Base URL is on. If it is, and you have an Anthropic key entered, this is your failure mode.
Fix: Turn the toggle off, confirm the base URL field is empty, and retry in a brand-new chat rather than the one that just failed.
2. "Model claude-opus-4.5-20251101 is not a reasoning effort model"
Symptom: The request reaches an endpoint at all, but Cursor rejects the response with a reasoning-effort model error - a message that only makes sense for OpenAI's API shape.
Diagnostic: This string means your Claude request was sent to the OpenAI-compatible endpoint currently set in the override field, not to Anthropic.
Fix: Same toggle, same fix. If it re-enables after a few seconds, quit Cursor completely (Cmd+Q on macOS, Alt+F4 on Windows) before it flips back, then relaunch and check the toggle state before opening a chat.
3. tool_choice.literal validation error
Symptom: A schema-shaped error naming tool_choice.literal['auto','required','none'] - the inverse failure, where an OpenAI-formatted request lands on Anthropic's endpoint.
Diagnostic: This confirms the override is active and pointed at Anthropic's URL while Cursor is still sending OpenAI-shaped payloads, a mismatch multiple users confirmed across Cursor 2.1.49 and later on both Windows and macOS.
Fix: Clear the custom base URL field entirely rather than just toggling it off - some reports found the field value persisted and kept routing requests even with the switch flipped to off.
How do you confirm the fix stuck?
Start a new chat, select a Claude model by name (not Auto), and send one message. If it responds normally, the routing is fixed for this session. Because the toggle can re-enable itself, check Settings > Models > API Keys again after your next Cursor restart before assuming it is permanently resolved - this is one of the few Cursor bugs confirmed in the Automation Error Index to require a repeat check rather than a one-time fix.
What if you actually need the override on?
If you use a third-party OpenAI-compatible provider (a local model gateway, an inference reseller, or a corporate proxy) alongside Anthropic keys, you cannot run both safely at the same time under the current global-scope bug. Enable the override only while actively using that provider, then disable it and verify the base URL field is cleared before switching back to Claude models. Cursor does not currently support per-provider base URLs, so this manual toggling is the only workaround until a fix ships.
How do you fix all three variants in under two minutes?
- Open Settings > Models > API Keys in Cursor.
- Turn off Override OpenAI Base URL and delete any text left in the base URL field.
- Quit Cursor completely rather than just closing the window.
- Relaunch Cursor and re-check the toggle state before opening a chat.
- Start a new chat, select a named Claude model, and send a test message.
FAQ
Does this bug affect all models or just Claude?
It affects any provider whose key is active while the override points at a different provider's endpoint. It surfaces most often with Anthropic keys because the override is labeled for OpenAI, so users assume it is scoped away from Claude traffic when it is not.
Why did my key work yesterday and fail today?
The most common cause is the self-reactivation bug: the toggle silently switched back on after a restart or after you enabled an Anthropic key, without any action on your part.
Is this a bug or a configuration mistake?
Cursor staff confirmed it as a known issue in the product backlog, not user error. The global scope of the base URL override and its tendency to auto-enable are both acknowledged bugs as of this writing.
Do I need the override on if I only use Claude models?
No. If you exclusively use Anthropic/Claude models and never route through an OpenAI-compatible custom endpoint, leave Override OpenAI Base URL off and the base URL field empty at all times.
What if turning the toggle off does not fix it?
Confirm the base URL field itself is empty, not just the toggle switched off - a leftover value in the field can keep routing requests even with the switch disabled. If the error persists after a full quit and relaunch, it may be the separate Cursor Provider Error, which has other root causes including conflicting MCP servers, or the Cursor Connection Error, which points at network and proxy-layer causes instead of key routing.