Token savings are not dollar savings: the conversion math

Three posts into this series, every feature came with a headline percentage: 84% fewer tokens from clearing, “over 85 percent” from deferred tool loading, whole conversations compacted into a summary. Those numbers are real. What almost nobody publishes is the conversion rate — how many cents of invoice you get per percent of token. It is not one-to-one, it is not even close to constant, and on a typical agent request two different levers that both remove tokens differ by roughly 90x in what they do to your bill. Here is the arithmetic.

The unit error

Every token-reduction claim shares a hidden assumption: that a token is a unit of money. It is a unit of text. The money is attached separately, and on a single model there are four or five different attachments.

Here is Claude Opus 4.8, taken straight from Anthropic’s pricing table:

Same model, same billing period, same word “token” in every sentence anybody writes about optimization. A 50x spread.

This is why “we cut tokens by 84%” is an incomplete sentence. Eighty-four percent of what? Cut 84% of your cache reads and you saved a rounding error. Cut 84% of your output and you cut most of your bill.

Your bill has a different shape than your context window

Take a plausible mid-run request from a coding agent on Opus 4.8. It has been going for a while, so most of the window is history, and the prefix is cached:

Read the two share columns against each other. The 86.5% of tokens that dominate the context window carry 23.1% of the cost. The 3.8% that are output carry 51.3%.

Your context window and your invoice are two different distributions over the same events. Context engineering optimizes the first one. You are billed on the second.

The same request, two optimizations

Now apply two levers to that request and price both.

Lever A — clear stale tool results. Context editing removes 33,000 tokens of spent tool output from the cached history. Cache reads fall from 45,000 to 12,000. Everything else is untouched.

Ignoring the cache-invalidation cost for one moment (we come back to it, and it makes this worse):

• Before: $0.0225 + $0.0250 + $0.0500 = $0.0975
• After: $0.0060 + $0.0250 + $0.0500 = $0.0810
• Tokens: 52,000 to 19,000, a 63.5% reduction
• Cost: a 16.9% reduction

Add the real clearing cost — a clear invalidates the prefix, so the 12,000 surviving tokens must be rewritten at $6.25/M rather than read at $0.50/M. Amortise five clears across a 50-request run and each request carries about $0.0075 of rewrite:

• After, honestly: $0.0885 per request, a 9.2% reduction

Lever B — think a little less. Lower effort by one notch and the model spends 1,400 output tokens instead of 2,000. Nothing else changes.

• Before: $0.0975
• After: $0.0225 + $0.0250 + $0.0350 = $0.0825
• Tokens: 52,000 to 51,400, a 1.2% reduction
• Cost: a 15.4% reduction

Side by side, with conversion rate defined as percent-of-bill saved divided by percent-of-tokens saved:

Roughly a 90x difference in conversion efficiency, on the same request, on the same model, in the same second. One lever removed 55 times more tokens and saved 40% less money.

Why context features convert badly by construction

This is not bad luck. It follows from what the features are for.

Context features operate on the context window. The context window, in any long-running agent, is mostly conversation history and tool results. If you have set up caching at all — and you should have — history is exactly the part that is cached, which means it is exactly the part billed at 0.1x. The levers are aimed, structurally, at the cheapest token class on the sheet.

Then there is the second-order effect, which is the part that surprises people: clearing does not only remove tokens, it reprices the survivors. Anthropic’s caching docs are explicit that the cache follows a tools to system to messages hierarchy and a change at any level invalidates that level and everything after it. Clear something in the middle and the tail must be written again.

That turns into a breakeven condition you can actually compute. Let K be the tokens you keep (and therefore rewrite), C the tokens you clear, and N the number of requests before the next clear:

cost of clearing   = K x (write_rate - read_rate)
saving afterwards  = N x C x read_rate

breakeven:  N x C  >  K x (write_rate - read_rate) / read_rate

On Opus 4.8 with a 5-minute cache, (6.25 - 0.50) / 0.50 = 11.5, so:

N x C must exceed 11.5 x K. With a 1-hour cache (2x write) the multiplier is 19x.

In the worked example: K = 12,000, so N x C must exceed 138,000. Clearing 33,000 tokens gets there after 4.2 requests. Clear every third request instead of every tenth and the feature is costing you money while its logs proudly report a shrinking context.

