LLM Price Cuts Landed in the Cache Column, Not Your Bill

Inference got up to 80% cheaper this year. Your AI line item probably did not move. Both things are true, and the reason is a column on the pricing page that almost nobody reads: cache reads. For an agentic product — anything that loops, holds a codebase in context, or carries a conversation across turns — the cache-read price, not the headline input and output price, governs most of the bill. The 2026 price war was fought almost entirely in that column.

That has a blunt consequence. The public pricing table ranks models wrong for the workload you are actually running, and whether you captured this year's discount was decided by prompt architecture you shipped months ago, not by a vendor announcement you read last week.

Two kinds of numbers in this post

Every price below comes from a vendor's own published table, fetched on 26 October 2026, and every ratio was computed by us from those tables. The screenshots are here so you can check the arithmetic yourself.

The savings percentages are a different class of claim. "Costs 40% less on typical workloads," "typical bills drop about 25%," "the cost of Fable intelligence just dropped 54%" — each of those is a company reporting a number about its own product, from its own workloads, not independently reproduced. We cite them and label them, and we do not build the argument on them. Where the argument needs a measured number, it uses a published price or an independent evaluator.

Exactly one number moved

Claude Fable 5 and Claude Fable 5.1 are priced identically on every line a buyer normally compares: $10 per million input tokens, $50 output, $12.50 for a five-minute cache write, $20 for a one-hour write. The only cell that differs on Anthropic's price list is "Hits and refreshes" — $1 per million for Fable 5, $0.25 for Fable 5.1. A 75% cut, with the sticker price unchanged to the cent.

Read one row up and the ranking starts to wobble. Fable 5.1 costs 2.5x Opus 5.5 on input ($10 against $4) but only 1.25x on cache hits ($0.25 against $0.20). The premium a buyer reads off the page is roughly double the premium an agent actually pays. One table, two defensible rankings, depending on which column your workload lives in.

The spread is not a constant you can memorise, either. Cache-hit price as a share of input price runs 2.5% on Fable 5.1, 5% on Opus 5.5 and Sonnet 5.5, 10% on Haiku 5.5 — and 10% on the superseded Fable 5. The depth of the cache discount is a per-model decision, re-made with every release.

The vendor states the mechanism itself

This is not a reading between the lines. Anthropic's own Opus 5.5 announcement says cache reads "make up the majority of agentic and coding work costs," prices them at $0.20 per million, and calls that 60% less than Opus 5. Input and output, in the same paragraph, fell 20%.

The cut is three times deeper in the column nobody quotes than in the one every headline reported.

Where an agent's money actually goes

Cognition published a breakdown of a single coding task on its own benchmark: output $1.07, uncached input $0.84, cached input $3.08 — $4.99 in total at the old $1.00 per million cache-read rate. Cached input is 62% of that bill. The two columns the pricing page advertises account for 38%. The token mix behind it is ~3M cached tokens against roughly 21k output and 70k uncached input, which they summarise as "over 95% of the tokens on both models are cache reads."

Cognition sells an agent built on these models, so read their headline savings figures as a vendor's claim about itself. The cost structure is the part that holds up, because Anthropic states it independently and the ratio is reproducible from the published prices.

Now the penalty for getting it wrong. On Opus 5.5 a five-minute cache write costs $5 per million against $0.20 for a hit — 25x for re-sending context the model already holds. Even plain uncached input is 20x the hit price. A prompt that busts the cache every turn — a timestamp at the top of the system prompt, a tool list that reorders, a history rebuilt instead of appended — pays that multiple on every turn, quietly, and nothing in your logs calls it an error.

Cache invalidation is not a performance bug. It is a pricing event.

The same arithmetic, the opposite answer

Run the reasoning at OpenAI and it points the other way. Its published table lists gpt-6-astra at $10.00 input / $50.00 output / $1.00 cached input, and gpt-6.1-sol at $2.00 / $10.00 / $0.10. Astra is 5x Sol on the number you read and 10x on the number a cache-dominated workload actually pays.

So the correction inverts. The same reasoning that makes Anthropic's most expensive model cheaper than it looks for agentic work makes OpenAI's most expensive model more expensive than it looks. Two vendors, the same pricing structure, opposite corrections — which means there is no rule of thumb to carry between them. There is only the arithmetic, per model, against your own token mix.

A price cut is not a bill cut

Artificial Analysis measured Fable 5.1 at $3.76 per Intelligence Index task at maximum effort against $3.14 for Fable 5. That is 20% more per task, arriving in the same release as the 75% cache-read cut, because the newer model emits roughly 1.7x the output tokens.

Artificial Analysis disclose that they did pre-release evaluation work for Anthropic, which is worth knowing — and which makes the finding more interesting rather than less, since it runs against the vendor's marketing.

Price per token and cost per task are different quantities, and a single release can move them in opposite directions. Only one of the two appears on your invoice.

What to do before the next announcement

1. Instrument the cache-hit rate. Both vendors return cached-token counts in the usage payload of every response. If you cannot state today what fraction of your input tokens are cache reads, you cannot forecast your AI spend, and no pricing page will tell you.
2. Forecast from your token mix, not the price list. Multiply your measured mix by each column, per model. That number, not the sticker, is what a model switch costs you.
3. Treat prompt structure as a cost control. Stable prefix, append-only history, nothing volatile above the cache breakpoint. This is an architecture decision with a 25x multiplier attached, which puts it well outside the "prompt engineering detail" bucket where it usually sits.
4. Re-rank per workload when prices change. A cut that lands in the cache column is worth most to the teams with the longest reusable context and nothing at all to a team doing one-shot classification.

This is the work we do when we take AI-built software to production at SV Dev: the cost review happens before the model selection, not after the first surprising invoice. It is the same class of problem as pinning model versions and containing AI-written code — a decision that looks like an implementation detail at commit time and becomes a line on a P&L two quarters later.

Key takeaways

• The 2026 LLM price cuts landed mostly in cache reads, a column the headline price never quotes.
• Fable 5 and Fable 5.1 have identical headline prices; only the cache-read price changed, by 75%.
• Sticker ranking and cache ranking disagree, and they disagree in opposite directions at Anthropic and OpenAI.
• A cache miss on Opus 5.5 costs up to 25x a cache hit, charged on every turn.
• A 75% price cut can still produce a higher bill if the model emits more output tokens.

FAQ

What is a cache read and why does it dominate agentic costs?

When a model re-reads context it has already processed — a system prompt, a tool schema, a codebase, the earlier turns of a conversation — that context can be served from a prompt cache at a steep discount instead of being re-ingested at full input price. Agents re-read enormous amounts of stable context on every turn, so cache reads become the majority of their tokens and, with them, the majority of the bill.

Why did my AI bill not fall when prices fell?

Most likely one of three reasons: your workload has little reusable context, so the cache discount does not apply to you; your prompts invalidate the cache each turn, so you pay write or full input prices repeatedly; or you moved to a newer model that produces more output tokens per task, which can outweigh a cache-read cut.

Is the most expensive model always the wrong choice for agents?

No, and that is the point. On Anthropic's table the top model's premium roughly halves once you price it on cache reads; on OpenAI's it roughly doubles. The ranking depends on the vendor and on your token mix, so it has to be computed rather than assumed.

How do I measure this without new tooling?

Read the usage object you already receive on every API response. Sum cached input tokens, uncached input tokens and output tokens per task over a week, then multiply those three totals by each candidate model's three prices. That is the whole method.