Connectivity issues abruptly break running streams of changes only when connected to Gemini models

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Connection to a Gemini model (e.g. 3.0 flash or 2.5 flash) gets unexpectedly interrupted after multiple changes were executed with the following error:

Unrecoverable agent model looping detected.

The only option is to “Try again” but that reverts all changes made by the model since the last message sent by the user.
This has started happening since Dec 23rd on multiple occasions when connected to Gemini models.
The result is a LOST work progress but RECORDED token usage that counts towards the limit!

Steps to Reproduce

Use any Gemini model to make multiple changes i.e. for several minutes and the connection will get interrupted, it will definitely happen when used for longer tasks.

Expected Behavior

No connection breaks that cause lost tokens usage due to losing progress as the only remediation is to retry from the last checkpoint (last received request by the user).

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.50 (user setup)
VSCode Version: 1.105.1
Commit: 56f0a83df8e9eb48585fcc4858a9440db4cc7770
Date: 2025-12-06T23:39:52.834Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Gemini 3.0 flash but it also happened with Gemini 2.5 flash.

For AI issues: add Request ID with privacy disabled

Request ID: a4121ab1-ea1f-4517-9ce8-1c8b28579aae
{“error”:“ERROR_CUSTOM_MESSAGE”,“details”:{“title”:“Unrecoverable agent model looping detected”,“detail”:“Unrecoverable agent model looping detected.”,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

2

Hey, thanks for the report. This is a known issue, and the team is working on improving the stability of Gemini models. Loop detection can sometimes trigger incorrectly during long tasks with many changes.

To help the engineers, could you share:

  • 2–3 additional Request IDs from different failures (Chat → top-right menu → Copy Request ID)
  • Approximate time the agent ran before it stopped (seconds/minutes)

Temporary workaround:

  • Try splitting the task into smaller parts instead of one long request
  • Use Claude 4.5 Sonnet or GPT-5 for long tasks. They’re more stable right now
  • Start a new Agent chat for each task

I’ll pass your Request ID to the team for analysis.

3

Hey Dean, thanks for replying so quickly.

I’m sharing 2 additional Request IDs from the last 2 days:
28a9d62d-79a7-420a-b752-d7fe217ce5e2
0774159c-4b5e-4c65-8f0e-5c5a1fee9d8a

The agent ran for approximately 3-4 mins (or more in a one or two cases) before the loop detection break but I noticed that since Dec 24th it has started to break within 10 to 30 seconds of running tasks so I stopped using Gemini.
A problem for me using Claude 4.5 Sonnet or GPT-5 is that they’re quite expensive.
I tried using GTP only for planning but that also seems to charge many output tokens.

1 Like
4

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.