Why is cursor recently consuming an absurd amount of tokens recently? Each API request in my usage dashboard is 500k-1m tokens, 90% of which is cache write/read. I work with large open source projects but in every request I sent I make sure to attach the relevant files, both the context files and the files to edit/debug. Is cursor sending the whole project as cache write to AI providers? This is getting prohibitively expensive and it’s driving me to go back to the old ways of using claude.ai or chatgpt.com for ai-assisted code.
Do you have any MCP servers enabled?
No.
Hey, good request. No, Cursor doesn’t send your whole project. But in Agent mode, every tool call and every follow-up message is a separate API call, and each one has to include the full chat context history, the system prompt, tool call results, and so on. When you’re working with a big open source project, that context grows fast.
About cache write and cache read, that’s prompt caching from the provider (Anthropic or Google), and it actually saves money, not increases costs. Cache read is about 10x cheaper than normal input tokens. Without caching, those same tokens would be counted as full input, and the cost would be much higher.
A detailed explanation from our team with example calculations is here: Someone please explain - Why are cache read and write chargeable? - #8 by condor
A few tips to reduce token usage:
- Start a new chat for each new task, long chats build up context
- Only attach the files you actually need in context
- For simple tasks, use cheaper models
- If you’re in Agent mode, keep an eye on tool calls, each one resends the full context
Which model and which mode are you using, Agent or Ask? That’ll help me give more specific advice.
I’m observing similar thing. Previously, a monthly subscription was easily enough for me. Last time, the monthly quota ran out in about 2.5 weeks; now 40% of the tokens are gone in just two and a half days. Auto mode. My usage pattern is roughly the same.
I thought the issue might be with MCP and the rules, so I deleted most of the rules and disabled all MCPs - but it’s still the same: even a relatively minor code change request (taking about 0.5 to 1 minute to process) consumes anywhere from 1M to 4–6M tokens. Only most minor requests (like ask something) use less than 1M.
I am reporting a significant billing anomaly and a technical failure regarding the “Prompt Caching” mechanism in my account today.
After analyzing my usage data (CSV attached), I found a clear reason for the sudden cost spike I’m experiencing. While my workflow remains identical to previous days, the system has stopped caching prompts entirely today.
Data-Driven Comparison: Based on my “april usage.csv”:
-
From April 6th to April 17th: My average Cache Hit Rate was consistently above 93%. This kept my costs around $0.35 per million tokens.
-
Today (April 18th): The Cache Hit Rate dropped to 0% for every single request. Consequently, the cost per million tokens has jumped to $1.31 (a ~275% increase).
The Impact: In just 2 hours of work today, I have consumed 12 million input tokens because the system is re-reading my entire context for every prompt instead of using the cache. This has caused me to reach my usage limit 15 days earlier than expected.
Questions for the Team:
-
Why has the Prompt Caching stopped working for my account today, despite working perfectly for the last 12 days?
-
Is there a known issue with the “auto” model routing or the caching server today (April 18th)?
-
Given that this is clearly a technical failure of the caching system and not a change in my usage, can my usage credits be adjusted?
I have attached the april usage.csv which clearly shows the drop from 95% cache to 0% cache.
april usage.csv (12,9 KB)
Cursor is an amazing tool, but this lack of predictability due to caching failures makes it very difficult to manage for professional use.
i have experiencing the same thing. After running out in last month around mid of billing period, I started to collect all usage to try to figure out what I’m doing and the impact in costs. Today I have experienced a 4 times cost increase just because the cache is not working I think or not using it for some reason I don’t understand and then, today I have reached the limit. Without this increase I suppose I would have used the included usage at least 4-5 more days.
Started seeing a very similar issue today.
Through 2026-04-17, rows still carried large Cache Read volumes (mean 62,086,443.73 tokens summed per calendar day, averaged across 22 day(s)).
Cache-read flatlined at 0 today — i.e. no cache-read billing.
Mean daily recorded spend shifted from about $10.81 (those cache-era days) to $35.90 today and that was only 1/2 day so far.
The previous mean of “cache read ÷ events that day” was 544,016.87 tokens per event per day. Today cache read flatlined to a steady 0 and costs soared.
Having similar issue. Last month I had to actually try to max out my Composer 2 usage. This month 2 days after reset I am at 15% already while working A LOT less. Something either nerfed or broken. Composer 2 melting at the same rate API usage does
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.
Last month, my plan quota was hit within 2 weeks. that is crazy
I’ve already moved to claude code and my token usage has gone down dramatically while performance stayed pretty much the same
Try this!
This thread is useful because it separates two issues that often get mixed together: normal Agent-mode context growth vs. a possible cache-hit/billing anomaly.
For debugging my own usage I would want a local-first report that only reads exported usage CSVs/logs and answers:
- which requests had cache hit rate collapse or unusual cache write/read ratios
- whether the spike correlates with Agent vs Ask, model switch, MCP/tool-call count, or long chat history
- a minimal “what changed?” summary before opening a support ticket
I’m validating whether this would be useful as a small independent tool, without uploading source code or API keys. If anyone here has already exported usage CSVs/logs, would that kind of local-only auditor help, or is the main blocker something else?
Pro+ exhausted in 4 days – Feedback about Cloud Agent usage
Hi everyone,
I wanted to share my experience because I think it may help other users and hopefully improve Cursor.
I’m an independent developer working on a single personal web application. It is not a massive enterprise codebase with hundreds of developers. It’s essentially a web application built over time, and my daily workflow has remained very similar for months.
For a long time I was using Cursor Pro. Even though I occasionally reached my limits, I could usually work for almost the entire month without major issues.
I then upgraded to Cursor Pro+ because I expected a significantly larger working capacity.
The first month with Pro+ was exactly what I expected.
However, at the end of July / beginning of August, something changed.
Without changing my workflow or starting significantly larger tasks, I exhausted my included Pro+ usage in only 4 days.
At first I thought there might be a billing issue, so I opened a support ticket. The Cursor Billing team investigated my account.
They found:
- 9 unique Cloud Agents
- 60 Cloud Agent runs
- Approximately 85 follow-up requests
- One Cloud Agent (“iOS Cloud Agent on depositoplus”) reached 35 turns (34 follow-ups)
They also confirmed that there were no billing errors or infinite loops. According to them, the rapid usage was mainly caused by repeatedly continuing the same Cloud Agent conversations.
After discussing this with support, I now understand that the billing itself was considered correct.
However, I think there is still a UX problem.
As a user, I naturally expect an AI Agent to become more efficient as the conversation grows because it already knows the project.
Instead, the opposite seems to happen.
The longer the Cloud Agent conversation becomes:
- the more context it carries,
- the more tokens are processed,
- the more expensive each follow-up becomes.
If I had known this earlier, I would have opened a new Cloud Agent for each task instead of continuing the same conversation.
My suggestions
I think Cursor could greatly improve the experience by adding:
- a warning when a Cloud Agent conversation becomes expensive;
- an estimated token/cost indicator before sending a follow-up;
- automatic conversation summarization/compression;
- a recommendation to start a new Cloud Agent after many follow-ups.
I’m not asking for a refund.
I simply wanted to share my experience because my practical experience was very different from what I expected after upgrading to Pro+.
I’m also curious whether anyone else has experienced a similar increase in usage around the end of July or beginning of August, despite keeping the same workflow.
I recently ran into a very similar high token usage problem.
My Agent got stuck in an endless exploration/search loop (it kept repeating “Explored X files, Y searches” without making any real progress) and burned through over 100 million tokens. I stopped it as soon as I noticed, but the damage was already done.
I contacted support (ticket T-E70932) and asked for a usage credit for the tokens wasted by this clear bug. Unfortunately, they refused to add any credit back, saying that on-demand usage charges are non-refundable even when caused by a product issue.
This feels quite unfair. The excessive consumption was entirely due to the Agent failing to exit a loop, not normal or intentional usage. Many people seem to be hitting similar looping problems, yet we’re left paying the bill.
Has anyone else successfully gotten a credit for this kind of bug-related token burn? Or is the current policy just “you eat the cost”?
Excuse my ignorance but where did you find the view your screenshot is from? I too am seeing similar token usage and charge patterns and am trying to better understand. Do you generate them yourself or is it somewhere in the admin/settings?