Claude Fable and Mythos Cost Twice as Much as Opus. For Agents, They Can Cost Less

Everyone read the same headline number: Claude Fable got about 25 percent cheaper, up to 45 percent for agentic work. Then everyone moved on.

Almost nobody looked at which price moved. Base input did not change. Output did not change. Cache writes did not change. One number changed, and it changed the shape of the cost model rather than its size.

Here is the footnote from Anthropic’s pricing table, verbatim:

Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price. All other models use the standard 0.1x multiplier.

Every Claude model prices a cache read at one tenth of base input. The Fable and Mythos line prices it at one fortieth. It is the only exception in the entire table, and it produces a result that reads like a typo.

The inversion

Put the two frontier models side by side.

Prices per million tokens, from Anthropic’s published pricing page, checked 4 September 2026.

Read the cache-read column against the base-input column. Fable’s base input is twice Opus 5’s. Its cache read is half Opus 5’s.

That is not a rounding artefact. Two and a half percent of ten dollars is twenty-five cents; ten percent of five dollars is fifty. The premium model has the cheaper read, and it is cheaper by a factor of two.

For anything that re-reads a large context on every turn — which is what an agent is — the read column is most of the bill. So the ranking flips.

The 100:1 rule

Take one agent turn in steady state: the prefix is already cached, the model reads it, thinks, and emits some output. Ignore the write for a moment; we will come back to it, because it is the other half of the story.

Cost of that turn is one cache read of the whole prefix, plus the output you generate:

cost_per_turn = R * cache_read + O * output_price

  R = cached prefix, in tokens
  O = output, in tokens

Fable beats Opus 5 when its side of that comparison is smaller:

  R * 0.25 + O * 50   <   R * 0.50 + O * 25
  O * 25              <   R * 0.25
  R / O               >   100

When your cached context is more than 100 times your per-turn output, the expensive model is the cheap one.

Worth stating the general form, because prices move and this article should not:

R / O  >  (output_fable - output_opus) / (cache_read_opus - cache_read_fable)
       =  (50 - 25) / (0.50 - 0.25)
       =  100

Plug in whatever the pricing table says on the day you read this.

Here is the same thing as numbers you can check:

The crossover at 200K prefix and 2K output is an exact tie — a nice sanity check that the algebra is right.

# Steady-state cost of one agent turn that reads an already-cached prefix.
def turn_cost(cached_tokens, output_tokens, cache_read, output_price):
    return (cached_tokens * cache_read + output_tokens * output_price) / 1_000_000

FABLE = {"cache_read": 0.25, "output_price": 50.0}
OPUS_5 = {"cache_read": 0.50, "output_price": 25.0}

for prefix, out in ((200_000, 1_000), (200_000, 2_000), (200_000, 5_000), (500_000, 2_000)):
    f = turn_cost(prefix, out, **FABLE)
    o = turn_cost(prefix, out, **OPUS_5)
    print(f"{prefix:>7} ctx {out:>5} out  fable ${f:.4f}  opus ${o:.4f}")

Which workloads sit above 100:1? Codebase-wide refactoring, long research runs, document and spreadsheet work, anything with a large tool surface — the exact shapes Anthropic describes the line as being built for. Which sit below? Chat, drafting, summarisation into long output, anything where the model writes more than it reads.

The other half: the most expensive writes in the lineup

The discount applies to reads only. Writes kept their standard multipliers — 1.25x for the 5-minute TTL, 2x for the 1-hour TTL — applied to a base of ten dollars. That produces the highest cache-write prices in the active lineup.

Now look at the ratio between them:

Every other model in the lineup sits at 12.5. The Fable line sits at 50.

A cache miss on Fable costs you fifty reads. On every other model it costs you twelve and a half. Use the 1-hour TTL and it is eighty.

This is the part that turns a pricing note into an architecture constraint. On other models, prefix stability is a tuning detail worth a modest saving. On this line, your cache hit rate is worth four times more, and a workload that thrashes its prefix can end up paying more on Fable than it would have on Opus even at a 250:1 read ratio.

How many turns before it pays off

The 100:1 rule is the steady-state limit. It assumes the write is already paid for and amortised down to nothing. Real sessions are finite, so the honest question is how many turns you need before the cheaper reads outrun the dearer write.

Write the prefix once, then run N turns against it:

total_fable = R * 12.50 + N * (R * 0.25 + O * 50)
total_opus  = R *  6.25 + N * (R * 0.50 + O * 25)

Fable wins when:
  R * 6.25  <  N * (R * 0.25 - O * 25)
  R / O     >  25 / (0.25 - 6.25 / N)

That denominator turns negative below 25 turns. Under 25 turns on one cached prefix, no context ratio is large enough — Opus 5 wins every time. Above it, the bar drops fast:

Two of those rows are exact ties you can check by hand. At 50 turns with a 200K prefix and 1K output, both models total $7.50. At 100 turns with 200K and 1.5K output, both total $15.00.

This assumes the prefix is written once — in one go or incrementally as the conversation grows — and then survives. Every eviction restarts the amortisation, which is the previous section’s point arriving from a different direction.

The practical reading: long-running coding and research sessions clear this bar easily, because they run hundreds of turns against one prefix. Request-response services that assemble a fresh context on every call never clear it, no matter how large that context is.

