I asked Cursor Agent to implement a bounded feature in an enterprise Go project.
The Agent completed the implementation.
An independent architecture audit (Claude Code) found multiple blocking defects.
The Agent then performed a recovery pass to fix the reported issues.
After the recovery, a second independent audit still found blocking defects.
During this workflow the Agent consumed approximately 13 million tokens and exhausted almost my entire $5 on-demand budget in less than one hour.
My concern is not the cost itself.
My concern is that the Agent required a very large amount of reasoning/context while still failing to produce a correct implementation after multiple attempts.
Steps to Reproduce
Open an enterprise-sized Go repository.
Ask Cursor Agent to implement a bounded feature (not a full project).
Let the Agent complete the implementation.
Perform an external architecture/code audit.
Ask Cursor Agent to fix the reported issues.
Perform another audit.
Observed result:
Agent consumes millions of tokens.
Multiple recovery passes are required.
Blocking defects may still remain after recovery.
Expected Behavior
For bounded implementation tasks I expect:
Lower context/token consumption.
Better first-pass implementation quality.
Recovery to resolve all reported issues.
More efficient repository/context usage.
Visibility into why millions of tokens are consumed.
Operating System
Windows 10/11
Version Information
Cursor Pro
Windows 11
Cursor Agent
For AI issues: which model did you use?
Cursor Agent (Auto)
Primary model: Claude Sonnet 4
Additional Information
Additional information
Repository type:
Enterprise Go application
Architecture:
Already defined before implementation.
The task was limited to a single feature implementation.
Independent audits were performed after each implementation pass.
Approximately:
13 million tokens consumed
About $5 on-demand usage
Less than one hour of work
Remaining blocking issues after recovery included:
IPv6 validation accepted while nftables renderer generated IPv4 rules.
priority=0 inconsistency between Create and Update operations.
Hey, thanks for the detailed breakdown. I’ll go piece by piece, because two different things got mixed up here, token usage and code quality.
About the model. In Auto mode, Cursor picks the model per request, not you. So Primary model: Claude Sonnet 4 in the report is an assumption, not what actually served the session. In practice, Sonnet wasn’t used here.
About the 13 million tokens. That doesn’t mean each request used a brand-new context of that size. Most of that volume, about 88%, is cache-read tokens. That’s how agent loops work. The agent rereads already collected context on each tool call, and those repeated reads are billed at the cheaper cache-read rate, not as fresh input. Fresh input is only a few thousand tokens per request on average, so there was no context bloat in your session, the metering worked correctly.
About usage visibility. A per-request breakdown (input / output / cache read) is already available at cursor.com/dashboard under Usage. That’s exactly the transparency you’re asking for.
About implementation quality (IPv6/nftables, priority=0 mismatch). That’s valid feedback, and I’ll pass it to the team. If you can share the Request ID for those runs (chat context menu in the top-right > Copy Request ID) plus the commit hashes, that would really help us dig into exactly where the agent went wrong.
A couple things that usually improve first-pass quality and reduce usage on bounded tasks:
Plan mode for unfamiliar code, the agent plans first, then executes
start a fresh chat for each task so context doesn’t get dragged along
give targeted context (@ files for specific modules) instead of expecting the agent to find everything in a big repo
Send the Request ID and we can look at the specific runs.
Thank you for the clarification regarding Auto mode and cache-read tokens. I understand how your billing works and that cache-read tokens are charged differently from fresh input.
However, my concern is not simply the number of tokens. My concern is the quality and efficiency of the agent.
During this project, the agent repeatedly analyzed the same files, revisited the same plans, and produced incorrect implementations (such as the IPv6/nftables issues and the priority=0 mismatch that you acknowledged). These mistakes required multiple retries and significantly increased the total usage before arriving at a usable result.
Because the excessive usage was directly related to the agent’s poor execution quality, I would like this case to be reviewed by your billing team and request a refund or usage credit for the affected sessions.
I can provide the Request IDs and commit hashes if needed, but I would first appreciate confirmation that this case will be reviewed as a potential service quality issue rather than being dismissed solely as expected token consumption.
Thank you for the clarification regarding Auto mode and cache-read tokens. I understand how your billing works and that cache-read tokens are charged differently from fresh input.
However, my concern is not simply the number of tokens. My concern is the quality and efficiency of the agent.
During this project, the agent repeatedly analyzed the same files, revisited the same plans, and produced incorrect implementations (such as the IPv6/nftables issues and the priority=0 mismatch that you acknowledged). These mistakes required multiple retries and significantly increased the total usage before arriving at a usable result.
From my perspective, this represents an inefficient execution rather than normal expected usage. I paid for an agent that should complete bounded engineering tasks efficiently, but instead it consumed a very large amount of usage while repeatedly making avoidable mistakes.
Because the excessive usage was directly related to the agent’s poor execution quality, I would like this case to be reviewed by your billing team and request a refund or usage credit for the affected sessions.
I can provide the Request IDs and commit hashes if needed, but I would first appreciate confirmation that this case will be reviewed as a potential service quality issue rather than being dismissed solely as expected token consumption.
Thanks for following up, and for separating the two concerns so clearly.
On the code quality side (the IPv6/nftables mismatch and the priority=0 inconsistency), that’s valid feedback and I’m happy to share the specific runs with the team. If you share the Request IDs (chat context menu, top-right > Copy Request ID) plus the commit hashes, we can look at exactly where the agent went wrong.
For the refund or usage credit part, that’s handled by our team at [email protected]. They can review your account and the sessions directly. Please include the same details there (Request IDs, commit hashes, the timeframe) so they have full context.
I can’t decide on credits from the forum, but sending those Request IDs my way still helps us investigate the quality issue on our side.