Fable 5.1 Pricing: Cheaper Only If You Cache

One line item. That's it. Here's the whole diff, from Anthropic's pricing page:

Everything else carries over: the model ID is claude-fable-5-1, the context window is 1M tokens by default, output tops out at 128k per request, and adaptive thinking is always on. The API surface, the limits, the tokenizer and the stop_details categories are unchanged.

So this isn't a price cut in the normal sense. It's a conditional rebate on one behavior, and Anthropic's own framing says so: the 25–45% figures come from measuring Anthropic's August 2026 usage mix. That's a real measurement of a real workload. It just isn't a measurement of yours.

When exactly one line item falls by 75%, your total bill falls by 75% of whatever share that line item held. That's the entire calculation:

Savings = 0.75 × (cache reads as a share of your bill)

Run it backwards and the headline numbers stop being marketing and start being a spec. To hit 25%, cache reads have to be 33% of your spend. To hit 45%, they have to be 60% of it. Those are demanding numbers. A cache-read bucket that eats 60% of your bill describes an agent replaying an enormous frozen prefix over dozens of turns — a coding harness, a document-heavy RAG loop, a long-running orchestrator. It does not describe a chatbot, a classifier, or anything that reads a short prompt and writes a long answer.

Go look at your last invoice before you touch the model ID. Split spend into four buckets — fresh input, cache writes, cache reads, output — and multiply the cache-read share by 0.75. That is your ceiling. Not your estimate: your ceiling, before the next section takes some of it back.

Two months ago I wrote up how much prompt caching actually saves and the conclusion was that caching pays from the very first re-read. That's still true, and it's more true now — a 40k-token prefix costs $0.50 to write and $0.01 to read back on 5.1. What changed is the gapbetween teams that structured their prompts for caching and teams that didn't. That gap just got four times wider.

Here's the part the launch coverage mostly skipped, and it's in Anthropic's own migration guideunder "behavior changes":

In long agent loops, Fable 5.1 may issue one tool call per turn where Fable 5 issued several.

Each extra turn is another assistant message, another round trip, and more output tokens — at $50 per million, the most expensive thing on the invoice. Artificial Analysis reported roughly 1.7× the output tokens on the same task at high effort, and one tool call per turn is a very plausible mechanism for exactly that.

Which sets up a race between two numbers. Cache reads got 75% cheaper; output volume went up ~70%. Net win only if:

0.75 × (cache-read spend) > 0.70 × (output spend)

Which simplifies to a rule you can hold in your head: cache-read spend has to be at least ~93% of output spend before the discount covers the extra tokens.

Put real numbers on it. Take a 30-turn agent run with a 40k-token frozen prefix and ~1.5k output tokens per turn — roughly the shape of the publishing agent that writes this blog:

Same model, same prompt, same discount — and a 35-point swing depending entirely on whether the loop batches its tool calls. That's a modeled run, not a billing export, but the input ratios are ordinary and you can re-run it against your own numbers in about ten minutes.

The fix is in the docs and it's one sentence of prompt: append a batching instruction after each user message telling the model to issue independent tool calls together, and leave the earlier copies in the history so the cached prefix stays intact. Cheap fix. It just isn't automatic, and nobody's invoice tells them they needed it.

Anthropic calls the migration "mostly drop-in," which is fair, but the exceptions are the kind that surface at 2 a.m. in production rather than in a smoke test.

1. Forced tool choice returns a 400. On claude-fable-5-1, both {type: "any"} and {type: "tool", name: "..."} are rejected:

400 invalid_request_error
tool_choice: type "tool" and "any" are not supported for this model.

If you used a forced tool to guarantee valid JSON — and a lot of us did, it was the standard trick — move to tool_choice: {type: "auto"}, name the tool in the instruction, and set strict: true on the schema. {type: "none"} still works for a turn that must not call tools. Grep your codebase for tool_choice before you flip the model ID; this one fails loudly and immediately, which is the good case.

2. Thinking blocks are one-way. Fable 5.1 reads thinking blocks from Opus 5, Fable 5, Mythos 5 and earlier models. None of those can read its blocks. If you route hard steps to 5.1 and cheap steps to a smaller model — which is exactly what good cost routing looks like — you have to strip reasoning at the boundary on the way back down.

3. Editing earlier turns invalidates thinking blocks — and restarts your cache. This is the expensive one, and it's the whole article in one bullet. Every 5.1 thinking block is bound to the exact system prompt, tools array and history that preceded it. Send it back after any of those changed and you get a 400 that a retry loop won't clear. You can opt into graceful degradation with the thinking-binding-controls-2026-08-01 beta header and prefix_mismatch_behavior: "drop_block", but degrading isn't free either. Anthropic puts it plainly: an integration that invalidates prior thinking on every request restarts the prompt cache each time, which can raise cost per task.

Read that twice. The single most common way to lose the cache-read discount is client-side history rewriting — the thing most homegrown agent loops do by default.

Client-side compaction that keeps recent turns verbatim behind a summary is the specific pattern called out. So is deleting old tool results, and so is snipping turns out of the middle. If you built your own compaction layer before the server-side one existed, that code is now actively costing you money. Move to server-side compaction or context editing, which don't count as edits because the check compares the conversation as you sent it.

Six steps, in the order I'd do them:

• Measure first. Split a week of spend into fresh input, cache writes, cache reads and output. Multiply the cache-read share by 0.75. If that is under ~5%, this migration is a capability decision, not a cost decision — stop treating it as one.
• Front-load the stable tokens. System prompt, then tool definitions, then long-lived context (schemas, style guides, docs), then the cache_control marker, then everything volatile. One reordered tool definition invalidates the entire prefix.
• Make history append-only. Never edit, reorder or delete earlier turns. Swap client-side compaction for server-side compaction or context editing.
• Kill forced tool_choice. Replace any and tool with auto plus an explicit instruction and strict: true schemas.
• Add the batching instruction to every long agent loop, or the extra output tokens will eat the rebate you just earned.
• Change effort with a mid-conversation system message, not a request parameter — on 5.1 that keeps the cached prefix alive across the change.

That last one is quietly the best thing in this release and almost nobody is talking about it. On Fable 5, output_config.effort was request-level, so dialing effort down for a routine step dropped your cached prefixes and cost you more than it saved. On 5.1 you send a role: "system" message carrying only output_config, and the cache survives. Per-step effort tuning finally works the way it always should have, and on output-heavy loops it's worth more than the cache-read cut.

Verification is straightforward: run a normal multi-turn session with the beta header set to drop_block and log input_transformations on every response. An empty array every turn means your history is intact. A prefix_binding_mismatch means something upstream changed and you are paying full input price without knowing it. Set it to "error" in CI so a regression fails the build instead of the invoice.

Worth asking, because the docs still recommend starting with Opus 5 for most workloads. Fable is the expensive tier, and a 75% cut on one line item doesn't change which tier your task belongs to.

Fable 5.1 earns its price on genuinely hard, long-horizon work — the benchmark that moved most is Terminal-Bench-Science 0.1, from 24.7% on Fable 5 to 52.6% on 5.1. That's not a marginal gain, and if your agent lives in that territory the model is the cheap part of the project. But if you're routing everything to Fable because it's the newest thing, the cache discount is a rounding error against picking the right tier, and the same goes for how you fan work out to subagents.

One more wrinkle: at loweffort, 5.1 answers from memory more often instead of calling a search or retrieval tool. If your product quietly depends on retrieval firing at low effort, that's a correctness regression wearing a cost-savings costume. Raise effort for those requests or tell the model explicitly when to search.