Inefficiency - > 70% of tokens wasted

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.

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.

There is a third one.

:backhand_index_pointing_right: Read previous Cursor Chats and …

It will automatically read only relevant chats, what was asked, what was decided and what was delivered in similar requests.

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.

Here is my way to use Cursor effectively.

  • 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 hit the quota limit just a few days before when I did not apply the above way :smiley: Hope this can help you!
Romantic Developer from Vietnam.

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.

“Given the Cursor never applies the ‘mandatory’ rules” describes two failures, and only one of them belongs to the model. The first is mechanical. A rule in .cursor/rules is read only when it is an .mdc file with frontmatter; a plain .md there is ignored. An .mdc whose frontmatter has a description but no alwaysApply: true is the type the agent includes only when it judges the rule relevant, which for a rule you call mandatory is backwards. Open each file: the first three lines must be ---, alwaysApply: true, ---, and the Rules tab under Customize shows the status of every rule. The lessons file does not load itself either: it is read when the always rule says “read docs/lessons.md before editing anything” and gives the path, because the agent does not go looking. An AGENTS.md at the repository root is read as well, and nested ones in subdirectories are combined with it, so the PowerShell rules can sit next to the PowerShell code.

The second failure is that models ignore instructions they did read, and for syntax errors I stopped treating that as a rules problem. A rule is a request; a gate is a fact. A stop hook runs when the agent believes it is finished, receives {"status": ..., "loop_count": ...} on stdin, and if it prints {"followup_message": "..."} on stdout that text is submitted as the next user message, up to loop_limit times. So .cursor/hooks.json becomes {"version": 1, "hooks": {"stop": [{"command": "pwsh -File .cursor/hooks/gate.ps1", "loop_limit": 3}]}}, and gate.ps1 walks git diff --name-only HEAD plus untracked files: for every .py it runs python -m py_compile, for every .ps1 it calls [System.Management.Automation.Language.Parser]::ParseFile($f, [ref]$null, [ref]$errs) and collects $errs, and for every text file it decodes the bytes as strict UTF-8, fails on the first byte that is not, and fails separately on a leading BOM, which strict decoding accepts. Whatever fails goes into the followup message verbatim, with file and line. Up to that limit the agent cannot declare the task done with a file that does not parse, and it fixes the error while the context that produced it is still loaded, which is the cheap moment. The same diff list answers “unauthorized and invisible changes”: any file in the diff that was not named in the task is listed under “explain or revert each of these”, and a commit before every session keeps that list exact.

Version facts belong at the top of the always rule as values, not as advice. “Use correct PowerShell syntax” is ignored because it carries no information; “pwsh 7.4 and never powershell.exe 5.1, so && is legal and -Encoding utf8 writes without BOM; Python 3.12; every file UTF-8 without BOM” gets copied because it is specific. Paste the output of $PSVersionTable.PSVersion and python --version rather than typing them from memory, and keep the rule under 500 lines, which is the documented guidance and far above what gets followed.

On the lessons file, three things made it useful instead of long. One: one lesson per entry, with the trigger in the first sentence (“when a .ps1 calls python, …”) so the agent can match an entry to the task instead of reading forty and keeping none. Two: an outcome mark. A lesson that was applied and held is worth more than a lesson written after a bad evening, and without the mark the file accumulates both at equal weight; the agent appends “applied, held” or “applied, did not hold” to the entry it used, and entries that never fire in a month move out. Three: a correction is a new dated entry next to the old one, not an edit of it, because the record of what was wrong is itself a lesson and because two contradicting entries side by side are visible in a way a silent overwrite never is. The cheap test at session start is to ask the agent to quote the three lessons it thinks apply before it touches code; if it quotes nothing, the file was not loaded and the next hour goes where your 70% went.

Disclosure: I work on a memory product, which is why I have opinions about this; nothing above depends on it.