Bug Agent stuck on Taking longer than expected and Reconnecting with Gemini 3.1 Pro

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent is experiencing severe network delays. I use the Gemini 3.1 Pro model. After almost every command the Agent gets stuck on Planning next moves or shows the message Taking longer than expected. It also frequently shows Reconnecting. This started happening recently and gets much worse in the evenings. It takes several minutes to process simple commands.

Steps to Reproduce

Open Cursor and start Agent with Gemini 3.1 Pro

Ask the Agent to perform a task

Observe the massive delays and the Taking longer than expected message

Expected Behavior

The Agent should execute commands quickly without hanging for minutes and dropping the connection

Screenshots / Screen Recordings

Cursor_S38TrzyUYa

Cursor_3hKYVoJ7UD
Cursor_3hKYVoJ7UD295×305 6.5 KB

Operating System

Windows 10/11

Version Information

Latest version

For AI issues: which model did you use?

Gemini 3.1 Pro

For AI issues: add Request ID with privacy disabled

The requests just hang and timeout so I cannot get an ID. Maybe:

“Request ID: 769ca12c-1358-4496-91ee-d445a342017b
{“error”:“ERROR_RESOURCE_EXHAUSTED”,“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”:true}
[resource_exhausted] Error
iLe: [resource_exhausted] Error
at upA (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:32115:39814)
at cpA (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:32115:38717)
at fpA (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:32116:5088)
at uol.run (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:32116:9098)
at async art.runAgentLoop (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44360:7632)
at async wOl.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44408:8884)
at async wOl.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44408:9837)
at async ALe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:32182:15752)
at async Js (vscode-file://vscode-app/c:/Users/Professional/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:43415:4781)”

Additional Information

I launch the IDE with the no proxy server flag. Could this be a connection timeout to the API provider or an internal routing issue Is there a log file where I can see exactly what network request is hanging

Does this stop you from using Cursor

Yes - Cursor is unusable

1 Like
3

Hey, thanks for the report.

A couple things to check:

  1. Are you using your own Gemini API key (BYOK) or Cursor’s built-in models? This matters because the fix is different in each case.

  2. Your exact Cursor version: go to Help > About Cursor and copy paste the full version info here.

  3. Run network diagnostics: Cursor Settings > Network > Run Diagnostics, then share a screenshot of the results.

  4. Try disabling HTTP/2: press Ctrl+,, search for “HTTP/2”, enable “Disable HTTP/2”, then restart Cursor.

  5. Temporarily try a different model (like Claude Sonnet 4.6 or Auto). Does the same issue happen, or is it Gemini-only?

About the --no-proxy-server flag, why are you using it? If you’re on a corporate network or using a VPN, that’s important context.

The resource_exhausted error means the Gemini backend is hitting request limits. This is a known issue the team is tracking. Switching to Auto can help since it can route requests away from overloaded endpoints.

Send your answers to the questions and we’ll go from there.

4

Same issue here, only with gem 3.1

1 Like
5

Same Issue.

I am using my Gemini API.

6

Same issue here, constantly seeing ‘failed to connect to the model provider’. other models are fine and codex is running alongside it with no issues.