Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Was delighted to accidentally start using composer a couple of weeks ago when I ran out of credits using opus. Worked amazingly and seemed incredibly affordable. Well done!
But somehow in the last 24 hours I seem to be burning through extra credits like I’m on opus (i’m not). And I’m seeing Taking longer than expected frequently. For minutes at a time. It fully froze up a couple of times and I had to reboot.
Has something changed? Or am I just using more genuine credits than I realise for the current task? I swear I burned though $40 in about 8 hours, when previously that would have taken 2 weeks. Could be the task type, but need to check.
Also super disappointing that with the endless updates you seem to have removed all the previously added and useful spend indicators, now have to go searching for them.
ps. its just taken 8 minutes to answer a query about css padding on one element in my app.
Steps to Reproduce
try using composer 2.5
Operating System
MacOS
Version Information
Version: 3.7.42
VS Code Extension API: 1.105.1
Commit: 5702c9cfca656d8710fad58402fe37f14345e3a0
Date: 2026-06-15T19:39:42.738Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin x64 25.5.0
For AI issues: which model did you use?
composer 2.5 “fast”
Additional Information
Sorry, can’t help being grumpy when pumping money in like a slot machine and its crawling like a free model. Still love cursor overall. Just wish you’d stop messing with it ever other day.
Does this stop you from using Cursor
No - Cursor works, but with this issue
Hi Paul!
There are two separate things going on here, and the first is a quick fix.
Credit burn - you’re on the “Fast” variant. Composer 2.5 has a Fast toggle that’s on by default. It’s the same model with the same intelligence, just served at higher throughput for a higher per-token price (about 6x the standard rate). Turning it off is the biggest lever on your spend:
- In the chat model picker, hover over Composer 2.5, click the Edit button that appears, and toggle Fast off.
Fast is worth it when you’re actively watching a response come in. For most other work, standard gives you the same result for a fraction of the cost.
The rest of the “suddenly burning credits” feeling is the included-to-on-demand boundary. On individual plans, Composer usage comes out of your included pool first, and once that’s used up, extra usage bills on-demand, which is what makes spend jump. You can see exactly where you stand and set a spend cap at cursor.com/dashboard in the Usage section (that’s where the spend breakdown lives now too). More on usage and limits, and the per-variant pricing is on the Composer 2.5 page.
Slowness and freezes - separate, and not your setup. Composer 2.5 Fast had some slowness in performance and elevated errors earlier today that our team has since mitigated, which lines up with the “Taking longer than expected” stretches you ran into. Switching Fast off (above) also steers you away from that, so it helps here too. For context: “Taking longer than expected” just means the response hasn’t started streaming yet, and when it fully locks up you don’t need a full reboot — Cmd+Shift+P → Developer: Reload Window recovers in a few seconds.
hi Mohit,
yeh i saw the issue flag after I posted.
but for the record, while the speed is back on composer, no delays or crashes, its performance has gone through the floor today (after the fix), really frustrating. its definitely still not working properly. its working quickly but very poorly on basic tasks.
i’ll turn off the Fast, didn’t realize it was 6x but usage still feels crazy, i’m used to watching my usage, and I’ve only ever used it on fast. unless the rate changes from the credits included in the monthly bundle, to the credits used when you switch to on demand, it still feels like it was off.
thanks for the reply.
P.
On the rate, it doesn’t change between your included allowance and on-demand. Both are billed at the same per-token API rates. Your plan includes a monthly budget of usage at those rates, and once it’s used up, extra usage just continues at the same rates as pay-as-you-go. So nothing gets more expensive per token when you cross into on-demand. What changes is visibility: while you’re inside the included allowance it draws down a pre-paid pool quietly, and once that’s exhausted every request shows up as a charge, which is what makes spend suddenly feel like it jumped. You can see the breakdown and set a spend cap in the Usage section at cursor.com/dashboard. More on usage and limits.
The other big lever is which model you’re on. If you’ve moved some of this work onto a premium model like Claude Opus, that’s many times the per-token cost of Composer 2.5, so it’ll burn through the allowance much faster than Composer did. Worth keeping an eye on the model picker for the heavier sessions.
On quality — turning Fast off won’t lower it. Standard and Fast Composer 2.5 are the same model with the same intelligence; Fast only changes throughput and price (details). And we don’t quietly swap model versions underneath, so nothing changed there today beyond the speed issue that’s now mitigated. If a specific response was clearly poor, the most useful thing for us is a request ID from that exact generation - open the three-dot menu on the message and Copy Request ID, and post it here.
One note: if you’re in Privacy Mode we can only see limited metadata, so if you can reproduce a bad response with Share Data enabled and grab the request ID from that one, we can dig into what actually happened. How to find a request ID.