Hey all I experience some excessive Composer 2 token consumption today - wanted to know if anyone had similar experience.
I have been working in my codebase for about 6 months now and have a good handle on what types of tasks or builds consume what amount of tokens and what it costs me.
I wouldn’t be writing this unless it was shocking - I performed a build today
1 rule applied
~30 document reads
~15 document edits
Token consumption was 4.5M at a cost of $5.50!
Similar tasks in the past have been easily 1/10th consumption and I would expect it to take. Similar tasks in the past on both Composer 1.5 and Composer 2 have been more akin to $0.5 to accomplish. Is anyone experiencing the same today?
Thank you for reporting this. Do you feel comfortable sharing the request ID with me? If you have privacy mode enabled, do you mind switching it to Share Data in Cursor Settings, re-creating the issue, and then sharing the request ID with me? This will help me take a closer look at the request and see if something is going wrong. Cheers!
Hey,
I just found this thread when searching for exactly this issue. My token usage exploded massively too. Super simple requests in a new project. Last 3 request with 400k - 3,7m tokens - never above 100k before.
I’ve enabled data sharing - here is my request_id: 93d5043f-4763-49ed-bd02-cb51d5250211
Something seems off
He @Nicolas_Heiligenthal really appreciate you hopping in here and sharing your session - wish I could as well but my hands are tied there.
Want to communicate I switched to Sonnet 4.6 with more consistent results to my previous experience with Composer. Will revisit Composer 2 in several weeks to see if it’s improved.
Hi @Nicolas_Heiligenthal Thanks for sharing the screenshot and the request ID. I can’t see information about your requests because of your current privacy mode settings. If you feel comfortable, do you want to disable privacy mode temporarily and see if you can re-create a similar request that generates this potential issue? You can re-enable privacy mode immediately after.
Hi guys! It’s happening with me too. Since last month, any session using Composer 2 consumes a huge amount of tokens.
In less than an hour using Composer 2, with only a few sessions, it used a total of $10. I had a $5 on-demand limit, increased it to $20, and in less than an hour it consumed everything.
This seems unusually high compared to previous usage. Has anyone else experienced this? Is there something that changed recently with Composer 2 token consumption?
Same thing here.
I have been intentionally watching my usage and I just noticed that a simple doc editing task burned 1.5M tokens!
I asked the Agent to summarize work done:
“Effort for the agent: One multi-file pass with search/replace and small structural rewrites; moderate length because several long spec sections had to stay consistent across files”
My workflow did not change, I am using Composer 2 only (not the fast version) and until recently usage was moderate but in the past couple of days I noticed a HUGE increase even for small tasks.
Same Here! A small UI change in placement of an Icon burned up almost 1M tokens. I just started using haiku-4.5 after that instead of Composer 2, I realized after about 15 messages (8M tokens)
I’ve been noticing a consistent issue with Composer where even very small UI changes or minor daily bug fixes are consuming an unexpectedly high number of tokens — especially cache read tokens.
What I’m Observing:
Even with fresh chats and new tasks, the system is consuming very high cache read tokens (sometimes exceeding 1M).
The task itself can be very small to medium (e.g., a minor UI tweak or a simple/medium fix), but token usage doesn’t scale proportionally.
It feels like Composer is pulling in a large context or previous state unnecessarily.
Why This Is Concerning:
Makes it difficult to estimate or control usage.
Impacts performance and cost efficiency.
Doesn’t align with the expected behavior for isolated or fresh tasks.
Questions:
Is Composer reusing hidden context or system-level cache even in new chats?
Are there best practices to reduce cache read usage?
Should we structure prompts differently to avoid this?
Would really appreciate if anyone from the team or community can clarify:
Whether this is expected behavior
Or if there’s a way to optimize and reduce cache consumption
I am also seeing MUCH higher token usage when selecting Composer 2. I’ve been happy with the output, but the increased cost from token usage far outweighs the price per token discount. I don’t think the complexity of my tasks accounts for the change from pre-Composer 2 to post-Composer 2. FWIW, I only used composer-2-fast on the weekend when it was 50% off, and only for a short period of time.
Hi all, here’s a status update of where things stand. A cache read problem involving Composer 2 was fixed on April 6th that aligns with the exact symptoms that were witnessed here.
However, it is a bit concerning that a lot of you are still seeing similar issues more recently than that. The April 6th fix was a server-side fix, not a client fix, so those issues should have started showing an improvement right away. I’m going to dig into a few of these request IDs now and see if I can observe any patterns.
This is still happening. A simple usage consumed 10M tokens, completely unnecessary. Using Composer is becoming unsustainable. It would be nice if Cursor offered some kind of credit to those experiencing this, as it’s extremely unfair.
5 requests. 17 million in auto mode at a cost of $21 insane!
5 requests at a cost of 21 dollars is excessive for use in auto mode, which is supposedly meant to be efficient, “supposedly”.
I’ve been using Cursor for over a year and every day, I used to spend an average of $60 ± $80 a month.
This month I switched to the Pro+ plan since my account was $20 and I was already spending $60.
As soon as I changed the plan, I used it for an hour or two and it simply used 100%, in one day it spent the $60 and to confirm the uncontrolled spending I went and added another $35 extra which was sucked up in less than 20 minutes. Something is very wrong.
