After using Cursor virtually every waking minute of every day for more than 18 months and 5.6 Billion tokens later I can report that more than 70% of the tokens were spent fixing Cursor induced, repetitive errors.
In most instances the errors were consistently repeated syntactic errors that could have been avoided by having knowledge of PowerShell and Python versions. Of course, the other than UTF-8 mis-codings continue to plague software development and token costs.
The consequence of those inefficiencies have more than quadrupled testing time and costs, mostly because of syntax errors and the model arbitrarily making unauthorized and invisible changes to the code.
While Cursor and the underlying models have made it possible to develop complex prototypes, overall the code is of such poor quality that it requires extraordinary effort and expense to ensure the code is production ready.
Two key methods that i have used to reduce development time and errors is to 1) have each agent session record Lessons Learned, which future agents can refer to and immediately learn what not to do and what to do, and 3) effectively keep laboratory notebooks (.md files) on all artifacts that are built, requirements, architectures, data management standards, etc.
Given the Cursor never applies the “mandatory” rules, I commonly tell the agents to read the rules and lessons learned. That has helped immensely, but not sufficiently
I am interested in hearing from other developers about their experiences and methods for reducing costs, improving efficiencies and improving code quality and reliability.
The Lessons Learned + notebook approach is smart — I’ve done something similar with architecture decisions.
One narrower slice of the token-waste problem I’ve been chipping at: a lot of wasted back-and-forth comes from the agent guessing at how my own codebase is structured (what calls what, where something’s actually defined) instead of knowing it — it reads a few files, infers, and is sometimes wrong, which costs tokens fixing the wrong assumption. I built an MCP server that gives it the real parsed call graph instead of letting it infer from text (happy to share details if useful) — doesn’t touch your syntax/version-mismatch issues though, that’s a different beast entirely.
Completely agree. The economic cost of AI induced mistakes is a much bigger problem than token price alone. That’s one reason I’m exploring repository level reasoning with Meeba Brain — reducing the number of wrong assumptions an agent makes before it starts changing code.
Same experience. To go (very) short. Cursor equals bug factory. There’s no way around it. It has become an income spiral of LLM tokenspam, hallucinating models resulting in poor buggy code. The push towards vibe coding makes this even worse.
Addiction to vibe coding is the businesscase now, creating a whole other problem to society, but worth Trillions…
(and yes, I also tell it to follow rules and .md almost 80% of the time, because it just doesn’t)
The 70% tracks, but there’s a second drain in Cursor nobody counts, because it
doesn’t look like a wasted token. It looks like a failed request.
Images. Two hard errors, both from the model provider rather than Cursor: a
maximum of 20 images per request, and “Maximum dimension: 2000 pixels”. The
second one leaves the chat broken. In https://forum.cursor.com/t/stuck-on-max-image-error/145505
even text-only follow-ups kept failing until the user opened a new chat.
Your notebook fixes the half where the agent made a mistake it could learn from.
This half has no mistake in it. The agent is hitting a wall it can’t see.
On the dimension one specifically: on current versions, Cursor automatically downscales images before they’re sent to the model, so an oversized image shouldn’t hit that “Maximum dimension: 2000 pixels” wall or leave the chat stuck the way the older thread describes. I just ran a few paths to check - a very large pasted image, an image opened via the read tool, and a full-page browser screenshot - and each one got downscaled and went through fine instead of erroring. If you’re still seeing a chat get stuck on that dimension error on a recent build, reply with your version and a rough repro and I’ll dig in.
The 20-images-per-request limit is a genuine model-provider cap, so that’s the one we can’t work around. If you hit it, starting a fresh chat is the cleanest way through for now.
Mine is 5.8B since the beginning of June!
I paste a lot of images and I’ve been using voice more - I wonder if that is part of it - too much waffling ;-D
I was using quite a lot of GPT but it started gobbling up too much quota.
This is why we refuse to use Cloud Agents. So much time and effort by the bots on creating crap code or changing existing code in bad ways. Which then requires another review to fix that code which can break even more, especially if its starts looping solutions.
The solution that’s kept things much better has been manual review of every generated code. I’ve seen all models of all kinds just do some of the stupidest things while coding. Like yesterday Sonnet 5 while changing other code just randomly decided to go into an unrelated file and just delete 5 lines of code. There was no reason for it to be in that file, the change didn’t make any sense, and in the end after seeing what it did there was literally no justifiable reason for its change.
This is now how we do things with the latest models and its the only one that truly avoids loss or crap code injection.
Plan with a high end model
Be very very specific with the plan
if even slightly unsure the AI could misinterpret, solidify it so it can’t.
Have the plan implemented
Manually review everything
Do not use AI to correct at this point as it may do more harm and waste time than be helpful.
Debate with like Composer on the side(yay side chats) about code you’re not sure about. Can it be improved, is this really the best way?, why not we do this instead because of it’ll be affected by “this”.
Make your own changes and improvements to the code
Run tests and even test manually
Once a month too we have latest Opus do a final review of a bigger chunk of the code base that includes ones that were changed earlier. However just doing steps 4 and 5 have caught so much stuff it’s unbelievable.
For the time being one really has to treat AI models as them being junior developers at their first job. However, throughout the many years I’ve been in software dev I can’t think of one time I’ve had a junior developer go into a random file and just delete or change code completely unrelated to anything they were suppose to work on. Yet I’ve caught AI doing it more times than I can count at this point.
Utilize every tool as scripts. For example: you want to research something online? Need to read a web page? Then do not let the sub-agents do the work repeatedly. Build yourself a script to scrape the content with a structured output.
Skill is useful if your skill is not a big documentation where every single piece of knowledge is inside. Keep it simple and use your scripts/tools above. The skill should only be the workflow for doing something.
Always use plan mode before implementation. If your planning workflow is repeated the same way every time, then use it as a skill.
Keep your docs folder updated and always be the single source of truth; new implementation/fix cannot be wrong.
I have been using Cursor since 2024, from the Education program to Pro Plan. I spent around ~1B of tokens every month through daily usage.
I think the only way out is to choose a better model or wait for the model to improve so they don’t make those mistakes in the first place.
Grok 4.5 often make powershell and python syntax errors, i put related info in the agents.md, or make a skill, they still violate them often.
But these problems almost not happening anymore since grok 4.6.
Current models still stuggle to clearly grab the right info in memory and make right decisions accordingly, even problematic down to prompt obediance. The info is there, but simply ignored, even the smartest model make such mistakes often.
This makes any agentic level developing pointless. You only ease it by a little bit, never cure.
Read previous Cursor Chats and …
Hope this can help you!