Model routing & AI coding costs

On June 1, GitHub Copilot moved to a credit-and-usage model and r/GithubCopilot stayed lit for a month — the top thread, "Pay the same, get anxiety for free," cleared a thousand upvotes, alongside "Cancel your Copilot subscription today," a report of someone burning 25% of a monthly allotment on day one, and enterprises quietly disabling Opus over the change. Cursor went through its own pricing convulsion. It isn't a cash grab so much as structural. Flat $10–20/month plans worked when "AI coding" meant autocomplete: cheap, bounded, everyone's usage looked roughly alike, and the vendor could average across users. Agents broke that math. Every run is a stack of per-token model calls, and a power user running multi-step tasks against frontier models all day can cost orders of magnitude more than a casual user — often more than they pay. Under a flat fee the light users subsidize the heavy ones, and heavy users have every incentive to run the most expensive model on everything because it feels free. Usage billing just pushes the variable cost back onto whoever generates it.

The reason it feels worse isn't the average bill, it's variance: a subscription is a forgettable line item, but a meter that ticks while you work spends part of your attention watching it instead of coding. So the goal isn't only "spend less," it's making the bill predictable again. The habits that do most of the work: match the model to the task (the single biggest lever — most edits, renames, and explanations don't need a frontier model), keep context tight because you're billed on tokens in and out, lean on local models for the routine 80%, and set a hard cap plus an alert so a surprise invoice becomes an expected number. And don't reflexively cancel — measure a month of real usage first; for many people usage billing is actually cheaper once they stop running the flagship on one-line changes.

The classic story: month one is $30, three months later it's $400, and you swear nothing changed. One fresh Cursor user burned 37% of their usage in 14 hours on two short scripts; at the heavy end, one Claude Code user reports burning 10 billion tokens in 52 days building MCP servers, automation, and full apps — always-on agent use compounds fast. The spike almost always traces to a short list of causes, none visible if you only check the invoice monthly:

• Long agent loops — a multi-step agent gets stuck retrying or expanding scope and burns 100K tokens before it stops.
• Background features you forgot — inline autocomplete keeps firing on a flagship model while you're not even in the editor.
• Tool drift — a pre-commit hook or CI step quietly starts using AI for commit messages or review and multiplies request volume.
• A teammate on your account, a trial tier silently rolling to full paid rate, or a default-model bump in a tool update.

Underneath, the failure modes are the same three: casual queries hitting flagship models ("is this regex right?" answered by your most expensive model, $0.04 × 200 times a month), no per-session ceiling so a runaway loop makes 60 tool calls and 40K reasoning tokens, and no batch awareness so 200 files get reviewed at the flagship tier when 90% needed a small model. The fix is four cheap guardrails: a daily spend cap that notifies at 80% and downgrades or stops at 100%; a per-session token ceiling (soft at ~50K, hard at ~100K) to catch loops; a visible running cost in the corner of the editor, because visible cost is self-regulating cost; and an audit log of model, prompt size, duration, and cost so a spike has something to look at. This is the same discipline that stops a runaway Lambda from producing a $40K AWS bill — every major tool ships at least some of these, and none of them are on by default.

Open the credit panel of any AI coding subscription and the burn isn't the hard refactor — it's a hundred small tasks the IDE quietly sent to the strongest model because the strongest model is the default: renaming a variable, formatting a block, generating a docstring, finishing an import, suggesting a regex. The same ask shows up across r/ClaudeAI, r/cursor, r/AICodeAssist and the Cody / Composer / Windsurf forums: can the IDE route — try the cheap tier first, escalate only when it's justified?

A typical session splits three ways. Mechanical work (rename, format, autocomplete, simple scaffolding) is ~60–70% of tool calls, and a 7–13B-class model handles it correctly >95% of the time. Local reasoning (single-file refactor, a docstring that reflects the real logic, a small fixture) is ~20–30%, and a mid-tier model handles it >90%. Cross-file or design reasoning ("refactor this pattern across the repo," "why is this test flaking," "is this migration safe") is only ~5–10% and is genuine frontier territory. Default-strongest charges 10× for the 60% that never needed it.

The durable pattern is cheap-first, verify, escalate: run the cheap tier, check cheaply (does it compile, does the patch apply, do the changed tests still pass), ship if it passes, escalate only on failure — and cache the "this file is hard" decision for ~15 minutes so you don't re-pay the cheap attempt on every request. It also means not wasting tokens on whole-file context dumps and full-history resends. You don't need infrastructure to start: users who simply keep two profiles — "cheap" for autocomplete/edits, "hard" for chat/refactor — and switch by hand still report 60%+ credit savings with no quality drop they can feel. Gateways like 9Router, LiteLLM, or OpenRouter can automate the routing if your IDE speaks an OpenAI-compatible endpoint.

Model switching helps, but it doesn't replace cost visibility. A cheaper model repeating the wrong tool calls is still expensive; a stronger model working from stale context still wastes time and money. The recurring pattern in fresh Claude/Cursor threads is developers hitting weekly Claude Code caps, watching token use spike, and hopping between Claude Code and Cursor whenever cost or latency changes — which resets the clock without fixing the leak.

What's actually missing is a live answer to "where are the tokens, time, and retries going?" You can't tell whether the model, the prompt, or the workflow is the bottleneck until you can see it. One token-reduction project traced the waste to whole-file context dumps, full-history resends, and oversized model routing — none of which a model swap addresses. Cost and speed need to be first-class signals sitting next to the work: which model acted, which commands ran, how much budget the run consumed, whether tests actually proved anything. Without that, the developer becomes the monitoring system, reconstructing after the fact what the agent probably did.

A visible running total — "this session: $0.07 · 4,200 tokens · medium model" — is self-regulating: most developers instinctively scope the next prompt smaller when they can watch the number climb. The point isn't to sit and stare at a meter; it's that swapping engines to escape a bill you can't see just moves the same blind spot to a new provider. Cost visibility is a workflow problem, not a prompt-engineering trick.

The tier debate — Claude Max vs Codex vs another plan — misses the containment problem. You need to know what a specific run is allowed to spend before it starts, not after the invoice. An agent that reviews a repo, spawns sub-agents, reruns tests, calls tools, and wanders into unrelated files turns one task into an open-ended cost center, and dashboards don't help because they describe spend that already happened.

The expensive sessions look ordinary until they aren't: a step retried several times with slightly different prompts, an automatic escalation from a cheap model to an expensive one because the tool "thinks" the task is complex, a verification step that runs the full suite plus lints plus unrelated failures (often more expensive than the implementation itself), and the user simply stepping away while it keeps going. Budget isn't only dollars; it's tokens, wall time, concurrency, and tool calls.

The controls that actually contain it:

• A per-run envelope — e.g. this run may spend up to $0.75 / 60K tokens / 20 tool actions — checked between tool calls, not at the end.
• An explicit approval step before any model escalation ("switch to a higher-cost model and raise the cap from $0.75 to $2.50?").
• An idle-user stop that pauses after ~10 minutes without input and does not auto-resume when the window regains focus.
• A separate, smaller verification budget so testing can't quietly double the run's cost.

A warning at 80% is not a cap — a cap means the run cannot exceed the number without a fresh approval. And the metric worth tracking isn't average spend, it's how often a run breaches its own envelope; that tells you whether your defaults, your planner, or your escalation logic is the thing leaking.

Once an agent works while you're away from the screen, a sleeping monitor shouldn't be the only sign that work is still happening — and burning millions of tokens on a small fix is exactly the failure people report. Long, unattended runs change the requirement from "good answer" to "is this run still healthy?" You need a live read on the active task, the current model, recent commands, token use, files touched, and verification status, so you can step away without losing control.

Token burn is itself feedback: a run that keeps consuming context without converging should be paused, summarized, or handed to a different model before it damages the task. Real setups make this concrete — one builder keeps a dedicated Claude Code/Fable machine alive and remote-controls it so sessions survive travel, device changes, and geography; another spends about ten hours a day on a Supabase app and feels most of that time goes into fixing the AI's mistakes rather than the AI saving time. Routing across a long run also needs role clarity: one model plans, another implements, another summarizes, and the workflow should preserve those handoffs as evidence instead of making the next session reconstruct them from memory.

The durable point: monitoring isn't a luxury feature bolted onto autonomy — it's the price of delegation. The more an agent does unattended, the more its runtime has to be visible, because the important failures happen between prompts: which command ran, which model acted, which file changed, and whether a human ever approved the risky step.

A recurring warning in fresh threads: don't make a single AI vendor the core of your workflow. One developer lost Claude access for a month with no explanation and only bot support, which broke their entire learning-and-coding routine. Another reports their Cursor account being accessed from a new machine while they slept — burning Opus/Fable usage, accepting contracts, changing limits, and generating fresh bills. A third saw unexplained usage and billing spikes after shifting most work to Codex.

The through-line isn't model taste, it's operational risk: provider access can vanish, sessions can be hijacked, and billing can move without your say-so. None of that is solved by loyalty to one provider — it's solved by a layer above the provider that keeps working when the engine changes. Practically that means a few things: the ability to fall back to another agent or account when one is banned, rate-limited, or compromised; session and device awareness so unfamiliar usage is noticeable early instead of at month-end; and spend visibility so a hijack or a silent limit change shows up as an anomaly rather than a shock on the invoice.

Treating the coding agent as one swappable part of a controlled workspace — rather than the whole workflow — is what lets you change engines without rewriting how you work. The apps and models will keep changing; the stable asset is the operating layer around them that remembers the project rules, records what happened, and doesn't depend on any single vendor staying available.

Developers running high-end models across many projects hit a workflow problem, not just a pricing one. One user juggles seven projects, uses the strongest model as planner/orchestrator, and burns through Max 20x / Fable limits; another rearranges a weekend around Fable credits to ship SaaS features while access is cheap; a third argues the frontier model is better spent on comprehensive code-and-security analysis than on routine generation. The shared need is quota-aware model choice: decide which task deserves expensive reasoning and which can drop to a smaller or local model, and keep proof that the expensive run was actually used on the right task.

There's real waste hiding in the details. One Claude Code power user parsed two weeks of local transcripts and found nested subagents overpaying around 14% because prompt-cache writes are billed differently than reads. Another routes easy work to free/local models through an eval harness specifically so premium-model tokens are saved for judgment calls. And people on cheaper plans want evidence before upgrading: does Max/Opus actually reduce the "80% of my time is debugging AI mistakes" tax, or am I just paying more for the same rework?

Answering any of these requires per-agent, per-project usage you can see and compare, plus a record of which model did what. Otherwise "orchestration" is just the flagship model applied to everything, quietly, at 10× the necessary cost — and you find out at the end of the billing window instead of while you can still change the routing.

This is the discovery tax, and it's easy to miss because it doesn't look like "real" work. One Claude Code user reports the very first prompt eating roughly 20% of a five-hour usage window before the model does anything useful. A retrieval layer got built (intellinker's focused-retrieval MCP) specifically because a single lookup via WebFetch can dump 5,000–50,000 tokens and spawn several agents for what should be a trivial fetch. And Cursor users keep asking the same thing from the other side — how do I reduce the time the agent spends searching files, opening them, and following imports before the first edit? A recent launch (Tempest) even frames token-efficient repository understanding as a control problem, not a model problem, positioning a local code-graph against Conductor-style workflows.

The pattern underneath: the expensive part isn't the edit, it's context assembly. Every fresh session re-greps the tree, re-reads the same files, and re-derives structure the model already "knew" yesterday — and on a metered plan you pay that tax every session. Four things cut it: scope the task instead of pointing the agent at the whole repo ("fix the auth handler in X" beats "here's the codebase"); prefer targeted retrieval over dumping whole files or pages into context; reuse an index or code-graph so structure is looked up, not rediscovered; and watch what the opening context actually costs so you know when it's the problem.

This is a different worry from "how do I spend less" — it's "can I trust what the tool tells me it's doing." A concrete example from the threads: one developer upgraded to Fable's Max 5x plan, then measured actual usage in a Claude Code dashboard and found the real allowance looked closer to 2–2.5x while costing far more than the tier below. The gap between the advertised multiplier and the observed one is exactly the kind of thing you can't audit from a marketing page.

The broader signal is developers moving past "which model is best" to wanting proof: that the model they selected stayed selected through a run, that the quota math is auditable rather than taken on faith, and that system prompts or runtime settings didn't quietly change under them mid-session. The vendor's own meter is the wrong source of truth for this — it's the surface being questioned. The ground truth lives in two places you control: your local session files (which model each call actually used, and how many tokens it burned) and the provider's usage API (real reset windows and remaining allowance). To audit a plan, compare the advertised multiplier against measured token consumption over a normal week, confirm each task ran on the model you assigned it, and track reset timers so a stall is a decision you made, not a surprise.

People reach for local models for the obvious reason: no per-token cloud billing turns a variable meter into a fixed hardware cost. But the threads show two things reliably biting. First, the harness. One developer wanting a strictly local coding assistant got blocked not by the model but by unexplained Docker, API-key, and setup assumptions baked into the tooling — the savings evaporate into plumbing you have to reverse-engineer. Second, capability. Another developer tried to replace Claude Code with a local Qwen/Cline stack driven by detailed Fable-written plans, and the harness still shipped broken code and bad terminal commands. Smaller local models have tighter context windows and weaker tool-use, so a plan a frontier model executes cleanly degrades into malformed edits and shell mistakes locally.

The budget framing shows up too — developers weighing Cursor Ultra against Codex spend as a monthly line-item decision — which is the tell that this is really a routing question, not a local-vs-cloud religious war. The pragmatic answer most people land on is hybrid: keep a strong cloud model for planning and the genuinely hard work, and route routine execution to a cheaper or local model, without maintaining a separate bespoke harness for every tool. The friction to eliminate isn't the model choice — it's the per-tool setup that makes switching expensive.

Paying for several coding tools at once isn't indulgence — it's a rational response to how the plans actually behave. Each subscription is strong at something and rate-limited somewhere: one is the cheap workhorse for fast edits until its window dies mid-afternoon, another is where you do planning, a third is your quality tier for the genuinely hard problem, a fourth is the fallback for when one of the others is throttled or down. Dividing work across them by role is a real strategy. The pain isn't the strategy; it's operating it.

Two costs pile up. The first is switching friction: four tools means four terminals, four sets of keybindings, four session states, and a constant tax of remembering which window is doing what and re-establishing context every time you hop. The second is blindness — with spend spread across four accounts, you have no single view of how much of each plan you've burned, so you find a limit by slamming into it, usually right when you're in flow.

The way out isn't consolidating down to one tool; that just throws away the strength you're paying for. It's putting a control layer over all of them: a single surface where each agent runs in its own labeled space, switching between them is a keystroke instead of a context-rebuild, and total usage across every account is visible in one place. Then you route the expensive tier to the hard problems and let the cheap plan carry the routine work — on purpose, before you hit the wall, not after.

This is a real thing people find when they actually open the transcript instead of the invoice: one Claude/Fable user audited theirs and reckoned cache rewrites were eating roughly a third of the spend, while nothing about the work felt like it should cost that. It looks like a billing glitch. It isn't — it's how agent harnesses talk to models.

Every turn, the harness re-sends the running context — system prompt, rules files, tool definitions, the conversation so far — because the model itself is stateless. Providers make that bearable by caching the stable prefix, so a repeated prefix is billed at a much cheaper cache-read rate than fresh tokens. The catch is two-fold. You still pay that cache-read rate every single turn, so a long session re-reads its whole context hundreds of times, and it adds up quietly. And the cache only holds while the prefix is byte-for-byte identical — the moment something near the front changes (a new system prompt, reordered context, an edited earlier message, a tool list that shifts), the cache breaks and the whole prefix is re-written at full price. Long sessions with churning context therefore spend a surprising share of the meter just re-reading and re-writing themselves.

The levers are mostly discipline, not a setting. Keep the stable stuff stable — don't reshuffle or edit early context mid-session, because that's what invalidates the cache. Start a fresh session instead of dragging a bloated one for hours. And, most importantly, look at the cache-read line specifically rather than one lump total, because until it's broken out, the third of your bill that's context overhead is invisible and there's nothing to react to.

Feature checklists and advertised limits are the worst possible basis for this decision, because neither predicts how much work you'll actually finish. "Unlimited" comes with a rate limiter you'll discover mid-task. A generous token allowance evaporates if the tool burns half of it re-reading your repo before every edit. A cheaper model that needs three attempts to get a change right is more expensive than the pricey one that lands it first try. The spec sheet can't see any of that — only your own workload can.

So measure throughput, not entitlements. Take a batch of tasks that look like your real work — not toy prompts — and run them on each plan while watching what actually happens: how many tokens a typical task consumes, how often you hit a wall or a slowdown, how many re-runs it takes to get an acceptable result, and how much of the spend went to genuine work versus context reloading. The plan that wins is the one where usable output per dollar (or per quota unit) is highest for your task mix, which is why generic benchmarks and other people's verdicts only get you so far.

The payoff of instrumenting it once is that the answer stops being a vibe. You may well find the honest conclusion is "different plans for different work" — a cheaper tier for routine edits, a frontier plan reserved for the hard problems — and now you can route deliberately instead of paying for one maximal subscription to cover everything.

This is the failure mode nobody warns you about: on a subscription, hitting the limit stops you. On metered billing, hitting the limit just starts charging you. A promotional credit, a trial of a new model, or a "continue with usage-based pricing" toggle can move you from the first world to the second, and the change applies to ordinary work you were already doing — not just the thing you opted into.

The reason it hurts is that agentic coding is a background activity. A rate limit is a safety feature when you leave a long run going: it fails closed. A meter fails open, and you find out at the invoice. The same shape shows up in the "I spent $45 on an AI builder that kept claiming it was done" stories — you're not only paying for output, you're paying for the failed loops that produced nothing.

What actually protects you:

• Treat the plan/meter transition as a deploy. It should be an explicit, dated decision you made at a keyboard — never a side effect of accepting credits. Re-read the confirmation copy; if it says "usage beyond your plan", that is a meter.
• Set the provider-side cap first. Most consoles have a hard monthly spend limit separate from soft alerts. Soft alerts email you after the fact; a hard cap stops the charge.
• Watch the two numbers separately. Plan quota consumed and paid overage are different signals. If your dashboard blends them into one "usage" bar, you cannot tell whether you are near a stop or near a bill.
• Cap the unattended runs, not the interactive ones. The interactive session has you in it. The scheduled or background one is where a meter compounds unobserved.

Compaction is not free, and it is the single most expensive operation people forget to count. To compact, the model has to read the whole conversation it is about to summarise. A long session that has accumulated file reads, tool output, and diffs can be hundreds of thousands of tokens; summarising it is one enormous request that lands in your window all at once. On a session that has been sitting idle, you also lose any cache warmth — so what would have been cheap cache reads are billed as fresh input.

The deeper problem is that this is invisible. There is no line item that says "compaction of session X cost Y". You see a full bar and a blocked afternoon.

A practical response:

• Don't compact a stale session — start a fresh one. Write the two paragraphs of state you actually need into a file, open a new session, and read the file. That costs a few thousand tokens instead of re-reading the whole history.
• Compact early and often, or not at all. Small, frequent compactions of a short context are cheap. One giant compaction at the end of a marathon is the expensive path.
• Keep a local record of what ran. Model, operation, rough context size, timestamp. When a window vanishes, the question "was this legitimate spend or a billing bug?" is answerable only if something on your machine logged it.
• Distrust a single reading. Providers occasionally mis-report; a local ledger is what lets you tell the difference between your usage and their accounting.

Recursion is the sharpest edge in agent tooling because the multiplier is invisible at the call site. A review skill that invokes a review subagent looks perfectly reasonable in isolation. What you cannot see from the prompt is that the subagent inherits the same skill, so it invokes another one, and each layer fans out. Five levels deep at a modest branching factor is hundreds of sessions, each with its own context load. Nothing errored — the design just multiplied.

Guardrails that hold:

• Cap depth explicitly. A subagent should know its own depth and refuse to spawn below a limit. If the harness won't do it, make the skill itself check for a depth marker and stop.
• Cap concurrent agents per run. Depth times breadth is the real number. Bounding one without the other still lets a run explode sideways.
• Make the call tree visible while it runs, not after. Counting 166 session files afterwards is an autopsy. What you want is to see the second layer appear and kill it.
• Don't let a skill invoke itself by name. Reviewer skills that can trigger reviewer skills are the classic loop. Split them: the thing that reviews should not be in the set of things a reviewer may call.
• Put a spend tripwire on unattended runs. A hard stop at a token or dollar threshold turns "I lost my week" into "it stopped after a few dollars".

A small budget doesn't fail because the model is weak. It fails because unfamiliar work invites the most expensive pattern there is: a long, exploratory session where the agent re-reads the repo, you ask vague questions, and nothing gets verified until the money is gone.

What makes a small budget productive is treating tokens like a scarce input to be spent on decisions, not on discovery.

• Separate discovery from implementation. Explore the codebase yourself, or with the cheapest model you have — file listings, greps, reading. Save the expensive model for the change you actually intend to make.
• Scope one verifiable task at a time. "Add the field to the form and make the existing test pass" is a task with a stopping condition. "Help me understand this project" is a subscription to an open-ended bill.
• Write the context down once and reuse it. The five paragraphs that explain the project's shape should live in a file you paste into every new session, not be rediscovered per session at full price.
• Cap the retry loop. If the agent has failed the same test twice, stop. The third attempt is almost always more expensive and no more correct than reading the error yourself.
• Prefer short sessions. Long context is quadratically expensive in practice: everything you have said gets re-read on every turn. Two focused twenty-minute sessions cost far less than one two-hour ramble and usually work better.

On $30, expect to be the one who decides what to do; use the model for the typing and the mechanical parts.

Almost every comparison you'll find answers the wrong question. They rank models, or list features, when what you're asking is marginal: given what I already have, what does the next $20 add?

Model branding is the least useful axis, because the frontier models are broadly available across the tools and change every few months. What differs, and what persists, is the harness: how the tool builds context, what it can execute, how it shows you a diff, and what it does when you disagree with it.

A useful way to score the marginal purchase:

• Concurrency. Can you run several projects or agents at once, or does the second project mean waiting? If you routinely have two things going, this is usually where the real value is.
• Execution surface. Does it run terminals, hit your database, drive a browser, deploy? A tool that only edits files hands the rest of the loop back to you.
• Review controls. Diff review, scoped edits, approval gates. Generation is commoditised; the ability to reject cheaply is not.
• Quota shape. Not the advertised limit — the throughput you get on your actual work. A plan that stops you on Thursday is a four-day plan.
• Portability. If your context, rules, and history are locked in the tool's cloud, the second subscription raises your switching cost as well as your bill.

If the honest answer on all five is "about the same as what I have", you're buying a second UI for the same capability.

Because you're paying the context tax twice. When work moves from one model or tool to another, the new one arrives blank: it re-reads the files, re-derives the architecture, re-establishes what has already been tried. On a large repo that re-read can be tens of thousands of tokens before a single useful line is produced — and you pay it on every handoff, at both ends.

Cheap-model delegation only wins when the delegated unit is self-contained. "Write this function to this signature, here is the test" travels well. "Continue what the other model was doing" does not travel at all.

The rules that make routing actually cheaper:

• Route by task shape, not by price. Mechanical, well-specified, verifiable work goes cheap. Ambiguous work where being wrong is expensive stays on the strong model.
• Make the handoff artefact small and explicit. A short brief — goal, constraints, the two files that matter, the acceptance check — beats dumping the transcript. If the brief is hard to write, the task isn't ready to delegate.
• Count the round trip. A delegation that saves $0.40 of generation and costs $1.20 of re-reading is a loss you can't see without measuring.
• Keep one durable project context outside the models. The re-read is only expensive because the knowledge lives in a conversation. Move it into a file and the handoff gets cheap.
• Don't split a debugging session. Debugging is the least portable work there is; the value is in the accumulated failed hypotheses.

Domain classifiers run on the text of your request, not on your intent, and they're tuned for a general population. If your subject matter overlaps a sensitive category — biology, chemistry, security, medicine, law enforcement — benign work trips them. The result usually isn't a refusal you can argue with; it's a silent capability change, which is worse, because the code quality drops and you don't know why.

You cannot argue your way past this, and you shouldn't try to phrase around a safeguard. What you can do is stop mixing two different kinds of work in one conversation:

• Separate domain reasoning from implementation. The part that says "this key distinguishes species by leaf margin" is subject-matter work. The part that says "render a decision tree from this JSON offline" is ordinary app code with no sensitive vocabulary in it. Do them in different sessions.
• Put the domain content in data, not in prompts. If the species names live in a JSON file the app reads, your coding session never has to contain them.
• Notice the downgrade. Check which model actually answered rather than which one you selected. A quiet fallback is the thing that wastes an afternoon.
• Keep a fallback that works. When one provider classifies your domain badly, another often doesn't. The point isn't to shop for permissiveness — it's that ordinary offline-app work shouldn't be blocked by vocabulary.

Feature-list comparisons and advertised limits don't predict what a tool costs you, because cost lands per workflow, not per spec sheet. The only number that matters is accepted changes per euro on your work — and it's hard to see because the expensive parts (retries, re-reads, reviewer corrections, wall-clock waiting) don't appear on the invoice as line items.

To compare tools honestly you have to measure the whole run, not the token bill:

• Accepted changes, not attempts. A tool that makes ten edits you keep beats one that makes thirty you revert, even at a higher token price.
• Retries and wall time. A €50 half-hour on one task is a data point; capture it alongside the same task on the other tool. Latency is a cost even when tokens are cheap.
• Reviewer corrections. Count how much you had to fix afterward. A cheap model that needs heavy correction isn't cheap.
• Which model actually ran. Routing matters — the flagship on trivial work is the quiet money leak, and "I picked cheap" doesn't guarantee cheap ran.

Do this for a week across the tools you're deciding between and the answer stops being a vibe. Usually it isn't "tool A beats tool B" — it's "route the easy 80% to the cheap path and keep the flagship for the 20% that needs it," which no benchmark will tell you.

The confusion is by design, not your fault: AI IDEs stack several different limits behind one word — "usage" — and they refill on different clocks. When the agent stops, you're left guessing which ceiling you hit, because the tool rarely tells you which one it was.

There are usually four distinct things, and it's worth separating them in your head:

• Action / request quota — how many agent actions or premium requests you get, often per month, sometimes per day. This is what "free agent limit" usually means.
• Context window — how much the model holds in one session. Hitting this degrades or stops a single conversation; it has nothing to do with your monthly quota.
• Token / usage budget — the metered spend, which can flip to pay-as-you-go the moment a promo or plan tier changes.
• Billing window — daily, monthly, or rolling, and different for each of the above.

The practical defense is visibility before you're mid-change: know which limit is closest to empty and what resets when. When the action quota is nearly gone, hand the current task to a cheaper local or terminal agent rather than starting something the session can't finish. A stopped agent mid-diff is almost always a limit you couldn't see coming, not one you couldn't avoid.

Launch benchmarks measure bounded, self-contained tasks. Your codebase is neither, and the failures that actually cost you time — losing the thread on turn forty, missing a cross-service contract, confidently editing the wrong module — are invisible to a benchmark by construction.

Run your own comparison. It takes an afternoon and it's the only evidence that transfers:

• Pick three tasks from your own history. A contained bug fix, a change spanning services or packages, and a longer refactor with a test suite. Use work you've already done, so you know what "correct" looks like.
• Hold everything else constant. Same harness, same instruction files, same starting branch, same prompt word for word. Change the model and the tooling together and you've learned nothing.
• Score what actually hurts. Did it pass the existing tests without weakening them. How many turns to a correct diff. How much of the repo it read to get there. Whether it stayed in scope. And the long-run question: at turn thirty, is it still working from the plan, or has it started re-deciding things you settled at turn five?
• Watch the interruptions, not just the output. Cost per accepted change, and how often a run stalls on a limit or gets downgraded mid-task, decide whether a model is usable at your scale — and neither appears on a leaderboard.
• Run each task more than once. These systems are stochastic. One run tells you almost nothing, and one spectacular run tells you less.

Expect a split verdict and let it be one. Most teams land on routing rather than replacing: the stronger model for multi-file reasoning where drift is expensive, the faster one for mechanical work where it isn't.

Most routing advice stops at cost: cheap model for easy work, strong model for hard work. That's half the decision. The other half is autonomy — how much the agent may do before a human looks — and it's the half that produces incidents rather than invoices.

Bind both to task risk, and write it down where the repo can see it:

• Define tiers by blast radius, not difficulty. Reading and summarizing. Editing tests. Editing application code. Touching migrations, infrastructure, auth, or anything with production reach. Difficulty tells you which model; blast radius tells you how much rope.
• Give each tier a model and an autonomy level. Auto-run, propose-then-run, or require explicit approval. A cheap model on a read-only task can run unattended; anything touching a migration needs a human regardless of which model is driving.
• Check the policy into the repository. A routing rule in someone's head doesn't survive a new teammate or an agent that never read it. In the repo it's versioned and diffable — you can see when the rules loosened, and who loosened them.
• Assign the tier at task start. The common failure is a task that begins as "look at this bug" and quietly becomes a schema change. Declare the tier up front and escalation becomes a visible event rather than a discovery.
• Instrument it. Cost per tier and approval rate per tier tell you whether the policy is real or routinely clicked through. A gate everyone dismisses is not a gate.

The result is boring on purpose: the expensive model shows up where mistakes are expensive, the human shows up where mistakes are irreversible, and neither depends on who happens to be at the keyboard.

You can't tell from feel, and that's the actual problem. Perceived quality moves with your own workload — harder tasks, a bigger codebase, longer sessions, more compaction — and with things on the provider's side you can't see: a system-prompt revision, a routing change, a different serving tier under load, a safety classifier catching on your domain vocabulary. Some of those are genuine degradation, some are you, and one bad afternoon is evidence of neither.

The fix is unglamorous: keep a small fixed evaluation suite and run it on a schedule.

• Ten to twenty real tasks from your own codebase, frozen. Not benchmark problems — the actual shapes of work you do, with known-good outcomes. Public benchmarks tell you nothing about your repo.
• Score completion, not just correctness. Did it finish the whole task, or stop at 80% and declare done? Unfinished work is the most common form of drift and the easiest to miss when you're reviewing a diff that looks fine as far as it goes.
• Score instruction-following separately. Plant explicit constraints — an output format, a file it must not touch, a required step — and count violations. This degrades independently of code quality, and it's usually what people are actually noticing.
• Track turns-to-done, latency, and cost per accepted change. A model that reaches the same answer in three times the back-and-forth got worse in the way that costs you money, even if every individual response looks reasonable.
• Keep a regression set. Tasks that used to pass are the signal. A new failure on a previously-passing task is what distinguishes drift from the work simply being harder this month.

Run it weekly, and again on any day the model feels off — that's what converts a suspicion into a datapoint. Keep the results, because one run is noise and a trend line is evidence.

Then the operational half, which most people skip: decide the fallback in advance. Know which model you'd switch to, at what threshold, and how you'd route around a bad window without re-planning your whole workflow mid-incident. A pinned model with no fallback is a single point of failure you've chosen not to think about.

The thing that decides whether a plan works for you isn't the model, it's the quota topology: how many pools exist, what draws from each, and what still functions when one is empty. Vendors describe plans in terms of models and headline limits. The failure you'll actually hit is "the cheap thing I needed is gone because the expensive thing consumed it."

Four questions to answer about any plan:

One pool or several? A single allowance shared across chat, IDE, terminal agent, and computer-use means every agent run is competing with your ability to ask a simple question later that day. Separate pools mean an exhausted agent doesn't take everything else down with it. At the same price, this is the most consequential difference between two plans.

What shape are the windows? A rolling few-hour window and a weekly ceiling behave nothing alike. The short window punishes bursts and then forgives them; the weekly ceiling is where people get genuinely stuck in the middle of a project. Both can apply at once, and it's the weekly one that ruins a week.

What's the consumption rate per mode, on your work? Terminal agents and computer-use consume at a rate not comparable to chat: long contexts, tool results replayed every turn, screenshots that stay in the transcript. A plan that feels generous for chat can be a few hours of agent work — and "a few hours" is the unit you should be estimating in.

What degrades, and what stops? The property worth paying for is graceful degradation: something lightweight stays available after the heavy pool is spent. If nothing does, a second account or a second provider isn't redundancy, it's a working requirement, and it belongs in the budget.

Don't buy on a forum answer about limits. They change, and they're described from a usage pattern that isn't yours. Buy the cheapest tier for a month, instrument it, and read your own numbers — noting that a provider's dashboard tells you what it believes you spent, while a local record tells you what you actually ran. When a window vanishes, only the second one lets you attribute it to a specific run.

The split is sound. Planning and implementing are different jobs, and the strong model earns its price on planning because a spec error propagates through everything downstream while an implementation error usually gets caught. But "can the cheap model implement this?" isn't a property of the model. It's a property of the pair: this spec, that model, your codebase's conventions. So measure the pair, on five representative tasks.

What to measure, in priority order:

• Spec adherence. Of the acceptance criteria you wrote, how many pass with no human intervention? This is the primary number, and it requires the spec to be acceptance-testable in the first place — which is the real work, and the thing that makes the comparison possible at all. If you can't score adherence mechanically, your spec was prose and no routing decision is available to you yet.
• Correction rounds. How many turns of "no, do X" before it lands. A cheap model at four corrections costs more than an expensive one at zero, in tokens and in your attention, and attention is the scarce resource.
• Escaped defects. What got through your gates and broke later. Weight this heavily — it's the cost that shows up as somebody else's afternoon.
• Wall time. On hour-plus features this often decides it outright. A cheaper model that takes three times as long doesn't save anything if the run occupies a window you needed for something else.
• Cost, last. It's the number everyone starts with and it means nothing without the four above.

The rule that usually falls out isn't "cheap model implements everything." It's a boundary: mechanical, well-specified, well-covered work — a new endpoint following an existing pattern, a migration, tests for defined behaviour — routes cheap. Anything requiring inference about intent, changes that cross module boundaries, or work in code with no test coverage routes to the strong model. Write that boundary into the repo so the decision isn't re-made by whoever happens to be at the keyboard.

And hold the gates fixed. The cheaper implementer only wins if its branch passes the same review and the same tests. If swapping the model also quietly swaps the standard, you haven't measured anything.

The entry above explains why context re-reads dominate the bill. This one names the actions, because once you can see the list, most of the spend is avoidable by habit rather than by settings.

The cached prefix survives only while the front of the context stays byte-identical. Anything that changes or invalidates it makes the next turn rewrite the whole prefix at full price — and on a large session, the prefix is the bill. Roughly in order of damage per occurrence:

• Switching models mid-session. Caches are per-model. Switching doesn't move the cache, it starts a new one, so your entire accumulated context gets written again. If you're going to switch, switch at a point where you'd have opened a fresh session anyway.
• Pasting screenshots into a long session. Images are large, they stay in the context permanently, and every subsequent turn carries them. One screenshot early in a short session is cheap. One dropped into a session that's already several hundred thousand tokens deep is expensive on that turn and on every turn after it.
• Editing or deleting an earlier message. The classic invalidation — everything from that point forward stops being the cached prefix.
• Large tool results left in the transcript. A raw test log, a full file dump, a directory listing: each becomes permanent context re-read on every later turn. This is the slow leak, because no single action feels expensive, and by hour three most of your prefix is tool output nobody will ever read again.
• Reviving a subagent or a session that's gone cold. Cache warmth expires. The first turn back pays full price for the entire history.
• Compacting late. Compaction reads everything before it summarises, so doing it at the end of a marathon is the single most expensive request in the session.

The practical rules: prefer several short sessions to one long one; ask for the verdict from a tool run rather than the raw dump when that's all you need; keep image-heavy work in short focused sessions; and treat "start a fresh session from a written brief" as the cheap operation it is rather than a loss of continuity. The measurement that makes all of this concrete is per-turn context share — once you can watch the prefix grow, these stop being abstract principles and start being obvious choices.

Two different failures that feel identical from outside, which is the real complaint: the meter sits downstream of everything you can see.

The first is arithmetic that doesn't reconcile because the wrong inputs are being counted. Your prompt and rules file might total 50k tokens — but that's the first turn. An agentic run re-sends the accumulated context at every step: each file read, each tool result, each retry. A session with thirty tool calls can therefore bill many multiples of the context you believe you supplied, before a single output token exists. Add extended thinking, which is billed and invisible, and cache writes, which cost more than cache reads, and a "small" prompt is not small.

The second is different in kind. Usage climbing with nothing running is an attribution failure, and no amount of prompt discipline touches it. What's missing is a ledger — which process, which project, which model, which account session — because "my usage went up" and "my usage went up because of this run" are completely different claims when you're disputing a charge with a vendor.

What to insist on, in rough order of value:

• Live attribution while a run is going, broken out by context, tool calls, cache reads and writes, thinking, and output — so you can see which of those is eating the budget rather than inferring it afterwards.
• A hard per-run budget that stops rather than warns.
• Preflight estimation — a rough cost for the run before it starts, from repo size and planned steps.
• Spending limits set deliberately low. A ceiling nobody chose is the kind of default that only becomes visible after it has mattered.

Treat this as capacity planning rather than tool shopping and the question gets much easier. You're not looking for a better agent; you're looking for the work to continue when one account caps out. Those have different answers, and the second is mostly about what stays put when you switch.

What makes a fallback genuinely usable:

• Context that lives outside the agent. Repo state, task state, decisions, and what has already been tried should sit in the project rather than in the session you just lost access to. If switching providers means re-explaining the project, you don't have a fallback — you have a second first day.
• Routing by difficulty, not by preference. Most of what burns a premium quota is cheap work: renames, boilerplate, test scaffolding, reading files. Sending that to a smaller or cheaper model isn't a compromise, it's what keeps the expensive quota available for work that needs it. Done properly this often removes the cap problem you're planning around.
• Visible headroom before you commit to a long task. The failure that actually hurts is capping mid-task. Knowing you have twelve percent left changes what you start, which is a cheaper intervention than any amount of recovery tooling.
• Bring-your-own-key as overflow capacity. Pairing a subscription with API access on the side is a sound answer to your fallback question — it converts a hard stop into a cost decision, which is a much better position to be in at the moment you're blocked.

On the tool comparison itself: day-to-day stability is mostly a property of your setup rather than of the vendor. The developers who describe a stable experience are usually the ones who stopped depending on any single account for continuity.