What actually breaks the prefix

Given the above, it is worth knowing precisely what invalidates a cached prefix. From the caching documentation:

• Tool definitions — changing any name, description or parameter invalidates everything: tools, system and messages
• Web search or citations toggles, and the speed setting — invalidate system and message caches
• tool_choice — invalidates message blocks
• Images — adding or removing one anywhere in the prompt invalidates message blocks
• Thinking configuration and output_config.effort — always invalidate message blocks, and on some models the tool and system caches too

And the failure mode that costs the most while looking like it works: a breakpoint placed on a block that changes every request. Put a timestamp or the incoming user message inside the cached block and the prefix hash differs every time. You pay a fresh write on every single request and never get a read. On Fable that is $12.50 per million tokens, forever, for a cache that never hits.

There is also a 20-block lookback window. If a growing conversation pushes your breakpoint 20 or more blocks past the last write, the lookback misses the prior entry entirely and you pay full input price. The fix is a second breakpoint placed closer to that position from the start, so a write accumulates there before you need it.

If you are wiring tools into agents at all, the surface area here overlaps heavily with the one I covered in building and running MCP servers safely — every tool you attach is prefix you are now paying to keep stable.

Three levers most people are not using

Move system instructions into messages. On the Fable and Mythos line, and on Opus 5 and Opus 4.8, you can append a {"role": "system"} message to messages instead of editing the top-level system field. The cached prefix stays intact. Not available on Sonnet 5.

Change effort without paying for it. Editing output_config.effort normally invalidates message blocks. On models supporting per-message effort, carrying the change in that same in-messages system message leaves the cached prefix alone. On a line where a miss costs fifty reads, this is not a micro-optimisation.

Pre-warm with max_tokens: 0. The API reads your prompt, writes the cache at your breakpoint, and returns immediately with an empty content array and zero output tokens billed. Fire it at startup or on a schedule so the first real request does not eat the cache-miss latency. It still incurs the write charge, so do it once and keep it warm rather than on every request.

Two smaller ones worth knowing: the minimum cacheable prefix on this line is 512 tokens, the lowest in the lineup (Sonnet 5 needs 1,024, Haiku 4.5 needs 4,096); and on the 1-hour TTL, a single avoided re-write more than pays for the upgrade, since the extra write cost is 0.75x base against a 1.25x re-write you would otherwise repeat.

Does it hold on Vertex AI and Bedrock?

On Google Cloud, yes — exactly. The Vertex AI global table publishes the same numbers as the first-party API:

The inversion survives into the batch tier: a batched cache hit is $0.125 on Fable against $0.25 on Opus 5 — the same factor of two.

Two Vertex-specific details worth having. Neither model carries a long-context surcharge; the above-200K column is identical to the below-200K one, which is not true of every Claude model there (Sonnet 4.5 doubles). And regional or multi-region endpoints carry a 10 percent premium over global across all token categories including cache reads, so the ratio holds while the absolute numbers move.

On AWS there are two different products. Claude Platform on AWS rates token usage at the same standard per-model rates, then converts to Claude Consumption Units at $0.01 per CCU — the arithmetic is unchanged, only the invoice unit differs. Amazon Bedrock is partner-operated and publishes its own rates; I could not extract machine-readable figures from that page, so I am not quoting any. Check them against your own account before relying on the ratio there.

Caveats that change the arithmetic

The tokenizer. Claude 4.7 and later use a newer tokenizer that produces roughly 30 percent more tokens for the same text. Your prefix in tokens is larger than the equivalent prefix on Sonnet 4.6, so per-token comparisons across generations understate the newer models. This cuts against the case above and should be in your model, not your footnotes.

Multipliers stack. The Batch API’s 50 percent discount and the 1.1x data-residency multiplier for US-only inference both apply on top, including to cache reads.

Cost is not the only axis. Anthropic’s own comparison table lists Fable’s comparative latency as Slower, against Moderate for Opus 5. Adaptive thinking is always on and the default effort is high. And Fast mode — the premium tier that trades money for speed — exists on Opus 5 and Opus 4.8 and is not offered on Fable at all. On a latency-sensitive path the model that costs less per turn can still be the wrong choice, and Opus has a speed lever that Fable does not.

Anthropic does not recommend Fable by default. Their own model documentation says to start with Opus 5 for most workloads and reach for Fable for demanding reasoning and long-horizon agentic work. Nothing here contradicts that. The point is narrower: if you ruled Fable out on price for a context-heavy agent, the arithmetic says you ruled it out for the wrong reason.

The bottom line

The interesting move was not a discount. It was a change in the shape of the cost function: one multiplier cut by a factor of four, applied only to reads, on the most expensive model in the lineup.

That does three things. It makes long-context agents structurally cheaper on the frontier model than on the mid-tier one above a measurable threshold. It makes cache misses four times more expensive relative to hits than anywhere else. And it makes prefix stability — which tools you attach, whether an image sneaks into the prompt, where your breakpoint sits — a first-order cost decision rather than a tuning pass.

Before you switch anything, measure two numbers you already have. The API returns cache_read_input_tokens and cache_creation_input_tokens in every response. Their ratio tells you whether this pricing structure is working for you or against you.