Deepseek-v41-flash-1017 — every request ResourceExhausted (Desktop and Web)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

Cursor-hosted DeepSeek V4.1 Flash (deepseek-v41-flash-1017, model picker only, BYOK: false) has failed on every request since this morning. The UI shows:

We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
Agent Host logs show connectCode: ResourceExhausted, willRetry: false, and usedTokens: 0 (rejected before inference starts).
The same failure happens on Cursor Desktop and Cursor Web (same account, same model). Other models (e.g. Grok, Composer) work in the same sessions.
This does not look like a local cache, MCP, or network issue on my machine.

Environment

  • Client: Cursor 3.27.14, macOS arm64 (Apple M4)
  • Model: deepseek-v41-flash-1017 (included/hosted route, not my DeepSeek API key)
  • BYOK: false (composer log: bring_your_own_key: false)
  • Setting tried: cursor.general.disableHttp2: true, Network Diagnostics OK, MCP off, new chats, model re-selected

Timeline (JST, 2026-10-30)

Time (JST) Result Request ID
09:21:39 Last success (Agent, same long conversation) 615054c7-6527-4f49-bf24-be219a785fc6
09:23:09 First sustained failure 2c1ae74e-a931-4669-b4f3-af4218946753
09:23:16 Fail 160a93a4-3ef1-443a-ac64-7ac81310851d
09:23:47 Fail 107f0102-bfbd-4121-af2c-371199c50299
09:24:25 Fail cecfe952-63a4-4f9e-a4e9-e243193db5e2
14:20:04 Fail a9b58db5-a6bf-4b9b-a02c-7ccc471296ed
14:37:21 Fail 57833802-ca35-47ab-b68a-3200d4005371
17:12:25 Fail 8ff1cc5a-dbf9-4a8b-9a42-2b7dad7875e9
17:22:52 Fail 503b6986-f36d-4be4-a623-85877c48ee9f
17:24:31 Fail 169c5334-e88c-4d64-a22d-961783b8e125
17:31:44 Fail 2acd0daa-5e98-49d7-a528-54871b47045d
17:50:24 Fail (composer also shows providerStatusCode: 403) a44dff6e-68ed-40c6-b99f-e467929dc0a0
17:50:39 Fail 1cc8bab2-44ee-4502-8a7a-3944eee7531d
17:52:52 Fail f2fa4c7c-1d2f-4c1e-a60a-03ee407c48a3
18:01:51 Fail a0332135-04cf-446f-a43e-3091deab80be
18:21:45 Fail 81e1d6f5-60fb-4a21-bd03-ce7cc3b39e9d
18:31:30 Fail 07597010-5724-4d7c-9e9b-4eb6e5b6ee1c
18:32:19 Fail (transportMode: http1_sse) 45ba2ec8-1fac-4cde-9e81-578d10950ba7
Yesterday (2026-10-29) the same model worked on the same conversation (e.g. successful turns around 22:37–23:07 JST). Failures with ResourceExhausted also appeared intermittently last night, but this morning the route has been 100% failing since ~09:23 JST.
There was no Cursor app update between the last success (09:21) and the first failure (09:23).

Log details (Agent Host)

Typical failure line:

  • connectCode: ResourceExhausted
  • willRetry: false
  • usedTokens: 0
  • modelId: deepseek-v41-flash-1017
  • transportMode: websocket (sometimes http1_sse)
    Example diagnostics block:
    [AGENT_ERROR_DIAGNOSTICS] requestId=2c1ae74e-a931-4669-b4f3-af4218946753 ... connectCode: ResourceExhausted
    Dashboard Other Models usage is ~2% (not monthly pool exhaustion).

Cursor Web

I reproduced the same Provider Error when using deepseek-v41-flash-1017 on Cursor Web (not only Desktop). That rules out local Mac cache, local Agent host-only quirks, and “fix by clearing ~/.cursor” for this issue.

What I already tried (no improvement)

  • MCP disabled
  • Network → Run Diagnostics (pass)
  • Disable HTTP/2 / HTTP compatibility
  • New chats, re-select model
  • Other models work on Desktop and Web

Ask

Please check the hosted routing / capacity for deepseek-v41-flash-1017 for this account. Per your docs, this model is served via inference partners, not DeepSeek’s own API — so DeepSeek’s public status may not reflect this outage.
Priority Request IDs for lookup:
45ba2ec8-1fac-4cde-9e81-578d10950ba7, 2c1ae74e-a931-4669-b4f3-af4218946753, 615054c7-6527-4f49-bf24-be219a785fc6 (last success)
Thanks.

Steps to Reproduce

  1. Sign in to Cursor (Desktop or Web) with a plan that includes hosted models.
  2. Open a new chat (Agent or Ask).
  3. Select model: DeepSeek V4.1 Flash (deepseek-v41-flash-1017) from the model picker. Do not use BYOK / custom DeepSeek API key.
  4. Send any short message (e.g. “hello”).
  5. Within ~1–2 seconds, the chat fails with: “We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”
  6. Copy Request ID from the chat “…” menu — logs show connectCode ResourceExhausted, usedTokens 0, willRetry false.
  7. Repeat on Cursor Web with the same account and model — same error (not Desktop-only).
  8. Switch to another hosted model (e.g. Composer or Grok) in the same session — request succeeds.

Operating System

MacOS

Version Information

Cursor 3.27.14 (Universal), macOS arm64 — from Help → About Cursor → Copy

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

I’m having the same issue with any model that is not a cursor supplied model

5

Me too. Besides, glm5.3 and glm5.3 flash also don’t work

6

Same here, since last night. This is disabling. I’m not given the budget for models higher-end than Deepseek Flash and GLM 5.3 Flash, and Luna and Haiku aren’t good enough.

7

Hey all,

This issue should be resolved now. If you’re still encountering the issue, please share a new Request ID for us to dig into!

9

Thanks @Colin — and thanks to everyone who replied on this thread. Good to know it wasn’t just my account.

Confirmed fixed on my end. Nothing has changed since my original report: same Cursor 3.27.14, same account, same model (deepseek-v41-flash-1017, BYOK off), same long conversation. MCP is still off, as in that post. No cache clear and no other client-side changes for this recovery.

Timeline (JST): last failure 10-31 01:10 — d690a410-0ab9-4f1e-be7a-28274f3a97ca (ResourceExhausted, usedTokens 0). After that, requests started going through again around 02:16 — de1fe1a2-9737-4aa3-b0eb-ee1160393dbd (attempt 0) — and kept working (e.g. 02:41 90b37a07-87d5-41be-93a3-cef10bc6194a, and again this morning).

So for me it looked like the hosted route came back, not a local Desktop/Web or Mac setting issue.

I’m not seeing the problem now. If the same error comes back, I’ll reply here with new Request IDs instead of opening a new thread.