I don’t even use MCP, just the regular agent. Usually Claude for planning and Composer 2 for executing.
I am on Ultra. and I keep close track of the percentage usage on the dashboard.
and I noticed how quick it is increasing.
I mean, my plan renewed, and I hit 4% usage after 3 prompts that did not even work that much.
Something is definitely going wrong.
Maybe it is time to jump to Claude Code if the consumption is getting this bad.
I just managed to spent my entire $70 in a single day. Not knowing this is happening. Got my Pro plan yesterday… and today back to Composer 
I was not aware that It will consume everything in my workspace in one go… Where can I know what was actually sent to the model ?
I agree…
One practical distinction that helped me debug this is separating “normal context growth” from “billing/usage anomaly.” A simple sanity check is to export the Usage CSV and group by request/session, then flag rows where cache-read is extremely high while output is tiny, or where cache-write unexpectedly drops to zero for the same workflow/model.
I’m validating a small local-first usage-audit idea for Cursor/AI-coding bills: it would ingest only exported usage CSV/log rows locally, cluster normal agent-mode context growth vs suspicious cache/billing patterns, and produce a short support-ready summary without uploading code or private prompts. Would that actually be useful to people in this thread, or is the bigger blocker still Cursor-side visibility/refund policy rather than analysis tooling?
I’m seeing similar behavior, and the concern for me is less about whether cache reads technically exist. I understand that cached context can be reused across multiple internal calls, and that a single visible request may represent several LLM calls behind the scenes.
The problem is the lack of transparency.
I’m on Cursor Pro+, already paying $60/month, and I usually don’t hit my limits too aggressively. But once I do hit the usage limit and On Demand kicks in, I have it capped at $40, and somehow that can get burned through within a few hours. I’m now at roughly $50 in On Demand spend on top of the subscription.
From the user side, that feels bad. It may be explainable internally, but the reporting does not give enough detail to build trust.
What I’d want to see is a clear per-request breakdown:
-
how many internal LLM calls were made
-
which models were used
-
what was counted as input, output, cache write, and cache read
-
whether repo files, rules, MCP tools, previous chats, or agent/tool outputs were included
-
why a small or focused request can generate huge cache-read numbers
Right now, the answer seems to be “that’s normal,” but normal is not the same as transparent. If a $60/month Pro+ plan can still spill into another $40–$50 of On Demand spend this quickly, users need better visibility and better controls.
Honestly, at that point, I’d rather Cursor offer a real higher-tier plan with clear limits than make the experience feel like invisible metered usage after the subscription runs out.
Cursor is a tool a lot of us genuinely like, which is why this is frustrating. The current usage experience makes it feel less developer-first and more like users are being asked to trust a black box with their wallet.
Have you had a chance to explore the Context Report that’s now available in Cursor?
It gives you full visibility into every piece of context sent to the model, along with every tool call and every turn. While it doesn’t break things down at the granular level of “these specific tokens were input, output, or cache read/write,” it still provides a lot of useful insight.
Hi @Melissa_Li Thank you for your post. Your post was tagged as a billing / invoice question and it was auto-hidden by our auto moderation software. We auto hide billing / invoice questions on the forum for security purposes and the individualized nature behind each of them.
Please reach out to [email protected] from your Cursor email and we can take a look at your account. The forum, being a public place, isn’t the best place for billing/invoice related questions