Token economics: where the money leaks in production

The sequence is almost always the same. The bill triples. The team cuts the prompt in half. The bill does not move.

That repeats because almost everyone looks for the money in the wrong place. The prompt is the visible part of the spend, so it gets cut first. And it is almost always the part with the smallest return.

The money leaks in three places the dashboard never shows: in the system design, in choices nobody recorded as choices, and in a belief about what the spend buys.

This post closes the arithmetic on each one. With the official multipliers, the formula in the open, and numbers you can check yourself. It is the economic close of the cluster on harness engineering: every technique from the earlier posts gets a dollar value here.

In the input, not the output. And in the resent context, not the prompt.

An April 2026 study measured that with rigor. How Do AI Agents Spend Your Money?, by Longju Bai, Zhemin Huang, Xingyao Wang, Jiao Sun, Rada Mihalcea, Erik Brynjolfsson, Alex Pentland and Jiaxin Pei, analyzed trajectories from eight frontier models on SWE-bench Verified (arXiv 2604.22750, v2 of 29 April 2026).

The central result: agentic tasks consume a thousand times more tokens than code chat and code reasoning. And input tokens drive the cost, not output ones.

The reason is mechanical. The agent rereads the original prompt plus everything it has already answered, before each new action. On turn 50, it resends the finished work of the previous 49 turns to produce one more short answer.

That reorders the priorities. Shortening the output pays little. Reducing the number of steps pays a lot.

Before optimizing anything, though, attribution comes first. Without knowing which agent, which flow and which step consumes what, every saving is a guess. That is the subject of instrumenting what you cannot reproduce.

Excess spend falls into three groups. They ask for different interventions.

The first group is structural: the system design charges you on every request. The second is configuration: someone ticked an option and nobody wrote down the price. The third is conceptual, and it is the most expensive of the three.

Three items from this group show up in almost every codebase.

The tool definition gets paid on every request. It is no setup fee. It enters the input on each call, forever.

The numbers are public. On Claude Opus 5, the tool-use system prompt costs 286 tokens with tool_choice set to auto, and 406 with any or tool. The computer tool set adds around 4,500 tokens. The browser one, around 6,600 (Anthropic pricing documentation, read on 28 August 2026).

Closing that arithmetic pays off. At 500 requests a day on Sonnet 5, at US$2 per million input tokens:

500 × 6,600 × US$2 / 1,000,000 = US$6.60 per day
US$6.60 × 30 = US$198 per month

That is US$198 a month to declare the tools, and nothing more. No useful work has happened yet. So designing tools for agents is a cost subject, and not only an accuracy one.

A late retry drags along everything that came before. A retry at step 2 is cheap. A retry at step 12 reprocesses the accumulated context of the eleven steps before it.

The cost of one attempt is no constant. It grows with the position of the failure. Failing early is far cheaper than failing late, which changes where verification is worth putting, the theme of why the agent does not review its own work.

Accumulated context is the base cost. Each turn resends the whole history. It is the item the SWE-bench study identified as dominant.

Prompt caching has three prices, not one. And the relationship between them decides whether it pays.

Anthropic's multipliers, relative to the base input price:

Reads cost a tenth. But writes cost more than normal. So a break-even point exists, and it depends on how many times you reread the same prefix.

For a prefix of P tokens used across N requests:

no cache:    N × P
with cache:  (write multiplier × P) + ((N − 1) × 0.1 × P)

Solving for both TTLs, break-even lands at N = 1.28 on the 5-minute cache and at N = 2.11 on the 1-hour one. The saving by request count:

Two non-obvious readings come out of that.

A 1-hour cache used twice still loses money. Five percent. The common intuition says a longer TTL is always safer. It is not: it costs more to write, and it needs a third read to break even at all.

The 90% ceiling never gets reached. The write keeps being paid. Even at a hundred requests, the real saving lands at 88.8%.

The documentation states the result in prose, saying the cache pays off after one read at the 5-minute TTL and after two at the 1-hour one. The table above is that sentence resolved into numbers.

A zero hit rate is almost never a provider bug. It is a breakpoint in the wrong place.

Invalidation follows a cascade: tools → system → messages. The map of what breaks what:

The top item is the most expensive. Adding one tool to your agent invalidates the entire cache, including the giant system prompt that did not change at all.

Three frequent traps:

