Why Claude Code Gets Expensive, and What Actually Reduces the Bill

The short answer

You are paying to resend the conversation, over and over

Claude Code's own documentation names the mechanic: every message is a new stateless API request, so it re-sends the full context each turn, the system prompt, project context, every prior message, every tool call and its results, plus your new message. Each tool round is another request carrying everything accumulated so far. That log you had it read at turn three is still being billed at turn thirty, unless the session cleared, compacted, or dropped it first.

Prompt caching is the discount that makes this survivable: a cache read normally costs 0.1x the base input price. The corollary is the part that surprises people, because nine documented actions invalidate that cache, and several are things developers do reflexively mid-task.

So the bill has three drivers, and they respond to different levers: how much context you carry, how often you break the cache, and which model and effort level is doing the work. The rest of this article takes them in that order, separating what Anthropic documents from what is measured elsewhere, and flagging the folklore.

The mechanic

Cache economics, and the nine things that break it

Caching is priced as a bet: writing to the cache costs more than a plain input token, reading from it costs far less. On Anthropic's published pricing table, a 5-minute cache write is 1.25x base input and a 1-hour write is 2x, while a read is 0.1x, dropping to 0.025x on Fable 5.1. In Claude Code the TTL follows a two-bucket rule: the main conversation gets 1 hour on a subscription while you are inside included plan usage, and 5 minutes once you are on usage credits, with an API key, or on a cloud provider; subagents, forks, workflows, teammates, and compaction get 5 minutes. Both buckets are configurable through promptCacheTtl and subagentPromptCacheTtl since v2.1.242.

That bet only pays off if the cached prefix survives. The documentation lists nine actions that can cause part or all of the next request to miss the cache:

• 1. Switching models.
• 2. Changing effort.
• 3. Enabling fast mode for the first time.
• 4. Connecting or disconnecting an MCP server whose tool definitions sit in the cached prefix.
• 5. Enabling or disabling a plugin whose MCP tools affect that prefix.
• 6. Denying an entire tool when tool search is unavailable or disabled.
• 7. Compacting, which must also read the existing conversation before it can summarize it.
• 8. Accumulating enough images and PDFs to force earlier content out.
• 9. Upgrading Claude Code.

Two documented exceptions are worth knowing because they change habits. Since v2.1.260, Fable 5.1 preserves the cache across effort changes on Anthropic API-key and subscription paths, though not on Amazon Bedrock, Google Cloud's Agent Platform, a Claude apps gateway, HIPAA configurations, or when experimental betas are disabled. And turning fast mode off, then back on, keeps the warmed cache. Meanwhile file edits, CLAUDE.md edits, permission-mode changes, and skills are documented as cache-preserving, with one catch worth knowing: a skill or command that names another model counts as a model switch. Spawning a subagent preserves the parent's cache, though the subagent's own first request still has to warm its own.

The practical reading: pick your model and effort at the start of a session rather than mid-task, and treat compaction as a deliberate cost, not a free cleanup.

The levers

What Anthropic actually tells you to do

The official Reduce token usage guidance is long, and the items are not equally powerful. Grouped by what they act on:

Track the result with /usage, which reports session tokens, a local list-price estimate, and cache statistics. Note two things about that number: the estimate resets after /clear, and on a subscription it is an API-style estimate rather than your invoice. Anthropic points at the Console billing page as authoritative, with Claude Code analytics available for Team and Enterprise.

The pattern

Expensive planner, cheap executor

One widely discussed cost pattern splits the work: let an expensive model plan and review, let a cheap one type. Several harnesses now ship separate planning and execution configurations as documented features.

Claude Code has the opusplan alias, which plans with Opus and executes with Sonnet, and custom subagents can pin their own model, including Haiku. Cline runs separate Plan and Act models. Gemini CLI's plan mode documents Pro-class planning with Flash execution. OpenCode makes Plan and Build separate agents, each able to name a model. Codex documents per-subagent models and a distinct plan-mode reasoning effort, though an automatic planner-versus-executor model split is not documented.

How much does it save? Anthropic publishes no controlled figure for opusplan, and the public evidence is thinner than the enthusiasm. The most cited data point is a single author's manual benchmark, and its conclusion was skeptical: an Opus 4.7 planner with a Haiku 4.5 executor in Claude Code scored 90 out of 100 at about $3.49, while solo Opus 4.7 in OpenCode scored 97 at about $4.04. Both the harness and the model mix changed between those runs, so it is a cross-configuration observation, not a clean test of splitting, and the author read it as mixing losing to a strong solo model in a mature harness. The result that favors the pattern came from the same study on a different stack: a high-effort planner with a medium-effort executor in Codex scored 94 for a few dollars, against 97 for roughly $16 solo. Read both as one manual sample, not as your numbers; how the planner's own tokens are counted moves the totals materially.

