Cursor upstream model services experiencing degradation

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am experiencing slow response from Models with sporadic errors altogether.
We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.Request ID: 7a23ecf3-2202-46e3-920c-84b09e2XXXX
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Unable to reach the model provider”,“detail”:“We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:false}
[unavailable] Error
RetriableError: [unavailable] Error
at zxS (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12039:27795)
at kMc (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12039:26530)
at Any (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12040:11929)
at Object.classify (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12040:16434)
at KxS (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12040:5824)
at async Dqm.runWithSharedTurnRunner (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12040:15786)
at async rH.resume (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:24469:7475)
at async Tkh.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:24488:13862)
at async Tkh.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:24488:22888)
at async IRe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12125:2087)

The status page shows everything is operational which is shocking.

Steps to Reproduce

Running prompts from Cursor IDE

Operating System

MacOS

Version Information

Version: 3.9.8
VS Code Extension API: 1.105.1
Commit: 4aa8ff1b7877ed7bd01bcba308698f71a6735380
Date: 2026-06-25T01:39:30.490Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

GPT 5.5 - Medium

For AI issues: add Request ID with privacy disabled

Request ID: 3de6ccb0-111e-4219-a967-d6e0b3577757

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report with the stack trace and Request ID.

This isn’t an IDE bug. It’s transient error handling. [unavailable] and “ran out of capacity” from the provider are treated as retriable, so we automatically retry them. The message “Unable to reach the model provider” is what surfaces when we temporarily can’t reach the upstream provider. From what we can see, some of your GPT 5.5 requests did go through during that window, so it was intermittent degradation on the provider side, not a full outage.

That also explains the status page. Short partial blips can stay below the threshold for marking the service as degraded, so it still shows “operational”.

What helps right now:

  • Just retry the request. It often works on the second try.
  • Temporarily switch to a different model, like Auto, or a Claude or Gemini option. Those route through a different provider.

If you catch a window where it fails consistently for a few minutes, send the time with your timezone and a couple of Request IDs. I’ll pass it to the team that monitors routing and inference.

6

Thank you for the response. I understand that this isn’t an IDE bug, there were no other relevant options that I could choose from.
This resolved in about 25 mins from when I reported the issue first.

What I’d like to see is that you were already aware of this issue when it was first reported and somehow report as increased error rate despite being under SLA or customers are kept wondering on what is going on.

7

Glad it got resolved, and thanks for coming back with the update about ~25 minutes, that’s a really helpful detail.

On your point about transparency, I agree, that’s a fair call. Short partial blips that stay under the SLA threshold don’t always make it to the status page right now, and from a user perspective it can look like everything’s green but it still doesn’t work. Showing these degradation periods more clearly is something we’re discussing. I can’t share a specific timeline yet, but the feedback is solid.

For next time, if you catch another window where errors are happening consistently for a few minutes, send over the time with timezone plus a couple of Request IDs. Then I can pass it to the team monitoring routing and inference with a concrete reference point.