What share of the tokens you pay for are never read?

Every vendor publishes what a token costs. None publishes a method for working out how many of yours did nothing, because none of them has a commercial reason to.

The data required is already being returned to you on every single API response, at no additional charge. What is missing is a definition worth measuring against and a small amount of plumbing.

First, a definition worth defending

"Never read" is loose. A model attends to everything you send, so in a literal sense nothing in the context window is ignored.

The useful question is narrower: which tokens could not have changed the answer? That is measurable, and it splits into three categories with very different economics.

category	what it is	how literal
Never retrieved	Written to cache at a premium, never read back	Fully literal. You paid for reuse that did not occur
Retrieved but inert	Sent and processed, but could not have altered the output	Definitional, but defensible
Generated then discarded	Output tokens nobody consumed	Depends on the product

The first category is the one to start with, because it needs no judgement at all.

Category one: cache writes that are never read

Prompt caching charges a premium up front in exchange for cheap reuse later. Published multipliers relative to the base input rate, as of August 2026:

operation	multiplier
cache read (hit)	0.1x
cache write, five minute	1.25x
cache write, one hour	2x

If the reuse happens, the arithmetic is excellent. Anthropic's documentation states that caching pays off after one cache read at the five minute duration and after two at the one hour duration.

If the reuse never happens, you have bought nothing. The prefix costs 1.25x where it would otherwise have cost 0.1x, a factor of 12.5, applied to what is usually the largest block of input in the request. A workload in this state is worse off than one with caching switched off entirely.

The measurement is a single ratio:

cache read ratio = cache_read_input_tokens
                   ------------------------------------------------
                   cache_read_input_tokens + cache_creation_input_tokens

Collect it per workload across a run of requests that should share a prefix. A ratio near zero, with cache creation staying positive, means every request is writing and none is reading.

The causes are almost always the same handful. A current timestamp interpolated into the system prompt header. A request or session identifier near the front. A per-user string in a shared preamble. A JSON block serialised without a stable key order. A tool list that varies between callers. Caching is a prefix match, so any byte change anywhere in the prefix invalidates everything after it.

None of these raises an error. Nothing fails. The request succeeds and the invoice grows.

Category two: retrieved but inert

This is the largest line in most estates and the hardest to argue about, so measure it in parts rather than as a single number.

Tool definitions for tools that are never called. Schemas are sent on every request whether or not the model uses them. Published overhead for August 2026:

item	tokens
Tool use system prompt, Claude Opus 5, tool choice auto	286
Tool use system prompt, Claude Sonnet 5, tool choice auto	354
Tool use system prompt, Claude Opus 4.7, tool choice auto	675
Bash tool, Claude Opus 5, 4.8, 4.7	325
Text editor tool	700
Computer use tool	735, plus 466 to 499 of system prompt

Individually small. Multiplied by request volume they are not, and the ratio worth computing is straightforward: tokens spent presenting each tool, against the number of times that tool was actually invoked. A tool schema shipped on a million requests and called on four thousand of them has a defined cost per call.

Fetched content beyond what the answer used. Anthropic publishes indicative sizes for the web fetch tool: an average 10 kB web page is roughly 2,500 tokens, a 100 kB documentation page roughly 25,000, and a 500 kB research paper PDF roughly 125,000. If the answer rested on two paragraphs, the remainder was paid for and inert. A content cap parameter exists precisely because this is a known problem.

History resent every turn. The API is stateless, so each call resends the conversation so far. Early turns that no longer influence anything are billed again on every subsequent request. Search results are explicit about this: the documentation notes they are counted as input tokens in the turn that retrieved them and in subsequent turns. One search, charged once, paid for repeatedly.

Context editing and compaction exist as controls for exactly this. Their existence is itself the evidence that the default behaviour costs money.

Category three: generated then discarded

Output is charged at five times input on every current model, so this category punches above its volume.

Thinking tokens are output tokens. On models where reasoning is on by default, a request that previously produced only an answer now also produces reasoning, billed at the expensive rate, whether or not the task needed it. Depth controls exist and are the right lever, but a default is not a decision.

Narration is the other half. Progress updates between tool calls, closing summaries, explanations of what is about to happen: all output, all charged at 5x. Some of it is what makes an agent usable. Some of it is written for a log nobody opens.

This category is the one where a number alone will mislead you, so treat it as a prompt for a product conversation rather than a target to minimise.

The method, in the order worth doing it

Step one, instrument. Log four fields per request with a workload tag: input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens. Add the server_tool_use block if server-side tools are in play. This is an afternoon of work and it costs nothing to run.

One correction while you build it: input_tokens is the uncached remainder only. Total prompt size is the sum of all three input fields. Dashboards that plot input_tokens as prompt size understate every cached workload, sometimes by an order of magnitude.

Step two, compute the cache read ratio per workload. Highest certainty, lowest effort, largest single swing. Either it finds a twelvefold overcharge on your biggest input block or it rules one out.

Step three, divide tool presentation cost by invocation count. Needs no new instrumentation if tool calls are already logged.

Step four, sample retrieved content against the answer. Manual, sampled, not automated. Twenty requests read properly will tell you whether fetched content is a rounding error or the main event, and that is enough to decide whether to build anything further.

Step five, express the result as cost per completed task. Per-token cost is falling and cannot detect any of the above. Cost per task captures all of it in one figure that maps to a business outcome.

A worked example, and the ordering it corrects

Illustrative arithmetic from published August 2026 list prices, not an observed engagement. Its purpose is to show which line dominates, because most teams guess wrong.

Take an agent running on Claude Opus 5 at $5 per million input tokens, with a five minute cache write at $6.25 and a cache read at $0.50. Say 100,000 requests a month, each carrying a 20,000 token system prefix that is meant to be cached, with a tool set attached.

line	calculation	monthly
Prefix, caching working	2,000 MTok mostly read at $0.50	roughly $1,000
Prefix, caching silently broken	2,000 MTok written at $6.25	roughly $12,500
Difference from one misplaced timestamp		roughly $11,500
Tool use system prompt at 675 tokens	67.5 MTok at $5	roughly $338

Two things fall out of that table.

The caching failure is worth about $11,500 a month, or roughly $138,000 a year, and its entire cause is a byte that should not have been in the prefix. Nothing errors. Nothing alerts. The only visible symptom is a number in a field nobody logged.

The tool overhead, which is the line teams usually reach for first because it is easy to reason about, is about $338. It is real, it is worth trimming, and it is a rounding error beside the thing sitting silently next to it.

That ordering is the point of measuring rather than guessing. Intuition ranks these two the wrong way round, because one is legible and the other is invisible.

What a good answer looks like

Not zero.

Some slack is the price of good answers. Trimming context until quality drops is a worse outcome than paying for tokens that turned out to be unnecessary, and an optimisation programme that treats waste as the only variable will find it, at the cost of the thing the spend was for.

The goal is a number you know and have chosen. An estate that cannot state its waste ratio is not efficient. It is unmeasured, and those are not the same condition.

The durable part and the perishable part

The figures above are dated August 2026 and will move. Prices change, tokenizers change, tool overheads change with every model release, and the specific token counts quoted here will be wrong within a year.

The method does not move. Four fields, one ratio, three categories, in that order. The instrumentation is free, the arithmetic is trivial, and the reason nobody hands you this is not that it is difficult. It is that measuring your waste is worth less to a vendor than selling you the tokens.

TechNative is a FinOps Foundation Implementation Partner and works with European organisations on measuring and governing AI spend on AWS. If you want a second pair of eyes on what your usage data is telling you, get in touch.