1. A breakpoint sitting on content that changes. A timestamp, a session ID or the user's name at the end of the system prompt guarantees a 0% hit rate. No error, no warning. The rule is to put cache_control on the last block that stays identical.
2. A prompt below the minimum. The cacheable minimum is 512 tokens on Opus 5, 1,024 on Sonnet 5, 2,048 on Opus 4.7 and 4,096 on Haiku 4.5. Below that nothing gets cached, and the API returns no error. Only the usage fields reveal it.
3. More than four breakpoints. The limit is 4, with a lookback window of 20 blocks. Extra breakpoints cost nothing, and they do nothing either.

Checking is quick: read cache_read_input_tokens and cache_creation_input_tokens in the response. If the first sits at zero and the second does not, you are paying 1.25× to write a cache nobody reads. Managing what enters the prefix is the same problem covered in why your agent forgets, seen from the invoice side.

Five settings move the price without ever appearing as a cost decision.

The first row deserves special attention, because it is invisible.

Claude 4.7 and later models use a new tokenizer, which produces around 30% more tokens for the same text. The documentation states it in the open, and adds that the exact increase depends on the content and the payload format.

That means a migration can cost more even at a lower price per token. Sonnet 4.6 costs US$3 per million input tokens and uses the old tokenizer. Sonnet 5 costs US$2 and uses the new one:

price:      −33.3%
tokens:     +30% for the same text
effective:  0.667 × 1.30 = −13.3%

A cut announced as 33% is worth close to 13% in practice.

That arithmetic comes from derivation, not measurement. It holds if the 30% applies to your payload, and the documentation itself warns that it varies. Measure yours with the token counting endpoint before planning a budget on the announced number. The point is not the exact value: it is that price per token stopped being comparable across model generations.

A calendar note: the promotional US$2/US$10 price for Sonnet 5 became the standard, and Anthropic cancelled the increase to US$3/US$15 planned for 1 September 2026.

This is the most expensive group, because the spend here is deliberate.

The SWE-bench study measured the relationship between tokens spent and accuracy. It does not rise. Accuracy peaks at intermediate cost and saturates afterward. Past that point, additional tokens buy variance, not results.

Two findings from the same work reinforce it:

• Identical runs of the same task differ by up to 30× in total tokens.
• Kimi-K2 and Claude Sonnet 4.5 consume, on average, 1.5 million more tokens than GPT-5 on the same tasks.

There is a serious operational consequence too. The models cannot predict their own cost: the correlation between prediction and real spend reaches only 0.39, and the underestimate is systematic.

That ends the idea of a spending ceiling enforced by the agent's good sense. It has no way to know how much it will spend before starting, because it cannot predict the context buildup or the trajectory it will take.

A June 2026 catalog documents the result in production. Token Budgets, by Sajjad Khan, gathers 63 confirmed budget-overrun incidents across 21 orchestration frameworks, between 2023 and 2026. Each one cites the GitHub issue and, when reported, the dollar loss. The taxonomy has eight clusters, with a Cohen's kappa of 0.837 over 113 items (arXiv 2606.04056).

A spending ceiling is engineering, with a cutoff in the code. It is no spreadsheet alert.

The route to spending less, then, is not buying more and better tokens. It is cutting steps. The measurement on long context and retrieval showed that from another angle, and it is what agent memory solves in practice: fewer steps mean less resent context, and the cost falls in a non-linear way.

The three big ones price caching with distinct structures. Each one, for that reason, fails in its own way.

Data read on 28 August 2026 in the Anthropic documentation and the OpenAI documentation, plus Gemini's published price tables.

The failure mode follows the structure:

• Anthropic punishes whoever writes a cache they never reuse. Wrote it and never reread it, paid 25% more.
• Google punishes whoever rents a cache nobody reads. Storage gets charged by the hour, hit or no hit.
• OpenAI punishes nobody. And that is why its leak is the hardest to find: with no write premium and no breakpoint under your control, a mutable prefix throws no error, adds no line to the invoice, it only fails to save.

Batch is more uniform. Anthropic and OpenAI both give 50% off input and output. Anthropic accepts up to 100,000 requests or 256 MB, expires in 24 hours and keeps results for 29 days. OpenAI works with up to 50,000 requests and 200 MB files, in a fixed 24-hour window.

One detail almost nobody documents: the batch discount stacks with the cache. And inside a batch, use the 1-hour TTL. The 5-minute one tends to expire before the items get processed, and prewarming with max_tokens: 0 does not work there.

Shared premise: a 20,000-token prefix between system prompt and tool definitions, 500 requests a day, Sonnet 5 at US$2 per million input tokens.

500 req × 20,000 tok × US$2 / 1,000,000 = US$20.00 per day
US$20.00 × 30 = US$600 per month

