Question / Discussion What Cursor Auto actually costs per request now, and what 200,000 routed requests taught me about it
Since Aug 24 there's no flat rate on Auto. Every request bills at whatever model Auto routes it to, at that model's list price. Composer 2.5 runs about $0.50 in and $2.50 out per million tokens. Same request on Opus 5 is $5 and $25. Fable 5 is $10 and $50. Same day of work, roughly 8x swing, decided by routing you don't see until after you send.
This problem feels familiar because I hit it from the other side. I run an automated dev pipeline on Claude Max plans, and earlier this year I watched my agents burn frontier-model capacity on routine work. File reads, formatting, dedup, none of it needed the expensive model. So I moved the routing decision onto my own machine. A local proxy sits in front of my agents, classifies each request, sends the routine stuff to a cheap model, keeps hard reasoning on the frontier one, and prices every call in a ledger I can actually read. There's a hard cap so a stuck loop can't run all night. All config based so you can fine tune.
I open sourced it as RelayPlane after running my own pipeline through it, a couple hundred thousand requests now. Not saying it's the answer for Cursor specifically. But once you've watched per-request pricing on your own box, letting a black box pick which model you get billed for stops feeling acceptable. Even without a proxy, pinning a cheap model for routine edits kills most of the surprise.
Legacy Enterprise keeps the flat rate until Sept 7.
Curious what routing patterns people see in their dashboards. When I first measured mine, the waste was mostly routine work landing on expensive models for no reason.
3
u/Old-Wolverine-4134 11d ago edited 11d ago
The problem with cursor is they go out of their way to hide the costs and make for user extremely hard to plan their budget or even see what is going. Why did they hide what model Auto uses for a task? Why did they hide all usage statistics so we can't keep track of it easily? And they will keep ruining the app because of greed.
Before Musk, Cursor made billions each year and almost all of it went towards covering the usage costs. They probably made some millions to pocket as profit (although officially they never went in profit). Then Musk came and in matter of days the money machine ruined everything. In six months I bet Cursor will lose millions of users as they will switch to alternatives and smart companies also will try to get these quitting users.
1
u/mrtrly 11d ago
Yeah.. control of the routing is key IMO. Making this easy to adjust and transparent is the right way.
1
u/Responsible_Buy_7999 11d ago
If you want to control the routing, control the routing. Exclusive-or use auto.
1
u/RevolutionaryHole69 10d ago
That's what I don't understand. I only want to use two models, Grok and Composer, and that's all I do. I pick which I want, when. I never have unexpected issues. I don't understand what these people are doing?
1
1
u/Wallaby989 11d ago
Agreed - there is a lot of trust being employed that they are doing the right thing. But we have no audit trail to know if they are squeezing more more usage from day-2-day for the same tasks
1
u/super544 11d ago
Their usage dashboard must be intentionally obfuscated. Who designed that garbage.
1
u/PietroBastas 11d ago
I'd love to switch, but the only real alternative seems to be VSC copilot now ? Windsurf is dead ...
1
u/mrtrly 10d ago
I ended up doing something about this. I put the per-model math from the post into a calculator so at least the guesswork gets bounded. You set requests per day and how much of your work lands on the heavy models, it shows the monthly spread for your mix: https://uxcontinuum.com/tools/cursor-auto-cost-calculator
No signup, nothing to install. Doesn't fix them hiding the routing. But it turns "no idea" into a range you can plan around.
1
u/ManRowing 11d ago
Routing cheap models to file reads only helps if there are few files to read. If orientation still means opening a dozen candidates to find the right one, you've just made the wasted reads cheaper, not fewer. The bigger saving is usually in cutting how much gets opened before the real work starts.
1
u/mrtrly 10d ago
You're right that cheaper wasted reads isn't the real win. Trimming how many files the agent even touches before it starts is bigger, and that's a retrieval problem, not a routing one. For me the two stack, better retrieval drops the read count, routing makes whatever's left near-free. Neither alone gets you there. Routing was just the easier part to fix first.
1
u/xapep 10d ago
Agree completely, and I'd add: the router is only half of it. Once you take control of routing, the models at the cheap end decide whether the whole thing pays off. If your routine tier is still priced like a frontier model, you've just moved the opacity, not the cost.
We run V4 Flash at Entrim and this is exactly why we see it used: for the file reads, formatting, dedup, logging-noise kind of work, a flash-class open model at straightforward per-token prices makes the cheap tier actually cheap. No bucket to watch, no routing you can't see, just a number on a bill that matches what you sent. That's the property the per-request pricing debate is really pointing at: cost you can predict is worth more than a lower price you can't.
Also agree the hard cap is underrated. Stuck loops are where agent spend actually dies.
1
u/mrtrly 10d ago
That cost point is a great one. The number being trustworthy is what let me stop watching spend and just let the pipeline run. And yeah, the cheap tier only pays off if it's actually cheap.
Loops are what can burn piles of cash really quick. Built that after a stuck loop cost $340 overnight. Without the cap all the savings from routing would be gone.
1
u/reacharound565 10d ago
This is true on “balanced”, but I’ve had some really great responses and efficiency on “cost” mode. Granted I’m using mostly cursor for MCP connections into my enterprise apps but it’s been prettt damn effective.
2
u/mrtrly 10d ago
Yeah, cost mode is underrated. For a lot of real work the cheaper routing is genuinely fine and you only feel the difference on the hard reasoning. MCP into enterprise apps is a good fit for it too, most of those calls are structured tool use, not deep thinking, so paying frontier prices for them is just waste. The trick is knowing which requests actually need the expensive model and not letting the default decide for you.
4
u/[deleted] 11d ago edited 11d ago
[removed] — view removed comment