The same headline, two very different bills

Take the tool-definition tax — roughly 55,000 tokens of MCP definitions on a five-server setup, which deferred loading cuts to about 8,000. Call it a 76% cut of a 62,000-token request. What is that worth?

If your definitions were uncached (a changing prefix, or low enough traffic that the cache keeps expiring between calls):

• Before: 60,000 input at $5/M + 2,000 output at $25/M = $0.350
• After: 13,000 input at $5/M + 2,000 output at $25/M = $0.115
• 67% off the bill. Excellent conversion, because you deleted full-price input.

If your definitions were already in a warm cached prefix:

• Before: 55,000 read at $0.50/M + 5,000 input at $5/M + 2,000 output at $25/M = $0.1025
• After: 8,000 read at $0.50/M + 5,000 input + 2,000 output = $0.0790
• 23% off the bill. Same token cut, one third the money.

The identical published percentage is worth 67% or 23% depending on a configuration detail the announcement never mentions, because the announcement is measuring the token axis and you are paying on the dollar axis. This is not a criticism of the vendors — the token figure is the honest thing for them to publish, since they do not know your cache-hit rate. It is a reason to never plug their percentage into your forecast.

There is a real consolation in the cached case, and it is not financial. Tool search is the one lever in this series that does not disturb the prompt cache, and Anthropic’s own evaluation shows tool-selection accuracy climbing from 79.5% to 88.1% on Opus 4.5 when the model stops choosing among hundreds of definitions. A retry avoided is billed at 100%.

The denominator moves too

One more reason a token percentage is a soft currency: the token count itself is not a property of your text.

“Claude 4.7 and later models and Claude Mythos Preview use a newer tokenizer that contributes to their improved performance on a wide range of tasks. This tokenizer produces approximately 30% more tokens for the same text.”

— Anthropic pricing docs, verified 2026-07-28

Identical prompt, identical sticker price per token, roughly 30% more tokens billed. An optimization that carefully removed 30% of your tokens is fully cancelled by a model upgrade — and the upgrade will look free, because the $/M figure on both pages is the same.

Worth noting: when we checked that same page for the hidden-costs roundup in early June, it said “up to 35%.” Today it says approximately 30%. Even the tokenizer premium is a number with a date on it.

Lines with no token axis at all

Some of your invoice cannot be reduced by sending fewer tokens, because it is not metered in tokens. From the current pricing docs:

• Web search: $10 per 1,000 searches, on top of the tokens the results consume. An agent that searches twice per task spends $0.02 in search fees before a single token is priced.
• Code execution: $0.05 per hour, per container, after 1,550 free hours per organization per month — and billed by execution time, minimum five minutes, charged even if the tool is never called when files are preloaded. Free when paired with web search or web fetch.
• Managed Agents session runtime: $0.08 per session-hour, metered only while the session is running. Anthropic’s own worked example puts runtime at $0.08 of a $0.705 hour, about 11% of that bill, entirely invariant to prompt size.
• Google context cache storage: $1.00 per 1M tokens per hour on Gemini 3.6 Flash and 3.5 Flash, charged for keeping a cache warm whether or not you read it. This is rent, not usage.

And the rates move on their own

The last term in the equation is the one you do not control at all. Every item here is from the current docs and changes your bill without changing your code:

• Claude Sonnet 5 is on introductory pricing. $2/M input and $10/M output “through August 31, 2026, after which the standard pricing of $3/$15 per million input/output tokens will take effect.” That is a 50% increase, on a date, roughly five weeks out from this post. Any Sonnet 5 forecast running past August needs two rate cards.
• US-only routing costs 1.1x on everything — input, output, cache writes, cache reads — via inference_geo: "us" on Claude 4.6 and later. Regional and multi-region endpoints on Bedrock and Google Cloud carry a 10% premium over global.
• Fast mode is 2x on Opus 5 and Opus 4.8: $10/M input and $50/M output against $5/$25 standard, and it stacks on top of the caching multipliers.
• OpenAI now charges for cache writes. Its caching guide states writes have no additional fee on models before the GPT-5.6 family, and 1.25x the uncached input rate from GPT-5.6 onward — which the pricing table confirms at $6.25/M against $5/M input on gpt-5.6-sol. A cost model built on “OpenAI caching is free to write” was correct last year and is now wrong by 1.25x on the newest family.

