I am posting this as a technical warning for everyone using the new Claude 4.5 Sonnet (Thinking) model with Agent/Composer mode on the latest v2.4.x builds.
There appears to be a critical “Recursive Loop” bug where the Agent gets stuck in a “Reviewing/Examining” state, causing the Cache Read count to explode exponentially without producing matching output.
The Technical Pattern (Check your logs):
I analyzed my usage logs during a 28-hour period where the Agent was active. The data reveals a massive disparity that confirms a software loop:
Total Usage: ~96 Million Tokens
Cache Reads:82.9 Million (The Agent kept re-reading the context endlessly)
Actual Output: Only ~800k Tokens
Ratio: ~100:1 (Cache Read vs Output)
Symptoms:
The IDE shows “Reviewing” or “Thinking” for extended periods.
No new code is generated, but the token counter runs in the background.
Happens specifically with Agentic workflows involving .NET or larger Node contexts.
Recommendation for Users:
Please monitor your “Usage” tab immediately if you are using the Thinking model. If you see high “Cache Read” spikes with low output, switch back to the Legacy Claude 3.5 Sonnet until a patch is confirmed.
For Devs:
This seems to be an issue with the context-clearing logic in the new Agent mode, leading to a runaway cache-read loop. Logs attached for technical analysis.
The pattern is clear. You have normal requests too (ratio 3–12:1), and also abnormal spikes (ratio 130–274:1). That means the problem is triggered by certain conditions, not all the time.
The most critical cases from your data:
07:55:24 - 5,58M cache read / 20K output = 274:1
10:05:10 - 3,98M cache read / 17K output = 224:1
To debug this, we need to understand what exactly is causing the spike:
Request ID from any of the problematic requests (Privacy Mode off)
What actions or prompts happened right before the spike
Project size, how many files, what kind of codebase
Repro steps, can you reproduce it
For now, the workaround is to switch to Claude 4.5 Sonnet (non-Thinking) or other models.
Thanks for the analysis. I appreciate you confirming the “Abnormal Spikes (Ratio 274:1)”. This validation is crucial because Support initially dismissed this as “expected behavior.”
Here are the requested details to help debugging (and to confirm this was a system loop):
1. Project Size (The Critical Proof): The project is very small.
Total Files: Only ~130 files combined (Monorepo: .NET Core API + React).
Structure: Standard ignores applied (bin/obj/node_modules excluded).
The Logic: It is mathematically impossible for a human or a working agent to consume 96 Million tokens on a 130-file codebase in 24 hours. The Agent clearly entered a recursive loop where it re-read the entire cache thousands of times.
2. Request IDs & Privacy: I checked my settings and “Data Sharing” is ENABLED on my account.
This means the detailed logs are available on your server.
Why no ID? The sheer volume of the loop (millions of events) has rendered my local Cursor “History” UI completely unresponsive/laggy. I cannot scroll to find specific IDs without the app freezing.
Action: Since you have the timestamps of the spikes (e.g., 07:55:24 UTC and 10:05:10 UTC), please use those to pull the server-side logs. You will see the Agent stuck in “Reviewing…” mode.
3. Repro Steps: Trigger: Using Agent/Composer mode with Claude 4.5 Sonnet (Thinking) for refactoring logic across 2-3 files. I cannot reproduce it now because my entire monthly quota is dead (0 tokens left) due to this bug.
Next Steps: Since you have identified these as Abnormal Spikes caused by certain conditions(system fault), could you please coordinate with the billing team? I have an open ticket, but I need this technical confirmation to override the initial rejection.
I am currently in a deadlock because I physically cannot provide the specific Request ID.
Please see the attached screenshot: Whenever I try to scroll back to the “96M token session” to copy the ID, the Cursor app freezes and crashes immediately (“Window is not responding”). The session data is too massive for the UI to handle.
Action Required: Since “Data Sharing” is Enabled on my account, the logs are available on your server. You have already identified the specific timestamps of the “Abnormal Spikes” in your previous reply:
07:55:24 UTC
10:05:10 UTC
Could you please use these server-side timestamps to investigate? I am sitting at 0 tokens and cannot work until this is resolved.
