Custom Fireworks model fails with ERROR_BAD_USER_API_KEY while sibling models on same key succeed

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A single Fireworks AI custom model consistently fails with “Invalid API key. Unauthorized User API key” while other Fireworks custom models, configured identically with the same API key, work correctly.

Failing model: accounts/fireworks/models/deepseek-v4-pro-0813
Working models on the same key, same config, same session: accounts/fireworks/models/kimi-k3 and accounts/fireworks/models/glm-5p2

All requests egress through the agent.v1.AgentService “Run” stream to agentn.global.api5.cursor.sh. Plain chat and agent mode use the same service and host, so mode is not a variable. The failures return, field-for-field identical:

ConnectError code 16 [unauthenticated]
errorDetailsDebug: {“error”:“ERROR_BAD_USER_API_KEY”,“details”:{“title”:“Invalid API key.”,“detail”:“Unauthorized User API key”,“isRetryable”:false,“analyticsMetadata”:{“actionRequired”:“config”}},“isExpected”:true}

In each case the stream connects and a first chunk is received before the error. TTFB was 30ms, 99ms and 125ms.

Cursor support (ticket T-F66811) confirmed from their side that these request IDs do not show a completed handoff to the upstream provider the way a healthy custom-model call does, and characterized it as a config or routing rejection on Cursor’s path rather than a Fireworks 401.

Steps to Reproduce

  1. Settings > Models > API Keys. Enter a Fireworks API key in the OpenAI API Key field and enable Override OpenAI Base URL pointing at the Fireworks OpenAI-compatible endpoint.
  2. Add three custom models: accounts/fireworks/models/kimi-k3, accounts/fireworks/models/glm-5p2, accounts/fireworks/models/deepseek-v4-pro-0813. Enable all three.
  3. Select kimi-k3 in the model picker and send “ping”. It answers normally.
  4. Select deepseek-v4-pro-0813 and send “ping”. It fails with “Invalid API key. Unauthorized User API key”.
  5. Repeat step 4 in a plain chat thread rather than an agent thread. Same failure.

Steps 3 and 4 minutes apart on the same key and same config is the control that isolates the model string as the only variable.

Expected Behavior

accounts/fireworks/models/deepseek-v4-pro-0813 should return a completion, as its sibling Fireworks models do on the identical key and configuration. The model is served on my Fireworks account and has real successful usage — 14.4M tokens on Aug 28 — so the credential and the model string are both valid.

Operating System

MacOS

Version Information

Cursor IDE 3.18.9

For AI issues: which model did you use?

accounts/fireworks/models/deepseek-v4-pro-0813 (custom model via Fireworks AI BYOK)

For AI issues: add Request ID with privacy disabled

9343eafa-37d3-4676-bece-7a8980bb4fcc agent thread, 12:21 Pacific, FAIL
77d6ba54-0df3-4a15-8b22-839058dd70b7 agent thread, 13:04 Pacific, FAIL
3d2deee4-4ae3-4b86-9c42-80f0cd9efd77 plain chat, ~13:15 Pacific, FAIL
c845c483 (truncated) kimi-k3, 11:12 Pacific, SUCCESS - control

Additional Information

Evidence that this is not the key or the Fireworks account:

  1. The same key succeeds on sibling custom models through the identical transport, minutes apart.
  2. Fireworks’ response-status analytics filtered to this model over 14 days shows only 200 and 429 responses. Account-wide over the same window: 200, 299, 400, 429 and 499. No 401 or 403 has ever appeared. If Fireworks had rejected the credential it would show there.

The open question: is there a model allowlist, name-parsing step, or routing table on the BYOK path that treats this model string differently from accounts/fireworks/models/kimi-k3? The “actionRequired”:“config” metadata suggests the service concluded my configuration is wrong, which fits a model-string routing mismatch better than a credential problem.

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Following up with cross-references, because this appears to be a long-standing bug family rather than an isolated case.