writes: 50 × 20,000 × US$2.50 / 1,000,000 = US$2.50
reads:  450 × 20,000 × US$0.20 / 1,000,000 = US$1.80
total:  US$4.30 per day = US$129 per month

US$129 ÷ 2 = US$64.50 per month

no cache: 500 × 6,600 × US$2 / 1,000,000    = US$6.60/day = US$198/month
cached:   500 × 6,600 × US$0.20 / 1,000,000 = US$0.66/day = US$19.80/month

In order of return per hour of work:

1. Hunt the moving breakpoint. Search for a timestamp, UUID, username or date inside the system prompt. It is the cheapest fix and the one with the biggest effect.
2. Measure the hit rate. Sum cache_read_input_tokens and cache_creation_input_tokens per route. The ratio between them tells the whole story.
3. Count the tool overhead. Multiply the definition tokens by your volume for the month. A tool the agent never calls goes.
4. Move asynchronous work to batch. Reports, backfills, bulk classification and evaluation: none of that needs an immediate answer.
5. Put a per-session ceiling in the code. Not in an alert. The catalog's 63 incidents exist because an alert stops no execution.

If your case is Claude Code on a subscription rather than the API by token, the arithmetic is different and it lives in what each Claude Code usage pattern costs. This post covers API at scale, where you pay per token and control the prefix.

And one route zeroes the per-token cost: running the model on your own machine. It swaps variable cost for hardware and operating cost, with a lower quality ceiling. What fits on your laptop in 2026 does that arithmetic.

<!-- [PERSONAL EXPERIENCE] -->

Producing this sixteen-post cluster gave me an uncomfortable example of leak number one.

Researching each post means reading primary papers. Several of them are arXiv PDFs. And Anthropic's documentation is direct about what that costs: a 500 kB scientific paper in PDF amounts to around 125 thousand input tokens.

Every fact check that ended in an academic PDF entered the context with that weight. And since each was read once, caching would not have helped: by this post's own table, writing a cache for a single read costs 25% more, not less.

The fix was not technical. It was a change of method: I started reading the abstract on the HTML page before deciding whether the full PDF was worth the spend. Most of the time the abstract already held the number I needed to verify, as happened with both papers cited here.

The judgment left over is this one: caching answers nothing on its own. For content read once, it increases the bill. The right question is never "can I cache this?", it is "how many times will I reread this?".

Is prompt caching worth it for few requests?

It depends on the TTL. On the 5-minute cache, break-even sits at 1.28 requests, so the second read already saves 32.5%. On the 1-hour one, break-even is 2.11: with only two requests you still lose 5%. For single use, caching always costs more.

Is the 1-hour cache always better than the 5-minute one?

No. It costs 2× to write, against 1.25× for the short TTL. It pays when the interval between requests goes past five minutes, or inside a batch, where processing takes longer than the short window. With few reads, the long TTL is the more expensive option.

Can batch and caching be used together?

Yes, and the discounts stack. A cached flow that drops from US$600 to US$129 a month goes to US$64.50 with batch. Inside a batch, use the 1-hour TTL: the 5-minute one tends to expire before processing, and prewarming with max_tokens: 0 gets rejected there.

Why is my cache hit rate zero?

The three most common causes are a breakpoint sitting on variable content such as a timestamp or session ID; a prompt below the model's cacheable minimum, which runs from 512 to 4,096 tokens; and a change to tool definitions, which invalidates every level in cascade. None of the three produces an error message.

Does switching to a cheaper model always reduce the bill?

No, because price per token stopped being comparable across generations. The tokenizer in Claude 4.7 and later produces around 30% more tokens for the same text. A 33% price cut can be worth close to 13% in practice. Measure your real payload on the counting endpoint before projecting savings.

Can the cost of a task be estimated before running it?

With low precision. The SWE-bench study measured a correlation of up to 0.39 between the models' prediction and real spend, with systematic underestimation. The same task varies up to 30× across identical runs. So control has to be a ceiling enforced in code, and not an estimate.

• The cost lives in the resent input, not in the prompt or the output. Cutting steps pays more than cutting words.
• The 5-minute cache pays on the second request. The 1-hour one, only on the third.
• A tool definition gets charged on every request. Add it up before adding one more.
• The invalidation cascade starts at tools. Changed a tool, lost the whole cache.
• Price per token is no longer comparable across model generations, because of the tokenizer.
• Spending more does not buy accuracy. Past the intermediate peak, extra tokens buy variance.
• A spending ceiling is code, not an alert. Sixty-three documented incidents say why.

Every price and multiplier cited here was read in the official documentation on 28 August 2026. LLM prices move fast: check the source before planning a budget on them.