# Is Claude Fable 5.1 cheaper than Opus 5? Only when cache reads are a third of your bill

> Fable 5.1 kept its $10/$50 sticker and cut one line: cache reads, $1.00 to $0.25. Opus 5 is exactly half of Fable everywhere else, so the crossover is arithmetic, and Anthropic's own 45% ceiling lands on the Opus 5 side of it. The derivation, the 50-read miss penalty, and a 30-day self-audit from the usage fields.

- Published: Sep 3, 2026
- Author: Leo Kaka, Engineering
- Tags: pricing, cost, caching, models
- Canonical: https://pirouter.ai/blog/fable-5-1-cache-read-crossover

---
No. Not unless cache reads are more than a third of your Fable 5.1 bill. The sticker did not
move: Claude Fable 5.1 is $10 per million input tokens and $50 per million output, the same as
Fable 5. Anthropic cut exactly one line, the one most procurement spreadsheets have no column for,
and cut it hard: cache reads went from $1.00 to $0.25 per million. Claude Opus 5 is priced at
exactly half of Fable on every other line and at double Fable 5.1 on that one, so the question in
the title has an arithmetic answer. This post derives it, checks Anthropic's own savings estimate
against it, and shows how to pull the one number the answer depends on out of the `usage` object
you already log.

Every price below is from Anthropic's published list and four of its documentation pages as they
read on 2026-09-03, quoted verbatim. Two outside measurements are cited as theirs. Nothing here
was benchmarked by us.

![Price matrix of Fable 5, Fable 5.1 and Opus 5 across input, five-minute cache write, cache read and output, in USD per million tokens, with the cache read column highlighted](/blog/images/fable-5-1-cache-read-crossover-price-matrix.png "The one line that moved, and the three rows it moves against. Official price sheet as read on 2026-09-03.")

## What changed in Claude Fable 5.1 pricing, line by line

The launch post is direct about it: "Cache reads now cost 75% less, or $0.25 per million tokens,"
and "Fable 5.1's pricing is otherwise the same as Fable 5's: $10 per million input tokens and $50
per million output tokens"
([Introducing Claude Fable 5.1 and Claude Mythos 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1)).
The price list confirms it line by line, and supplies the rows this post compares against.

| USD per MTok | Base input | 5m cache write | 1h cache write | Cache read | Output | Batch in / out |
|---|---|---|---|---|---|---|
| Claude Fable 5 | $10 | $12.50 | $20 | $1.00 | $50 | $5 / $25 |
| Claude Fable 5.1 | $10 | $12.50 | $20 | **$0.25** | $50 | $5 / $25 |
| Claude Opus 5 | $5 | $6.25 | $10 | $0.50 | $25 | $2.50 / $12.50 |
| Claude Sonnet 5 | $2 | $2.50 | $4 | $0.20 | $10 | $1 / $5 |
| Claude Haiku 4.5 | $1 | $1.25 | $2 | $0.10 | $5 | $0.50 / $2.50 |

