The shock is almost a rite of passage. You give Claude Code a real task on a real repo — it reads files, edits, runs the tests, fixes what broke — and when you check your usage afterwards, the number is a multiple of what the same hour in a chat window would have cost. Nothing went wrong. That number is what agentic coding costs, and this post explains why, then walks through the levers that actually reduce it — strongest first — ending with the one that bounds what a runaway session can charge to your wallet: a cap on what the key itself can charge, checked against in-flight reservations before each wallet-billed request, so an overrun is unlikely.
Where the tokens actually go
An agentic CLI is not a chat window, and four mechanics dominate the bill:
Every file it reads enters the context. When Claude Code opens an 800-line file to understand one call site, those lines become input tokens — and they stay in the conversation for every turn that follows. A thorough exploration of a mid-sized repo can pull in tens of thousands of tokens before the first edit happens.
Long sessions re-send accumulated context every turn. The underlying API is stateless: each turn, the client sends the entire conversation so far — every file read, every diff, every test log — and pays for it again as input. Cost per turn grows with session length, so the total cost of a session grows much faster than linearly. Turn 40 is quietly paying for turns 1 through 39.
Subagents multiply it. When Claude Code spawns a subagent to explore the codebase or review a change, that is a separate conversation with its own context, doing its own file reads, billed on top of the main session.
Retries and test loops add up. Run the tests, read the failure output, edit, run again — every iteration appends more output to context and pays for another full-context turn. A stubborn failing test can cost more than the feature it guards.
None of this is waste in the pejorative sense. The re-sent context is what lets the model remember what it did three edits ago; the file reads are what make its edits correct; the test loops are the difference between "wrote code" and "shipped code". This is the cost of the tool actually doing the work. The right response is not to fight the architecture — it is to control the three variables you own: which model does the work, how long the context gets, and what the key is allowed to spend.
Lever 1: model mix — the biggest single multiplier
Every one of those re-sent context tokens is billed at the active model's input rate, so the model choice multiplies everything above. Running the strongest model for everything is the most expensive possible configuration, and most sessions don't need it:
| Work | Model | Why |
|---|---|---|
| Daily driver: features, bug fixes, refactors | Claude Sonnet 5 | Handles the large majority of coding work at a fraction of the flagship rate |
| Genuinely hard problems: architecture, deep debugging | Claude Opus 5.5 or Claude Opus 5 | Worth the premium when reasoning depth is the bottleneck |
| Mechanical passes: renames, boilerplate, comment sweeps, log triage | Claude Haiku 4.5 | The work is pattern-shaped; a small, fast model does it fine |
Claude Code lets you switch mid-session with the /model command, so the practical habit is: default to Claude Sonnet 5, escalate to the Opus line (Claude Opus 5.5 or Claude Opus 5) when you hit a wall, and drop to Claude Haiku 4.5 for the mechanical passes. Because the multiplier applies to the whole re-sent context, a mixed setup routinely lands at a small fraction of the Opus-everything bill. To judge when escalating is worth it, Claude Opus 5 vs Claude Sonnet 5 renders both spec sheets and live rates side by side.
Opus-everything is also Claude Code's out-of-the-box setting now: since v2.1.280 its default model is Claude Opus 5.5, and through a gateway its background tasks run on the main model unless you pin a small one. To make the mix above your default, set ANTHROPIC_MODEL=claude-sonnet-5 and ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5, then escalate with /model when a task needs it. Claude Code on Opus 5.5 has ready-to-paste setups, including how plan holders keep Opus work on plan quota.
Claude Code speaks the Anthropic protocol, so through Router One it reaches the Claude family, and each Claude model's live rate is on the models page. The site-wide "up to 90% off official prices" figure is a ceiling reached on select models across the catalog, not a Claude-specific rate; the cheap Claude API page covers Claude access and billing. To estimate a workload before running it, the cost calculator does the arithmetic. If your sessions still default to Claude Sonnet 4.6, Claude Sonnet 5 vs Claude Sonnet 4.6 renders both spec sheets and rates from the live catalog before you switch.
Lever 2: session hygiene — shorter context is the reliable lever
Since each turn re-pays for the whole context, the length of the context is the second variable you directly control:
- One task, one session. Start fresh (
/clear) when you switch tasks. A session that fixed a bug this morning is expensive ballast for the refactor this afternoon. - Scope the ask. "Fix the null check in
src/api/auth.ts" reads one file. "Find and fix the login bug" reads twenty. - Point, don't paste. Pasting a huge file or a full log dump into the prompt puts it in context forever. Give a path and let the tool read the relevant part, or paste only the failing 30 lines.
- Let long sessions die. When a session has accumulated enough history that every turn feels heavy, summarize the state into a note and start clean. The restart costs one file re-read; continuing costs the whole history every turn.
A note on caching: you may have read that prompt caching changes this arithmetic. Whatever caching does or does not apply upstream, we won't promise cache-pricing mechanics here — the lever you can always verify in your own trace data is a shorter context. Fewer tokens sent is fewer tokens billed, under every pricing scheme.
Lever 3: the gateway backstop — a ceiling instead of hope
Hygiene is a practice; a cap is a guarantee. Running Claude Code through Router One takes two environment variables:
export ANTHROPIC_BASE_URL=https://api.router.one
export ANTHROPIC_AUTH_TOKEN=your-router-one-key
What that buys you, cost-wise, is a spend cap you set, two throttles the platform applies to every key, and a ledger:
- maxSpend — a hard cap on what the key can charge to your wallet. Create a key with maxSpend set to $10 and hand it to an overnight experiment: the worst case is now $10 of wallet charges, not "whatever it managed to burn by morning". The key's wallet-billed requests stop at the cap and your other keys keep working; requests your plan covers draw on the plan quota instead and do not count toward the cap.
- rateLimit — a requests-per-minute ceiling on the key, which turns a runaway retry loop from a fire into a trickle.
- tokenLimitTpm — a tokens-per-minute ceiling on the key, the direct brake on the failure mode this post is about: an agent stuck in a read-edit-test spiral cannot burn faster than it. Both ceilings are platform defaults, not dashboard settings; support can raise them on request.
- Per-request traces — every request is logged with model, tokens, cost, latency, and status (Dashboard → Logs). One key per project or per experiment, and the question "what burned $14 on Tuesday?" has an answer you can read, not guess.
One more line on the same ledger: if your own code calls Claude's server-side web_search or code_execution tools through /v1/messages, those turns are metered at the model's posted token rates and show up in the same traces — see Claude web search and code execution through the API.
The pattern of one capped key per experiment is the same mechanism described in per-key cost attribution, and the cost tracking page documents exactly what the ledger records.
Subscription anxiety vs. a wallet you can observe
The reason a surprise Claude Code bill stings is not the amount — it is that you couldn't see it forming. A flat monthly subscription answers that anxiety by hiding the meter; a metered API without observability answers it by making you afraid of the meter. The third option is the one this post has been building toward: a prepaid wallet, a hard cap on what each key can charge to it, and a per-request trace behind every charge. You loaded a known amount, no key can charge it past the cap you set, and the ledger shows which session, which model, and which loop the money went to. The value proposition is not a cheaper black box — it is that there is no black box.
If you do prefer predictable monthly spend, Router One also has subscription plans (launch notes) alongside the wallet — the Claude Max alternative page sets those plans against Claude Max. As of the 2026-09-24 plan response, Claude Opus 5 is in the plans' Premium models tier but no tier lists Claude Opus 5.5, so Opus 5.5 calls bill to the wallet. And if you're setting up from mainland China — where the direct-connect endpoint needs no VPN — the Claude Code China guide covers the full setup. For cost tactics beyond Claude Code, see reducing LLM API costs.
FAQ
Why does Claude Code use so many tokens? Because agentic coding is context-heavy by design: every file it reads becomes input tokens that stay in the conversation, each turn re-sends the entire accumulated context, subagents run their own separately-billed conversations, and test-fix loops pay for another full-context turn per iteration. It is the cost of the tool doing real work, not a malfunction — but it responds well to model mix, shorter sessions, and per-key caps.
What is the cheapest way to run Claude Code day to day? Route by difficulty: Claude Sonnet 5 as the daily driver, Claude Opus 5.5 or Claude Opus 5 only when reasoning depth is the bottleneck, and Claude Haiku 4.5 for mechanical passes like renames and boilerplate. Since v2.1.280 Claude Code defaults to Claude Opus 5.5, so set the Sonnet default yourself (ANTHROPIC_MODEL=claude-sonnet-5). Because the model's input rate multiplies the whole re-sent context every turn, this mix routinely costs a small fraction of running the flagship for everything. Live per-model rates are on the models page.
How do I set a hard spending limit on Claude Code? Run it through a gateway key with a cap. On Router One, create an API key with maxSpend set to your ceiling and point Claude Code at it via ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN; its wallet-billed requests stop at the cap no matter what the session does (requests your plan covers draw on the plan quota instead). The key's default rateLimit and tokenLimitTpm additionally throttle runaway loops mid-flight, and per-request traces show exactly what was spent where.
Does keeping sessions short actually reduce cost? Yes, and it is the most reliable lever after model choice. The API re-sends the full conversation every turn, so a long session pays for its own history repeatedly and total cost grows much faster than linearly. Starting a fresh session per task, scoping requests to named files, and pointing at paths instead of pasting large files all directly shrink the context being re-billed.
Is a token-per-minute limit safe to use with an agent? Yes — tokenLimitTpm acts as a brake, not a wall, and it is not something you have to configure: every key runs under a platform-default tokens-per-minute limit, which support can raise on request. A normally-paced session stays under it, while a runaway read-edit-test spiral gets slowed to that rate instead of burning freely. Combined with a maxSpend cap as the absolute backstop on wallet charges, the worst case of any wallet-billed experiment is bounded twice: in speed and in total.
The honest summary
Claude Code is expensive per hour because it does the work of the hour: reading, editing, testing, retrying. You can't make the architecture cheap, but you can control its three inputs — put Claude Sonnet 5 on daily work and escalate deliberately, keep sessions short and scoped, and run everything through a key whose maxSpend you chose in advance. Load the wallet at router.one, cap the key, and read the ledger instead of dreading the bill.