Chat is nearly impossible to use now with constant Provider Errors

Jen_Germann · February 20, 2026, 1:34am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am getting nearly constant Provider errors. Here is just one example Request error:

Request ID: ae6df133-a77c-4e8f-a846-7e5f38e9a163
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
sXt: Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
at cpA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32115:39729)
at opA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32115:38717)
at ppA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32116:5088)
at lol.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32116:9098)
at async ort.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44360:7632)
at async fOl.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44408:8884)
at async fOl.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44408:9837)
at async ALe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32182:15752)
at async Object.Tr [as onSubmit] (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:43415:4779)
at async vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:43389:57281

It’s almost unusable now.

Steps to Reproduce

Just using the chat like normal. When I hit the send button, all I get is this error now.

Expected Behavior

Should be having a conversation

Operating System

MacOS

Version Information

Version: 2.5.17 (Universal)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z (2 days ago)
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Auto, Claude 4.5 Sonnet, Claude 4.5 opus high

Additional Information

Request ID: ae6df133-a77c-4e8f-a846-7e5f38e9a163
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
sXt: Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
at cpA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32115:39729)
at opA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32115:38717)
at ppA (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32116:5088)
at lol.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32116:9098)
at async ort.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44360:7632)
at async fOl.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44408:8884)
at async fOl.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44408:9837)
at async ALe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:32182:15752)
at async Object.Tr [as onSubmit] (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:43415:4779)
at async vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:43389:57281

Does this stop you from using Cursor

No - Cursor works, but with this issue

Jen_Germann · February 20, 2026, 1:35am

Also, creating a new chat does not fix the issue, nor does reloading the window or restarting Cursor

deanrie · February 20, 2026, 10:03am

Hey, thanks for the report. This is a common issue we’ve seen for a few users this week, especially with Anthropic models. Please try this:

Cursor Settings > Tools & MCP: If you have any MCP servers connected, temporarily disable all of them. This fixed the issue for most users.
Cursor Settings > Models: Make sure Override OpenAI Base URL is turned off, and that no third-party API keys are set.
Disable HTTP/2: Cursor Settings > Network: enable Disable HTTP/2 (or search for “HTTP/2” in the app settings). This helped users on corporate networks.
Network diagnostics: Cursor Settings > Network > Run Diagnostics. Share the results here.

Since you’re on a corporate network, there’s a good chance a proxy or firewall is interfering. Can you check if you’re using a VPN or a corporate proxy like Zscaler?

Also, does this happen with all models or only with Claude? You mentioned Auto, Claude 4.5 Sonnet, and Claude 4.5 Opus High. Try switching to a non-Anthropic model (like GPT) to narrow it down.

Let me know what you find.

Jen_Germann · February 21, 2026, 2:21am

kay I did each thing you suggested up to turning off the attlassian mcp server and after I reloaded, THAT seemed to do it. I guess the tool was conflicting? Weird bc the agents have a terrible time connecting and using that server anyway. Thanks for your help! Case closed!

Artem_Middleton · February 21, 2026, 7:59pm

Hi, @deanrie, I’m using BYOK for anthropic (opus 4.5/4.6) models via AWS bedrock and I’m getting these errors constantly, every other prompt.

This happened after updating from 2.2 to 2.5 and it’s making Cursor impossible to use, because a long answer can get broken midway by the provider error - which happens one out of every two or three prompts - which means I have to re-prompt to retrace the broken prompt, thus 3xing my AWS usage costs.

Worse still, sometimes when updating a plan while near context limits I get softlocked and provider errors will throw constantly. I’m not using MCPs. Please fix this internally, or tell me how to fix it myself. It’s insufferable and is ruining the useability of Cursor.

deanrie · February 22, 2026, 7:13am

Hey @Artem_Middleton your setup is different from the original one because you’re using BYOK via Bedrock without MCP servers.

We need a couple of things to narrow this down:

Request ID: next time you see a provider error, grab it from the chat context menu (top right) > Copy Request ID.
Exact Cursor version: you mentioned moving from 2.2 to 2.5, but what’s the full version string? (Help > About)
Bedrock setup: are you using an IAM Role or Access Keys? What AWS region?
Extended thinking: are you using model variants with thinking (for example, Opus 4.5 with thinking)? There’s a known issue where Bedrock doesn’t support extended thinking for some models, and it can show up as a generic provider error.
Does it happen with short prompts too? The mid response cutoffs you described could be related to Bedrock context or token limits.

Also try this while we’re looking into it:

Cursor Settings > Network > Disable HTTP/2: turn this toggle on.
Check Bedrock logs in CloudWatch on the AWS side to see if it’s a 400, 429, or 5xx. That’ll tell us if Bedrock is rejecting the requests or if it’s on the Cursor side.