And one that moved in your favour, worth knowing because the old belief is still widespread: Claude no longer surcharges long context. The docs now state that Claude 4.6 and later include the full 1M-token window at standard pricing, and spell it out: “A 900k-token request is billed at the same per-token rate as a 9k-token request.” If you are still avoiding long prompts on current Claude models to dodge a premium tier, you are optimizing against a rule that no longer applies there. Check per model and per vendor — it is not universal.

Instrument dollars, not tokens

The fix is unglamorous: stop logging token counts as your cost metric and log cost as your cost metric. The API already hands you the four buckets you need.

Anthropic’s usage object splits input three ways, and the split is designed to be non-overlapping — input_tokens is documented as the tokens “which were not read from or used to create a cache.” So the four fields sum cleanly:

# Claude Opus 4.8, $ per token. Verified 2026-07-28 against
# platform.claude.com/docs/en/about-claude/pricing
RATES = {
    "input":       5.00 / 1_000_000,
    "cache_write": 6.25 / 1_000_000,   # 5-minute TTL; 1-hour is 10.00
    "cache_read":  0.50 / 1_000_000,
    "output":     25.00 / 1_000_000,   # thinking tokens included here
}

WEB_SEARCH_PER_CALL = 10.00 / 1_000

def request_cost(usage) -> float:
    """Dollar cost of one Messages API response."""
    tokens = (
        usage["input_tokens"]                  * RATES["input"]
        + usage["cache_creation_input_tokens"] * RATES["cache_write"]
        + usage["cache_read_input_tokens"]     * RATES["cache_read"]
        + usage["output_tokens"]               * RATES["output"]
    )
    searches = usage.get("server_tool_use", {}).get("web_search_requests", 0)
    return tokens + searches * WEB_SEARCH_PER_CALL

Three things this buys you immediately:

1. A cost-weighted mix, not a token mix. Aggregate request_cost by bucket over a day of real traffic and you get the second table in this post for your own workload. That tells you which lever is worth building before you build it.
2. Cache-invalidation alarms. A sudden rise in cache_creation_input_tokens with flat cache_read_input_tokens means something is breaking your prefix every request — a changing timestamp, a tool definition being regenerated, an effort level toggling between turns. Anthropic’s docs demonstrate the effort case directly: switching effort from high to medium mid-conversation turned a 3,546-token cache read into a 3,546-token cache write. That is a 12.5x repricing of the same tokens, caused by one parameter.
3. A true reading of your reasoning spend. output_tokens_details.thinking_tokens reports how many of your billed output tokens were internal reasoning, and the docs are blunt that this is not what you see: “You are billed for the full thinking process, not the thinking content visible in the response.” On keep-all models — Opus 4.5 and everything numbered 4.6 and up — prior turns’ thinking blocks also stay in context and are billed as input on every subsequent turn.

What actually moves the bill

Ranked by conversion efficiency rather than by how impressive the token graph looks:

That last row is the honest summary of the three posts before this one. Context editing, compaction and tool search are worth deploying — for window headroom, for latency, for accuracy on long runs, and for the retries they prevent. They are simply not, in most cached agent workloads, where the money is.

The money is in the classes you barely look at, because there are only a few thousand of those tokens and they scroll past too fast to feel expensive.

The one-line version

Multiply before you celebrate. A percentage of tokens is not a percentage of dollars until you have weighted it by class, and on a live agent those weights differ by 50x within a single request.

That is the last of the mechanics. What remains is fitting them together — which lever to reach for on which symptom, in what order, and what to measure after. That is the playbook, and it is the last piece of this series.

Verified on 2026-07-28 against primary sources: Anthropic pricing (model rates, caching multipliers, batch discount, long-context policy, tokenizer note, tool and server-tool pricing, Managed Agents runtime), prompt caching (invalidation hierarchy, usage-field definitions), steering thinking (thinking billed as output, effort-driven cache invalidation, thinking_tokens), OpenAI prompt caching and pricing, and Google Gemini pricing. All worked examples use published rates and stated assumptions; they are illustrations of the method, not measurements of your workload — run the numbers on your own usage data. This is the fourth post in a series on context engineering, after context editing, compaction and the MCP context tax. See our methodology for how we verify.