Cancelled 2x Cursor Ultra plans, here's why
7 comments
> I should just use these models more carefully as they could consume a lot of tokens when they are thinking.
Support is right. You cannot ever use a pay-as-you-go service unconsciously. This isn't an all-you-can-eat buffet, they're Tracfone minutes and you'll spend them accordingly.
If you can't square that mentally, maybe the big expensive models aren't a good match for your workflow.
Support is right. You cannot ever use a pay-as-you-go service unconsciously. This isn't an all-you-can-eat buffet, they're Tracfone minutes and you'll spend them accordingly.
If you can't square that mentally, maybe the big expensive models aren't a good match for your workflow.
If you read my post carefully you can see that the problem is not the cost of the models or the way I use them but something that is not just hidden from the Cursor UI but misleading. It keeps displaying a 200k context limit and also uses summaries to manage the context. You can only see that it pulled 21M tokens worth of data from Anthropic cache for a 4000 token prompt if you export your usage as a csv and analyse.
> It keeps displaying a 200k context limit
Some radiometers cap-out at 3.6 roentgen because they assumed that nobody would need a larger figure. That doesn't mean that 3.6 roentgen is the hard-limit on radiation, though.
Again - any PAYG product requires very explicit discipline to avoid getting smacked with a shady bill. AWS, Vercel or Claude.
Some radiometers cap-out at 3.6 roentgen because they assumed that nobody would need a larger figure. That doesn't mean that 3.6 roentgen is the hard-limit on radiation, though.
Again - any PAYG product requires very explicit discipline to avoid getting smacked with a shady bill. AWS, Vercel or Claude.
I think we’re talking past each other a bit.
This isn’t really about PAYG discipline or being surprised by a big bill. I had a spend cap. The problem is that, because of how Cursor implements caching, that prepaid usage got consumed in a way that was impossible to see or reason about ahead of time. I didn’t “overspend,” I just got far less actual work out of the same budget than I reasonably should have.
Also, the 200k context cap is a real cap. Claude does not attend to more than that. Cursor even summarizes aggressively to stay within it. The confusing part is that billing is driven by something else entirely: replaying cached prompt state that the UI implies is no longer relevant.
So from a user’s perspective, you’re operating inside a 200k window, MAX is off, prompts are small, and things look normal. Yet each call can still replay tens of millions of cached tokens that you never see and can’t inspect without exporting CSVs after the fact.
That’s very different from “you used more than you thought.” It’s more like the primary cost driver is invisible and contradicts the mental model the product presents. If the UI showed cache size or warned that a call would replay ~20M cached tokens, I’d agree this is just normal PAYG behavior. But it doesn’t.
That’s the issue I’m pointing out.
This isn’t really about PAYG discipline or being surprised by a big bill. I had a spend cap. The problem is that, because of how Cursor implements caching, that prepaid usage got consumed in a way that was impossible to see or reason about ahead of time. I didn’t “overspend,” I just got far less actual work out of the same budget than I reasonably should have.
Also, the 200k context cap is a real cap. Claude does not attend to more than that. Cursor even summarizes aggressively to stay within it. The confusing part is that billing is driven by something else entirely: replaying cached prompt state that the UI implies is no longer relevant.
So from a user’s perspective, you’re operating inside a 200k window, MAX is off, prompts are small, and things look normal. Yet each call can still replay tens of millions of cached tokens that you never see and can’t inspect without exporting CSVs after the fact.
That’s very different from “you used more than you thought.” It’s more like the primary cost driver is invisible and contradicts the mental model the product presents. If the UI showed cache size or warned that a call would replay ~20M cached tokens, I’d agree this is just normal PAYG behavior. But it doesn’t.
That’s the issue I’m pointing out.
I found out the hard way. I get a lot of value in cursor but I shouldn't be maxing out a 20x membership in a day of use...
I'm curious about the people who are like "Look at my workflow, I run 10x agents at a time", are they just running 10k per month bills to their employer? In which case it's like "Neat, cool story bro"
I keep tech bros flexing their coding agent bills every day. "I've spent 10k$ on Cursor today AMA"
I just canceled two Cursor Ultra plans. My usage went from a steady ~$60–100/month to $500+ in a few days, projecting ~$1,600/month. Support told me this was “expected.”
I did not suddenly start doing 10x more work.
Cursor shows a 200k context window and says content is summarized to stay within limits. Pricing is shown as $ per million tokens. Based on that, I monitored my call count and thought I was being careful.
What I did not realise: - Cursor builds a very large hidden prompt state: conversation history, tool traces, agent state, extended reasoning, codebase context. - That state is prompt-cached. - On every call, the entire cached prefix is replayed. - Anthropic bills cache read tokens for every replay. - Cache reads are billed even if that content is later summarised or truncated before inference.
So the UI says “max 200k context”, but billing says otherwise
Concrete example from my usage:
MAX mode: off Actual user input: ~4k tokens Cache read tokens: ~21 million Total tokens billed: ~22 million Cost for one call: about $12
Claude never attended to 21M tokens. I still paid for them.
This was not just Opus. It happened with Sonnet too.
Support explained that this is exactly how the API is billed so there wasn't an error and I should just use these models more carefully as they could consume a lot of tokens when they are thinking. But there is a limit to that and what I was charged was way high. There is ZERO transparency about how the cache is used. And the cache breakpoints are decided by Cursor so I don't think it's fair to throw the ball to Anthropic here.
The dangerous part is that cost becomes decoupled from anything you can see or reason about as a user. You think you are operating inside a 200k window, but you are paying for a much larger hidden history being replayed over and over.
I am not claiming a bug in Anthropic’s API. This is a product transparency issue. If a tool can silently turn a few hundred dollars of usage into four figures because of hidden caching behaviour, users need much better visibility and controls. Support suggested spend controls but I am actually complaining about how my pre-paid package was consumed.
If you use Cursor with long-running chats, agents, or large codebases, check your cache read tokens carefully. The UI will not warn you. The only thing you will see is a few days into your subscription "Your are projected to run out of your usage allowance in a few days"
I canceled and moved on, giving Claude Code a shot until this is fixed. Posting so others do not find out the hard way.