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. 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.