Describe the Bug
-
Basics to get out of the way:
Using a M1 based MacBook Pro on macOS Tahoe v26.4.1. 64GB memory, big HD’s with 8TB internal SSD. Xcode Version 26.5 (17F42). So a relatively modern machine with up to date software.
-
Cursor can work itself into a bad code generation loop. I find that I spend way too much doing debugging and reverse engineering Cursor (Claud) generated code. Cursor can break something when I’m trying to add some new feature. Then I try to fix what got broken and Cursor finds another way to break something else. This can go on for several rounds. I have to roll back often. Sometimes Cursor gets in a rut and just can’t find a way out so I have to tell it that it is screwing up and to try some specific way to look at a problem. This is causing me to spend more than half of my compute and billing.
-
Sometimes Cursor can get stuck in some background process that I notice it two ways, the first is that everything just slows down. I can’t enter text into Cursor at my typing speed. Cursor starts taking forever to respond or to process whatever. The other way I notice this is through my desktop CPU process monitor, a widget in my Menu Bar. I remedy this issue by restarting Xcode and/or Cursor. A reboot might be needed from time to time.
-
I wish there was a direct way to dispute billing with Cursor.
-
This forum is fine for problem reports such as this.
Steps to Reproduce
I can, and unfortunately do, reproduce this bad code generation loop problem far too often. The excessive CPU problem as occurred twice in the last 48 hours. Unfortunately I cannot tell you how to reproduce this problem. It just happens with heavy use of Cursor.
Expected Behavior
I expect Cursor to do what I tell it and only what I tell it. Way too many times Cursor takes too many liberties with its code generation. It should ask the user for clarification when it feels like exceeding the minimum requirements to satisfy a request.
Operating System
MacOS
Version Information
Version: 3.7.36
VS Code Extension API: 1.105.1
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.4.0
For AI issues: which model did you use?
Auto but I’m switching to ChatGPT 5.5 as an experiment.
Additional Information
Cursor appears to be working… most of the time.
Does this stop you from using Cursor
No - Cursor works, but with this issue
Here is a Cursor admission of guilt after struggling through several iterations of finding/fixing a bug only to have it reoccur several times:
Me: We went through several interations of this bug. Why didn’t you catch it earlier? Better yet, why did you generate it at all?
Cursor: You’re right to be frustrated.
Why I didn’t catch it earlier: I chased the symptom too broadly. The crash said “Task … arithmetic overflow,” and I first patched plausible async counters and mesh-size arithmetic instead of insisting on the exact stack frame. Once you provided RiverFlatTerrainProfile.swift, the cause was obvious. I should have asked for that frame immediately and avoided speculative fixes.
Why I generated it at all: it was a bad shortcut. Packing (q, r) into a single Int with q * constant + r is convenient, but unsafe unless the coordinate ranges are tightly proven and guarded. In this app, terrain/map coordinates can get large enough that proof was not there. The correct design was a hashable coordinate struct from the start.
The lesson is concrete: no arithmetic key packing for grid coordinates in this codebase. Use typed keys like AxialKey(q:r:).
Hi Leigh! A few distinct things here, so splitting them out.
Code quality / scope creep (breaks one thing while fixing another)
-
Use Plan mode for anything non-trivial. It has the agent lay out its approach first so you can correct course before any edits land, instead of discovering the over-reach afterward.
-
Keep requests tightly scoped. Smaller, single-purpose asks loop far less than broad “fix all of this” prompts.
-
Pin one strong model for tricky refactors instead of Auto. Auto is built to route across available models; pinning one (your GPT-5.5 experiment is worth continuing) gives more consistent behavior across a long debugging session.
-
Roll back with Checkpoints rather than asking the agent to undo its own mess. Each agent turn creates a checkpoint you can restore to, which is cleaner than another “fix what you broke” round. Checkpoints
-
Add a project rule to enforce your “do only what I asked” expectation. A .cursor/rules file applies on every request, e.g.:
Only make the change I explicitly request. If a fix requires touching anything outside that scope, stop and ask first.
Your “no arithmetic key packing for grid coordinates — use AxialKey(q:r:)” lesson is a great candidate for a rule too, so the agent stops reintroducing it. Rules
Slowdowns / high CPU This is a known issue we’re actively working on, and it matches what you’re seeing (typing lag, sluggish responses, cleared by a restart). In the meantime:
- Close agent sessions you’re done with instead of leaving many open at once.
- Reload the window / restart periodically during long sessions (which you’re already doing).
- Stay on the latest version - perf fixes are shipping regularly.
If it keeps biting, the fastest way for us to pin it is a Process Explorer capture during a slow moment (Cmd+Shift+P → “Developer: Open Process Explorer”) so we can see which process is eating CPU, ideally with a request ID from that period. Reporting bugs / request IDs
Billing For anything billing-related, email [email protected] - the team can look at your account directly and that’s the right place to sort out usage and charges.
Let me know how the Plan-mode + project-rule combo works out on the code-quality side.