Anthropic shipped Claude Fable 5.1 and a gated Claude Mythos 5.1 on September 1. Same base rate as Fable 5 — $10/$50 per million input/output tokens — so on paper this looks like a minor point release: better benchmarks (52.6% on Terminal-Bench-Science), a 1M-token context window, and a set of safeguard tiers gating the two variants. The number that actually matters for anyone running production agent workloads is buried a few paragraphs into the pricing page: prompt cache reads are now 75% cheaper. Anthropic’s own framing is that this lowers effective cost by 25–45% on typical workloads. That’s not a rounding error, and it’s not really a “discount” either — it’s the platform telling you which prompt shape it wants to reward, and most of the agent pipelines I’ve reviewed this year are shaped exactly wrong for it.

Why a flat per-token price hides the real lever

Sticker price optimization is a trap I see teams fall into constantly: they benchmark $/M tokens across providers, pick the cheapest, and stop there. But for any workload that re-sends similar context turn after turn — which is nearly every agent loop, every multi-turn chat, every tool-using pipeline — the effective cost isn’t the sticker price, it’s (cache writes × write price) + (cache reads × read price) + (fresh tokens × full price). A 75% cut to one term in that equation doesn’t move the sticker, but it can move your actual bill by double digits, and it only pays off if your architecture is generating enough cache reads in the first place.

Here’s the naive version most agent code still ships with:

// naive: system prompt + full tool docs re-sent on every call, no caching boundary
async function callModel(userMsg, history) {
  return await client.messages.create({
    model: 'claude-fable-5-1',
    system: SYSTEM_PROMPT + TOOL_DOCS, // ~8k tokens, identical every call
    messages: [...history, { role: 'user', content: userMsg }],
  })
}

Every single call here pays full input price for 8k tokens of content that hasn’t changed since the session started. Multiply that across a multi-agent fan-out — five subagents, each with their own tool docs reload — and you’re paying the top-of-menu rate for tokens the model has already “seen” a dozen times this session.

Structuring around the cache boundary

The fix isn’t new — prompt caching has existed for a while — but a 75% read-price cut changes the ROI math on how aggressively you should segment prompts around stable vs. volatile content. The pattern I moved to:

async function callModel(userMsg, history) {
  return await client.messages.create({
    model: 'claude-fable-5-1',
    system: [
      { type: 'text', text: SYSTEM_PROMPT, cache_control: { type: 'ephemeral' } },
      { type: 'text', text: TOOL_DOCS, cache_control: { type: 'ephemeral' } },
    ],
    messages: [
      ...history.map(markStableTurnsAsCached), // older turns get their own cache breakpoint
      { role: 'user', content: userMsg },       // only this is genuinely fresh
    ],
  })
}

Two cache breakpoints instead of zero: one for the system/tool-docs block (essentially static per deployment), one for the conversation history up to the last few turns (static within a session, growing slowly). Only the newest user message and the model’s next response are “full price” tokens. At the old cache-read rate this was worth doing but not urgent — the savings were real but modest enough that a lot of teams shipped without it. At 75% off cache reads, skipping this now means leaving 25–45% of your bill on the table for free, on a workload shape you almost certainly already have.

Where this actually pays off — and where it doesn’t

I ran the arithmetic against three workload shapes I actually operate:

• Long-running agent sessions with heavy tool docs (my blog-writing and research subagents): high payoff. Tool docs and system prompt are 6–10k tokens, re-sent on every one of 15–30 turns per session. Caching that block turns a linear cost curve into a mostly-flat one after the first call.
• Single-shot classification or extraction calls: near-zero payoff. If there’s no second call in the session, there’s nothing to read from cache — you pay the (slightly higher) cache-write price once and never recoup it. Don’t add caching overhead here; it’s pure downside.
• Multi-agent fan-out with a shared static preamble (my digest curator’s per-source summarizer agents): high payoff, but only if you architect the shared preamble as one cache entry reused across agents rather than each subagent writing its own. This is the one teams get wrong most often — five subagents each doing their own cache write on effectively identical content is five cache-write charges instead of one write and four reads.

The dividing line is simple: cache pays for itself when the same prefix is read more than roughly once more after being written. Below that, it’s overhead. Most people don’t check which side of that line their workload sits on before wiring in cache_control everywhere, and that’s the actual mistake — not under-caching, but caching indiscriminately and being surprised the bill didn’t move.

The governance angle nobody’s pricing in yet

Fable 5.1 and Mythos 5.1 are, per Anthropic, “the same model, but with different levels of safeguards” — Mythos gets more permissive guardrails for vetted cybersecurity and life-sciences use cases, gated behind a trusted-access program. That’s a second signal worth planning around even if you’ll never touch Mythos directly: safeguard tier is becoming a first-class dimension of model selection, not just capability and price. If you’re building an internal model-routing layer — and by this point in 2026 most platform teams are — it’s worth adding “safeguard tier” as a routing dimension alongside cost and latency now, before you have a workload that actually needs it. Retrofitting a routing dimension into a system that only knows about “cheap model vs. expensive model” is a bigger lift than adding the column while the system is still young.

What I’d actually do this week

If you’re running anything beyond single-shot calls against Claude: audit your system prompts and tool docs for a stable/volatile split, add cache_control breakpoints at the boundary, and check whether your multi-agent fan-out is duplicating cache writes it should be sharing. None of this requires migrating models or rewriting your agent loop — it requires looking at your token bill through the cache read/write split instead of the blended total, which most billing dashboards don’t surface by default. The 75% cut doesn’t reward you for using Fable 5.1. It rewards you for having already structured your prompts the way caching wants — and punishes, relatively speaking, everyone who hasn’t gotten around to it yet.