Claude Fable 5.1 shipped on 1 September 2026, and its per-token price is identical to the model it replaces: 10 dollars per million input tokens, 50 dollars per million output tokens. Same as Claude Fable 5. Nothing to report, if that is where you stop reading.

The number that moved is the one that does not appear in any headline: cached input reads went from about 1.00 dollars per million tokens to 0.25.

For most people that is a rounding detail. For anyone running an agent, it is the bill.

Why cache reads are the bill

A cached read is what you pay when the model re-reads context it has already seen — the system prompt, the tool definitions, the accumulated transcript. Standard cache-read pricing is roughly a tenth of the input rate, which on a 10 dollar model puts it near 1.00 per million. Writing to the cache costs more than plain input, about 1.25 times, because the cache has to be built.

Now consider the shape of an agentic workload. The agent reads a large stable prefix, calls a tool, gets a result, and goes round again. Every turn re-sends everything that came before. The volatile part — the new tool result — is tiny. The stable part is enormous and grows.

So across a long-running task, the overwhelming majority of input tokens are cache reads. Not fresh input. Not output. Reads of the same prefix, over and over, once per turn.

Cut that rate by four and you have cut the dominant term. Anthropic's own framing puts typical workloads around 25 percent cheaper and highly agentic ones as much as 45 percent cheaper, on unchanged headline rates.

The headline number is the wrong instrument

This is a recurring shape, and it is worth naming because it keeps catching people out.

A price list has one number everyone quotes and several that actually determine what you pay. Which one dominates depends entirely on the shape of your usage. Apple's iPhone price rise had the same structure in the opposite direction: a flat headline increase, with the real movement in a sub-line — there, the storage ladder; here, the cache rate.

If you benchmark models by comparing input and output rates in a table, this change is invisible to you. Fable 5.1 and Fable 5 are the same row. The workloads where the difference shows up are exactly the ones that are hardest to model on a spreadsheet, because their cost depends on turn count and prefix stability rather than on request count.

The measured cost of agentic work keeps being the surprising number in every write-up — and the cache rate is a large part of why.

The condition attached to it

Cache pricing only helps if you actually get cache hits, and caching is a prefix match. Any byte change anywhere in the prefix invalidates everything after it.

The usual silent invalidators:

  • A timestamp or a generated request ID inside the system prompt
  • Tool definitions serialised in non-deterministic order
  • A tool list that varies between requests
  • Volatile content placed before stable content

The diagnostic is direct: check whether cache-read token counts are non-zero across repeated requests with the same prefix. If they are zero, the rate cut is worth nothing to you, and something in your prefix is moving.

Order matters too. Stable content first, volatile content after the last cache breakpoint. That is the whole discipline.

The other changes are breaking ones

Worth knowing before anyone upgrades on the strength of the price alone. Fable 5.1 is not a drop-in for every harness:

  • Forced tool use is gone. Requesting a specific tool, or requiring that some tool be called, returns an error. The replacement is automatic tool choice plus an instruction naming the tool, strict schemas, or structured outputs.
  • Thinking blocks are bound to the model that produced them. Other models drop them silently.
  • Editing earlier turns invalidates thinking blocks. Harnesses that rewrite history need to become append-only.

So the honest summary is a cheaper model for long-running agent work, with a small amount of harness work to collect it.

What to do

  • Check your cache-read token counts before assuming you benefit. Zero reads means zero saving.
  • Move volatile content after your stable prefix. Timestamps and per-request identifiers in a system prompt are the classic reason a cache never warms.
  • Re-measure cost per completed task, not per request. Turn count is what this change acts on.
  • Audit the harness for forced tool use and history rewriting before switching.

What is not established

  • Independent verification of the 25 and 45 percent figures. They are the vendor's characterisation of typical and agentic workloads, and your prefix stability decides where you land.
  • Whether the cache rate holds across the tier over time.
  • How the change interacts with effort settings in practice, since a mid-conversation effort change can itself reset a cache.