The entire change is a footnote on that table: "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" ([Pricing — Model pricing](https://platform.claude.com/docs/en/about-claude/pricing)).
The model page restates it and adds that cache writes and the 512-token minimum cacheable prompt
length are unchanged
([What's new in Claude Fable 5.1 — Pricing](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)).

Two estimates travel with the cut: "For typical workloads, costs are reduced by around 25%
relative to Fable 5. For complex coding and highly agentic tasks, the savings could be up to
around 45%." Anthropic labels both as estimates. This post takes them at face value and checks
what they imply.

## Why the Fable 5.1 vs Opus 5 crossover is exactly one-third

Read the Opus 5 row against the Fable 5.1 row. Base input $5 against $10. Five-minute write $6.25
against $12.50. One-hour write $10 against $20. Output $25 against $50. Each is exactly 0.5×. The
exception is cache reads, where Opus 5 is $0.50 against $0.25: exactly 2×.

That regularity collapses the comparison to one variable. Call your Fable 5.1 cache-read spend
*R* and everything else on the same invoice *X*:

```text
Fable 5.1 bill  =  R + X
Opus 5 bill     =  2R + 0.5X        (identical token mix)

Fable 5.1 is cheaper when   R + X  <  2R + 0.5X
                      i.e.  R      >  X / 2
```

As a share of the Fable 5.1 bill, *R / (R + X) > 1/3*. Cache reads must be more than one-third
of what you pay for Fable 5.1 before it beats Opus 5 on the same tokens. Below a third, Opus 5 is
cheaper. At a third, they tie.

The same line can be stated with a number you may already have. On Fable 5 those reads cost
4*R*, so the saving from migrating to 5.1 is 3*R* / (4*R* + *X*). At the crossover, *R* = *X*/2,
that saving is exactly 50%. If moving a workload from Fable 5 to 5.1 cut its bill by more than
half, Fable 5.1 also undercuts Opus 5 on it. Less than half, and Opus 5 is the cheaper model for
that traffic.

Nothing here is an approximation; it is a consequence of Anthropic pricing Opus 5 at a clean half
of Fable on four lines and then moving the fifth.
[The Daily Brief](https://www.beri.net/article/anthropic-fable-5-1-cache-read-multiplier-opus-5-routing-crossover)
published the same one-third result on 2026-09-01; the derivation above was redone from the price
list rather than copied, and it agrees.

## Anthropic's own 25% and 45% land on the Opus 5 side of the line

Run the two estimates backwards through the formula, holding the token mix constant. A 45%
saving means 3*R* = 0.45 (4*R* + *X*), so *R* = 0.375*X*, and cache reads are 0.375 / 1.375 =
**27%** of the new bill. Opus 5 on that mix costs 1.25*X* against Fable 5.1's 1.375*X*: about 9%
cheaper. A 25% saving gives *R* = 0.125*X*, an **11%** share, and Opus 5 about a third cheaper.
Both of Anthropic's published scenarios sit below the line.

You do not have to assume a constant mix, because the chart in the launch post carries its
values in the bars' accessibility labels. It is titled "Indexed cost of Fable usage" with Fable 5
at 100, and its footnote says it was "measured at default effort over four weeks of actual usage
in August 2026," where "Typical workload covers Fable usage across Claude Enterprise, Claude
Code, and the API" and "Highly agentic workload covers context-heavy, tool-heavy work, where
cache reads make up most of the cost." Read from the page markup on 2026-09-03:

| Anthropic's chart (indexed, Fable 5 = 100) | Cache reads | All other tokens | Total |
|---|---|---|---|
| Typical · Fable 5 | 40 | 60 | 100 |
| Typical · Fable 5.1 | 11 | 64 | 75 |
| Highly agentic · Fable 5 | 65 | 35 | 100 |
| Highly agentic · Fable 5.1 | 17 | 38 | 55 |

![Data card with three large figures: 15%, the cache-read share of the Fable 5.1 bill in Anthropic's typical workload panel; 31%, the share in its highly agentic panel; and 33%, the crossover above which Fable 5.1 is cheaper than Opus 5 on the same tokens](/blog/images/fable-5-1-cache-read-crossover-fig.png "Cache reads as a share of the Fable 5.1 bill in Anthropic's two published workloads, against the one-third crossover. Source: [Introducing Claude Fable 5.1 and Claude Mythos 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1), chart values read from the page markup")

The cache-read share of the Fable 5.1 bill is 11 / 75 = **15%** in the typical panel and
17 / 55 = **31%** in the agentic one. Both are under a third; the agentic one is close enough that
a small shift in your read-to-output ratio crosses it. Price the agentic panel on Opus 5 with the
same formula: 2 × 17 + 0.5 × 38 = 53 against Fable 5.1's 55. On the most cache-heavy workload
Anthropic published, Opus 5 comes out about 4% cheaper. On the typical panel, 54 against 75, or
28% cheaper.

The chart also shows the mix moving. A pure 75% cut on 40 gives 10, not 11, and "all other
tokens" grew from 60 to 64 in one panel and 35 to 38 in the other. Anthropic's own measurement has
the new model spending more on the lines whose price did not change. That gets its own section
below; here it is a caution that 25% and 45% describe Anthropic's August traffic, not a formula.

Anthropic does not hide the routing conclusion. The model page opens with: "For most workloads,
start with Claude Opus 5 … Use Claude Fable 5.1 for demanding reasoning and long-horizon agentic
work, or when your evals on Claude Opus 5 at higher effort still fall short"
([Claude Fable 5.1 — Overview](https://platform.claude.com/docs/en/models/fable-5-1/overview)).
That is a capability argument, correctly. The price argument for Fable 5.1 starts above the
one-third line.

## Working the crossover on two workload shapes

Two shapes, priced end to end at list rates, with token counts stated so you can substitute your
own. Each was chosen to land near a number Anthropic published.

**Shape A: a long agentic session that gets the full 45%.** A 200,000-token prefix (repository
context, tool definitions, system prompt) written once to the one-hour cache, then 80 turns that
each re-read it, add 1,000 tokens of fresh input and emit 1,500 tokens of output.

| Line item | Tokens | Fable 5 | Fable 5.1 | Opus 5 |
|---|---|---|---|---|
| 1h cache write | 0.2M | $4.00 | $4.00 | $2.00 |
| Cache reads | 16M | $16.00 | $4.00 | $8.00 |
| Uncached input | 0.08M | $0.80 | $0.80 | $0.40 |
| Output | 0.12M | $6.00 | $6.00 | $3.00 |
| Total | | $26.80 | $14.80 | $13.40 |

Migrating this session from Fable 5 saves 44.8%, Anthropic's agentic ceiling to the decimal.
Cache reads are 27% of the new bill. Opus 5 runs the identical session for 9.5% less. A team that
budgeted on the 45% headline is paying a premium for the same tokens and has no line item that
says so.

**Shape B: a fan-out over a cached corpus.** A 150,000-token document set written once to the
five-minute cache, then 1,000 short extraction calls against it, each adding 200 tokens of
question and returning 100 tokens of answer.

| Line item | Tokens | Fable 5 | Fable 5.1 | Opus 5 |
|---|---|---|---|---|
| 5m cache write | 0.15M | $1.88 | $1.88 | $0.94 |
| Cache reads | 150M | $150.00 | $37.50 | $75.00 |
| Uncached input | 0.2M | $2.00 | $2.00 | $1.00 |
| Output | 0.1M | $5.00 | $5.00 | $2.50 |
| Total | | $158.88 | $46.38 | $79.44 |

Cache reads are 81% of the Fable 5.1 bill, the migration saved 71%, and Fable 5.1 undercuts Opus 5
by 42%. What separates A from B is how many output tokens each re-read of the prefix has to carry,
and that ratio lives in your traffic, not on any rate card.

The catch in Shape B: the read-heavy, output-light traffic that gets Fable 5.1 past Opus 5 is the
traffic two other Claude models price lower still. The same fan-out on Sonnet 5 (cache read $0.20)
comes to about $31.78; on Haiku 4.5 ($0.10) about $15.89, before adjusting for Haiku's older
tokenizer. The docs put it the other way round: Fable 5.1 keeps the tokenizer introduced with
Opus 4.7, and against models older than that "the same text produces roughly 30% more tokens"
([What's new — Tokenizer](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)),
so the same text on Haiku 4.5 counts roughly 23% fewer tokens than the figure above assumes. If your
workload clears the crossover, ask whether it needs a frontier model before asking which frontier
model is cheaper.

One trap on the way down is documented and silent. The caching page lists the minimum cacheable
prompt as 512 tokens for Fable 5.1, Fable 5 and Opus 5, 1,024 for Sonnet 5 and 4,096 for
Haiku 4.5, and says: "Any requests to cache fewer than this number of tokens will be processed
without caching, and no error is returned"
([Prompt caching — Cache limitations](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)).
A prefix that caches on Fable 5.1 can stop caching on Haiku 4.5 with no signal but two zeros in
the usage object. Any cross-tier A/B should assert those fields are non-zero before pricing a run.

## The write price did not move, so a miss is now 50 reads deep

Cutting reads without cutting writes did something the launch post does not mention: it
quadrupled the relative cost of a miss.

| Write ÷ read | Fable 5 | Fable 5.1 | Opus 5 |
|---|---|---|---|
| 5-minute write / cache read | $12.50 / $1.00 = 12.5 | $12.50 / $0.25 = **50** | $6.25 / $0.50 = 12.5 |
| 1-hour write / cache read | $20 / $1.00 = 20 | $20 / $0.25 = **80** | $10 / $0.50 = 20 |

One five-minute write that never gets read costs what 50 reads of that prefix would have; on the
hour-long cache, 80. Prefix stability was a tuning concern on Fable 5. On 5.1 a regression in it
is a budget event, and every existing way to cause one is unchanged.

The clock runs from the wrong end for long generations. "The lifetime is measured from the start
of the request that writes or reads the cache entry, not from the end of its response," and the
documentation works the case: "if a response takes 4 minutes to stream, a follow-up request that
reuses the same cached prefix must start within about 1 minute of that response completing."
Fable 5.1 defaults to high effort with adaptive thinking that cannot be disabled, so one long turn
can consume most of a five-minute window before anyone has read it.

Fan-outs have their own version. "A cache entry only becomes available after the first response
begins. If you need cache hits for parallel requests, wait for the first response before sending
subsequent requests." Launch all 1,000 of Shape B's calls concurrently before the first begins
responding and each pays a write instead of a read: 150M tokens at $12.50 is $1,875 where the
table says $37.50. That is the 50× ratio on one invoice.

History edits are the third way in, and on Fable 5.1 they now cost twice. The model page's rule
for keeping thinking blocks valid is to "treat the conversation as append-only," adding
instructions through mid-conversation system messages rather than editing the system prompt or
tools array, and it notes: "These patterns also keep the prompt cache warm"
([What's new in Claude Fable 5.1 — Breaking changes](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)).
The edit that invalidates a thinking block invalidates the cached prefix under it: one rejected
request or dropped block, plus one 50-read miss.

One change goes the other way. Per-message effort, in beta behind the
`mid-conversation-output-config-2026-07-01` header, lets you "change the effort level
mid-conversation without invalidating the prompt cache." Read it as a cache-preservation feature.
Opus 5 has it too, so it does not tilt the comparison.

## Multipliers stack: US-only inference is 1.1x on cache reads too

The cache multiplier is one of several on the invoice, and they compound.

**Data residency.** For Claude 4.6 and later, "US-only inference (inference_geo: "us") is priced
at 1.1x the standard rate across all token pricing categories (input tokens, output tokens, cache
writes, and cache reads)"
([Data residency — Pricing](https://platform.claude.com/docs/en/manage-claude/data-residency)).
A US-pinned Fable 5.1 cache read is $0.275. The response reports which geo served it in
`usage.inference_geo`, one more field to reconcile against. On a Priority Tier commitment, the
same page says each US-pinned token "draws down 1.1 tokens from your committed TPM."

**Batch.** The Batch API halves input and output, and the pricing page states that the caching
multipliers "stack with other pricing modifiers, including the Batch API discount and data
residency" ([Pricing — Prompt caching](https://platform.claude.com/docs/en/about-claude/pricing)).
A batched Fable 5.1 cache read is $0.125; batched and US-pinned, $0.1375. Batched Fable 5.1 base
input is $5, which is Opus 5's synchronous rate, so anything that can wait an hour closes half the
gap by itself.

**Fast mode, for contrast.** Fast mode exists only for Opus 5 and Opus 4.8, at $10 in and $50 out,
with caching multipliers applied on top. Opus 5 in fast mode therefore carries Fable's sticker and
a $1.00 cache read, Fable 5's old rate; there is no fast mode for Fable 5.1 to buy.

Residency and batch apply identically to Fable 5.1 and Opus 5, so neither moves the one-third
crossover. They move the absolute bill and the burn rate of a commitment. "What does a cached
token cost on this model" is therefore a product of factors set in four places: the model, the
request's `cache_control`, the request's `inference_geo`, and whether it went through Batch. A
cost model keyed on model ID alone is wrong by a factor that is easy to miss and hard to find
afterwards.

## The estimate holds your token mix constant. The model does not.

Every calculation so far priced the same tokens on two models. Fable 5.1 does not emit the same
tokens as Fable 5, and the migration notes list how it differs. "Claude Fable 5.1 may issue one
tool call per turn where Claude Fable 5 batched several," which costs "tokens, round trips, and
wall-clock time." When editing files it "is more likely to rewrite the entire file than make a
targeted edit," and "the rewrite costs more output tokens." Default effort is high, and the
checklist says to "re-tune effort from the default (high)"
([What's new in Claude Fable 5.1 — Behavior differences](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)).
Each one shifts spend onto output, the one line whose price is unchanged, and away from the
crossover.

Two outside meters, quoted as theirs, saw the same direction.

Artificial Analysis, which discloses that it "supported Anthropic with pre-release evaluation" of
the model, reports Fable 5.1 at maximum effort costing $3.76 per Intelligence Index task against
$3.14 for Fable 5, up 20%, "because it uses ~1.7x the output tokens." It credits the cache cut
with about $1.40 per task and puts the counterfactual near $5.16; Opus 5 at maximum effort came to
$2.34, and Fable 5.1 at xhigh effort to $2.72
([Claude Fable 5.1 tops the Artificial Analysis Intelligence Index](https://artificialanalysis.ai/articles/claude-fable-5-1)).
A reasoning benchmark spends most of its tokens on output, so the direction is not surprising;
what is useful is that the cut is visible in their number and the extra output outweighed it.

Techsy ran 14 matched tasks through OpenRouter on 2026-09-02 at low effort and billed $0.14693 on
Fable 5.1, $0.13285 on Fable 5 and $0.080725 on Opus 5, all three passing 14 of 14. Their calls
were short and uncached, so the cut never fired and Fable 5.1 cost 1.11× Fable 5 for identical
passes. Two side findings matter more. Leaving Claude Code at its default high on a function that
already passed at low billed 4.0× ($0.08798 against $0.022) for the same green tests. On the one
turn where the cache fired, the cache-read line fell 75% while the whole turn fell 21%, because
output still bills at $50
([Claude Fable 5.1 Review: We Metered It Against Fable 5 and Opus 5](https://techsy.io/en/blog/claude-fable-5-1)).
They add that subscription plans' five-hour windows do not price cache reads the way the API
does, so the 25% does not stretch a Claude Code seat.

Neither meter is your invoice. The narrower claim is this: the 25% and 45% hold the token mix
fixed, Anthropic's own chart shows it moving, and both independent measurements saw it move in the
direction that favours Opus 5. Adopt the model at its defaults and budget on the headline, and you
will save less than the headline.

## Three API changes that break a router before the bill does

Fable 5.1 ships three breaking changes. The one most relevant to anyone routing between Claude
models fails without a message.

**Forced tool use returns a 400.** `tool_choice` set to `{"type": "any"}` or
`{"type": "tool", "name": "..."}` is rejected with `tool_choice: type "tool" and "any" are not
supported for this model`; `auto` and `none` are unchanged. If forced calls are how you get
schema-valid JSON, the documented fix is strict tool use or structured outputs, a code change and
not a model-ID swap. One third-party gateway's changelog handles it differently: "Anthropic rejects
forced tool use … with a 400. The gateway forwards these requests with auto instead, so existing
code keeps working," and on the same page, "The gateway strips sampling parameters such as
temperature and top_p before forwarding, so a request that sets them still succeeds"
([LLM Gateway changelog — Claude Fable 5.1](https://llmgateway.io/changelog/claude-fable-5-1)).
That is a request rewritten in flight and returned as a success, the pattern the
[post on failover configuration](/blog/multi-provider-failover-setup) spent a section on. Whether
it is a convenience or a defect depends entirely on whether you knew.

**Thinking blocks travel one way, and the drop is silent by default.** "Every thinking block
records which model produced it, and it's preserved in one direction only: Claude Fable 5.1 reads
earlier models' thinking blocks, and no earlier model reads Claude Fable 5.1's." Then the sentence
written for routers: "When a request carries a block the target model can't read (a router or
fallback that switches models mid-conversation, for example), the API drops the block before the
model sees it. Dropped blocks don't count toward input_tokens and aren't billed. With the
thinking-binding-controls-2026-08-01 beta header, the drop is reported in a top-level
input_transformations array. Without it, the drop is silent." A cost strategy built on the
arithmetic above is precisely an architecture that switches models mid-conversation. Send the
header from the first request that can fail over, and log `input_transformations`, or the
reasoning continuity you pay Fable 5.1 rates for stops at the model boundary with nothing to show
for it except a slightly smaller bill.

**Editing earlier turns invalidates thinking blocks, on a schedule.** Modifying anything before a
Fable 5.1 thinking block returns a 400 reading `The block is bound to a different conversation`.
"The check is enforced for new accounts created on or after August 31, 2026. For accounts created
earlier, the API records the mismatch but acts on it only when the request sets
thinking.block_binding.prefix_mismatch_behavior." The same request can pass on an account opened
last year and fail on one opened last week. Find out which path yours is on before a
history-editing bug becomes a production 400.

One line on the same page runs the other way. Fallback on a refusal is supported, the permitted
targets for Fable 5.1 are Opus 4.8 and Opus 5, and "fallback credit refunds the prompt-cache cost
of switching models." It is the one place in this release where Anthropic eats a miss for you.

## A 30-day self-audit from the usage fields

The one-third test needs a number most teams have never computed: the share of Fable 5.1 spend
that is cache reads. Every response you have received carries the inputs. The caching
documentation defines them and gives the identity:

```text
total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens
```

where `input_tokens` is only "the tokens that come after the last cache breakpoint," not all the
input you sent ([Prompt caching — Tracking cache performance](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)).
The `cache_creation` object splits writes into `ephemeral_5m_input_tokens` and
`ephemeral_1h_input_tokens`, which matters because the two write prices differ.

| Usage field | Multiply by (Fable 5.1, USD / MTok) | Goes into |
|---|---|---|
| `cache_read_input_tokens` | 0.25 | *R* |
| `input_tokens` | 10 | *X* |
| `cache_creation.ephemeral_5m_input_tokens` | 12.50 | *X* |
| `cache_creation.ephemeral_1h_input_tokens` | 20 | *X* |
| `output_tokens` | 50 | *X* |
| `inference_geo == "us"` | × 1.1 on the whole row | both |

Then compare *R* / (*R* + *X*) with one-third. Do it per workload: averaging a fan-out and an
agent loop that share one key gives a share that is wrong for both.

```python
# 30-day roll-up over logged `usage` objects for one workload on claude-fable-5-1.
RATE = {"read": 0.25, "input": 10, "w5m": 12.5, "w1h": 20, "output": 50}  # USD per MTok

def cache_read_share(usages):
    r = x = 0.0
    for u in usages:
        cc = u.get("cache_creation") or {}
        geo = 1.1 if u.get("inference_geo") == "us" else 1.0
        r += u["cache_read_input_tokens"] * RATE["read"] * geo
        x += (u["input_tokens"] * RATE["input"]
              + cc.get("ephemeral_5m_input_tokens", 0) * RATE["w5m"]
              + cc.get("ephemeral_1h_input_tokens", 0) * RATE["w1h"]
              + u["output_tokens"] * RATE["output"]) * geo
    share = r / (r + x)
    return share, ("Fable 5.1 cheaper" if share > 1 / 3 else "Opus 5 cheaper on this mix")
```

Divide by a million if your logs hold raw token counts. The geo factor cancels in the ratio,
since it applies to Opus 5 as well, but not in the dollars, so keep it.

Three more checks fit in the same pass:

1. **Assert both cache fields are non-zero** on any workload you believe is cached. Two zeros
   means it was not, and nothing told you. Budget for this on any move to Sonnet 5 or Haiku 4.5,
   whose minimum cacheable length is two to eight times Fable 5.1's.
2. **Search your code for `tool_choice` set to `any` or a named tool.** Each occurrence becomes a
   400 on the new model ID, or a silent rewrite if a gateway in the path decided to be helpful.
3. **If anything in your stack switches Claude models mid-conversation,** send the
   `thinking-binding-controls-2026-08-01` header and log `input_transformations` from the first
   day. Dropped blocks are cheaper to discover as a log line than as a quality regression.

## The two numbers on the sticker no longer decide the bill

Fable 5.1's cache read is a quarter of Fable 5's, half of Opus 5's, and more than Sonnet 5's. A
miss costs 50 reads. A US-pinned read costs 1.1× of that, a batched one half. Which Claude is
cheaper depends on the product of those factors and on one ratio in your own traffic, and the two
figures a procurement sheet has columns for do not enter into it.

This blog has argued adjacent versions of that: the
[same weights carry different prices](/blog/one-weight-many-prices) across hosts,
[time of day is a pricing variable](/blog/time-as-a-pricing-variable), and a
[price change is a contract clause](/blog/price-notice-is-a-contract-clause) with a notice period.
This release is the cleanest case yet because nothing is hidden. The footnote is on the price
list, the estimates are labelled estimates, the chart carries its own numbers, and the model page
already says to start with Opus 5. The one missing input is on your side of the API, not theirs.

PiRouter is being built on the assumption that a router has to read that input. A router that
prices each request from its `usage` object per model, multiplier by multiplier, rather than from
the model's sticker, is designed to notice a crossover like this one the day a footnote changes.
That is a design position, not a shipped feature, and the arithmetic above needs none of it: pull
thirty days of usage, compute the share, compare it with a third. Then route.

---

## Sources

### anthropic.com

- [Introducing Claude Fable 5.1 and Claude Mythos 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1)

### platform.claude.com

- [Pricing — Model pricing](https://platform.claude.com/docs/en/about-claude/pricing)
- [What's new in Claude Fable 5.1 — Pricing](https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1)
- [Claude Fable 5.1 — Overview](https://platform.claude.com/docs/en/models/fable-5-1/overview)
- [Prompt caching — Cache limitations](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
- [Data residency — Pricing](https://platform.claude.com/docs/en/manage-claude/data-residency)

### beri.net

- [The Daily Brief](https://www.beri.net/article/anthropic-fable-5-1-cache-read-multiplier-opus-5-routing-crossover)

### artificialanalysis.ai

- [Claude Fable 5.1 tops the Artificial Analysis Intelligence Index](https://artificialanalysis.ai/articles/claude-fable-5-1)

### techsy.io

- [Claude Fable 5.1 Review: We Metered It Against Fable 5 and Opus 5](https://techsy.io/en/blog/claude-fable-5-1)

### llmgateway.io

- [LLM Gateway changelog — Claude Fable 5.1](https://llmgateway.io/changelog/claude-fable-5-1)