One mechanical caveat the pattern carries: switching models changes the cache key, so a planner-executor handoff crosses a fresh-cache boundary by construction. The savings have to beat that.

The folklore

Do subagents save tokens? Not by themselves

The most common cost belief worth correcting is that delegating to subagents reduces spend. Anthropic's own write-up is direct about the trade: each subagent spins up its own context, consumes tokens, and adds a layer of indirection. A subagent's first request cannot hit the parent's cache; it warms its own. Only its summary returns to the parent conversation.

That makes subagents a tool for protecting the parent's context and for routing cheap work to cheap models, not a discount in themselves. The published multiples are sobering: Anthropic documents agent teams using roughly 7x the tokens of a standard session when their teammates run in plan mode, and its multi-agent research system used about 15x the tokens of chat, with agents generally around 4x. That system, an Opus 4 lead with Sonnet 4 subagents, scored 90.2% better than single-agent Opus on an internal research evaluation, and Anthropic itself cautions that coding work usually offers fewer parallelizable subtasks than research does. The trade is the point: you are buying capability with tokens, not saving them.

Use subagents when the isolation or the model routing is worth paying for. Do not use them expecting a smaller bill.

The unit

The number that matters is cost per successful task

Token price alone does not determine what a task costs. The usable number divides total spend, including failed attempts, by successful completions, and the 2026 benchmarks that price whole configurations make the difference concrete.

EvoMap's EvoX benchmark priced 424 tasks across six public benchmarks on the same model, Opus 4.8 at xhigh effort, with uniform repricing: Claude Code solved 358 for about $7.20 per solve, Codex solved 338 for about $5.71, and EvoMap's own EvoX solved 338 for about $4.82. It omits cache adjustment because harness telemetry was asymmetric, and the publisher is one of the evaluated parties, so read the ordering rather than the decimals. The Next.js team's agent evals, priced at list and scored with pass@4, land in a similar shape. Dividing their average cost by pass rate, which is our arithmetic rather than theirs, the September 11 run gives roughly $0.74 per successful eval for Fable 5.1 with Claude Code at 97%, about $2.09 for Opus 5 with Claude Code at 94%, and about $0.065 for MiniMax M3 with OpenCode at 81%. Note which way that ordering runs: the cheapest per success is the low-cost open model, and the highest per success is the more expensive Anthropic model, not the top scorer.

A recent preprint, Harness or Model?, supplies the counterweight this article needs, and its result is genuinely unresolved rather than simply small. On a 256-task private suite, it ran two paired same-model comparisons of 80 tasks each, grading 792 of 800 planned runs. Native minus neutral success came out at negative 1.25 points for Opus 4.8 (95% confidence interval negative 10.0 to positive 7.5) and positive 1.25 for GPT-5.5 (negative 4.4 to positive 6.9): neither harness advantage was resolved, and the intervals permit materially larger effects in either direction. On cost, the neutral harness ran about 1.2x to 1.6x per solved task against native harnesses, with the Opus billing comparison missing usage records for 58 runs, leaving a plausible 0.7x to 2.3x range. A post-hoc split is the interesting part: native Opus trailed on repository tasks and led on contest tasks.

That looks like it contradicts the configuration-level numbers above, and mostly it does not. Benchmarks that compare whole configurations let the model and the harness move together, so they measure the pair; Harness or Model isolates the harness at a fixed model. Among the configuration-level benchmarks above, EvoX is the only same-model comparison at that scale, and it is vendor-run without comparable cache accounting. The honest summary: harness effects on success are task-dependent and still contested, while the harness-linked cost differences these studies report are material but under-measured, and in the Opus comparison not yet resolved.

In HarnessRouter's own recorded benchmark, eight harness and model configurations performed identical work and per-task cost varied by about 475x. That is one task, not a law, and it is exactly why the unit has to be cost per successful task on work you actually run.

Where HarnessRouter fits

Make the cheap option easy to prove

Every lever above is a decision you can only make well with numbers: which model is enough for this task class, whether the planner-executor split pays for its cache boundary, whether a cheaper harness finishes the job at all. Collecting those numbers otherwise means integrating each harness separately, one contract at a time.

HarnessRouter is the world's first unified interface for agent harnesses. It means one API contract for starting tasks, streaming progress, continuing sessions, and collecting files and results across every harness on the platform, with per-run cost recorded the same way for each. The harness and model become parameters you can measure and route on, per task class, rather than a commitment you defend.

FAQ

Frequently asked questions

Keep reading

Keep the bill honest

• Claude Code compact vs new session
• Thin model, thick harness: the measured case for harness engineering
• The same-task benchmark and public results
• Model pricing catalog