Four prior reports, all surfacing ERROR_BAD_USER_API_KEY or a close variant, all involving “Override OpenAI Base URL”:

  • API Keys for ChatGPT and Anthropic Failing (Nov 2025, Cursor 2.1.34)
  • Anthropic models break when Override OpenAI BaseUrl is set (Dec 2025, Cursor 2.1.26)
  • Anthropic (Claude) API Key Not Working in Cursor — Always Returns “Bad User API Key / Unauthorized” (Dec 2025, Cursor 2.1.49)
  • Custom model kimi-k2-7-code triggers “Model Not Found” error while backend API works normally (Jul 2026, Cursor 3.12.30)

@DeanRie’s accepted answers on those threads establish two things directly relevant here. First, that when Override OpenAI Base URL is enabled, Cursor can send malformed requests to the provider. Second, that when a base URL is set, all API keys see it — so the override is global across provider slots rather than scoped to one.

That second point is the mechanism I was asking about in my original post. If provider routing is decided by model string and the override applies globally, a model string that routes to a slot without a matching key would produce exactly ERROR_BAD_USER_API_KEY, while sibling strings that route correctly succeed on the same key. That is the pattern I am seeing.

Where my case differs from the earlier reports: for me the override is not incidental, it is required. I am using the OpenAI-compatible slot to reach Fireworks. “Turn off Override OpenAI Base URL” is the accepted workaround on three of those threads, but it is not available to me — turning it off would break the two models that currently work.

One new piece of evidence that may help narrow the mechanism. My Fireworks account-wide response-status chart for the last 14 days includes 400 responses. The same chart filtered to accounts/fireworks/models/deepseek-v4-pro-0813 shows only 200 and 429. If Cursor is sending malformed requests as described in the Nov 2025 thread, a malformed request might not be attributable to a model on the provider’s side, which would place it in the account-wide view and not the per-model view. That would reconcile the two readings I have been given: Cursor support told me on ticket T-F66811 that my three failing request IDs show no completed handoff to the upstream provider, while the earlier accepted answer on the kimi-k2-7-code thread reads an “Unauthorized User API key” as evidence the request did reach the endpoint.

I have an open ticket with Fireworks asking whether any requests at all, including unparseable ones, arrived from Cursor’s infrastructure at my three failure timestamps. I will post the answer here.

Given that the Nov and Dec 2025 threads were escalated to engineering and then auto-closed without a confirmed fix, is there a current status on the Override OpenAI Base URL bug family?

6

Hey, thanks for the detailed write-up and the Request ID. With those, the trace is easy to read.

Your Fireworks key is fine. Requests for accounts/fireworks/models/deepseek-v4-pro-0813 are going to https://api.openai.com/v1, and OpenAI is rejecting the Fireworks key (Incorrect API key provided: fw_…), not Fireworks. That means your Override OpenAI Base URL is currently set to https://api.openai.com/v1. That is the default value the toggle fills in when you enable it, not the Fireworks endpoint. That’s why you don’t see a 401 in Fireworks analytics. Those requests never reached Fireworks.

kimi-k3 and glm-5p2 work because those model IDs match models Cursor hosts on Fireworks. We route those IDs to Fireworks directly, no matter what the base URL is. So they looked like a clean control, but in reality they were just bypassing the setting. deepseek-v4-pro-0813 does not fall into that case, so it follows the base URL and goes to OpenAI.

How to fix it:

  • Cursor Settings > Models > API Keys.
  • In Override OpenAI Base URL, change the value to https://api.fireworks.ai/inference/v1
  • Press Enter or click outside the field so it saves. If you later disable and re-enable the override, it resets to the default OpenAI URL, so you’ll need to paste the Fireworks URL again.
  • Close and reopen Settings, then confirm the field still shows the Fireworks URL.
  • Start a new chat, pick deepseek-v4-pro-0813, and send “ping”.

On your question about scope, yes, the base URL applies to all OpenAI-compatible slots, not just one. But in this case, the issue is the base URL value, not the fact that override is enabled.

If the field already shows the Fireworks URL and the request still fails with the same error, send a new Request ID and I’ll take another look.