Opus 5 high vs Fable 5.1 low
ai/opus-5-high-vs-fable-5-1-low · Updated · Tags: ai
正在用 AI 翻譯成中文,可能需要一分鐘… 以下暫時顯示英文原文。
Claude Opus 5 at high vs Claude Fable 5.1 at low
Colour key: Opus 5 @ high Fable 5.1 @ low
TL;DR
- Use Opus 5 at
high. Anthropic's own rule: escalate to Fable 5.1 only when your evals on Opus at higher effort measurably fall short. - The 2x price gap is a mirage on cached loops. Fable lists at exactly 2x ($10/$50 vs $5/$25), but its
cache read is half ($0.25 vs $0.50 /MTok). On a 200K-cached turn, Fable at
lowlands ~25% cheaper than Opus athigh. Flip to output-heavy with no cache and Opus wins. Price your own request shape. - On speed, the pairing beats the tier labels. Throughput is a tie (~52 tok/s each, measured). Opus is
faster at equal effort, but at this pairing Fable at
lowreaches first token in 6.04s vs 17.45s and finishes a 500-token answer in 15.6s vs 27.0s. Effort sets latency; the model barely does. - Nobody publishes an Opus 5 vs Fable 5.1 benchmark. The one head-to-head that exists is Opus 5 at 91.7% vs Fable 5 at 91.3%, for ~60% of the cost.
- Do these two before choosing a model at all: cache the prefix (2.5x–3.7x) and sweep effort (
lowcost 0.25x for −8 pts on coding; on researchmediummatched the default). Both are worth more than this decision.
Fable 5.1 costs exactly 2x Opus 5 per token, so the instinct is that Fable is the expensive option. On a
cache-heavy agent loop that instinct is wrong: Fable's cache reads are half Opus's in absolute dollars, and
low effort cuts the tokens that carry the 2x premium. The two configurations can land within cents of each
other — sometimes with Fable cheaper.
This compares one specific pair of operating points, because they are the two that actually compete:
Opus 5 at its default effort against Fable 5.1 dropped to low.
Summary
Everything that follows, in one table. Winner in bold where there is one.
Claude Opus 5 @ high | Claude Fable 5.1 @ low | |
|---|---|---|
| PRICE | ||
| Input / output per MTok | $5 / $25 | $10 / $50 — exactly 2x |
| Cache read per MTok | $0.50 (10% of input) | $0.25 (2.5% of input) — half |
| Cache-heavy turn (200K cached, 5K in, 3K out) | $0.200 | $0.150 — ~25% cheaper |
| Output-heavy turn (no cache, 5K in, 20K out) | $0.525 | $0.400 or $0.550 — flips on an unmeasured assumption |
| Batch API | 50% off | 50% off |
| SPEED | ||
| Published latency tier | Moderate | Slower |
| Measured throughput | 52.1 tok/s | 52.3 tok/s — tie |
| Measured time to first token (at these efforts) | 17.45s | 6.04s — Fable ~2.9x faster |
| Measured 500-token answer (at these efforts) | 27.04s | 15.60s |
| Fast mode | Yes — up to 2.5x output tok/s (at $10/$50) | None |
| Priority Tier | No | No |
| Effort's speed effect | Dominant — TTFT 2.37s at low to 69.92s at max | Dominant — 6.04s at low to 266.80s at max |
| QUALITY | ||
| Published head-to-head | 91.7% (vs Fable 5's 91.3%, at ~60% of the cost) | 91.3% (Fable 5, not 5.1) |
| Benchmark table for this exact pair | none published | none published |
| Effort cost/quality curve | medium −2 pts @ 0.5x cost; low −8 pts @ 0.25x | low "often exceeds xhigh/max of previous models" |
| Capability ceiling | — | Higher — the only reason to pay for it |
| CONSTRAINTS | ||
| Context / max output | 1M / 128K | 1M / 128K |
| Thinking | Adaptive; disable allowed at ≤ high | Always on — cannot be disabled (400) |
| Forced tool use | Works | 400 — use auto + instruction, or strict |
| Zero data retention | Fine | Requires 30-day retention; ZDR orgs get a 400 |
| VERDICT | Default. Start here. | Escalate only when Opus at higher effort measurably falls short |
Opus 5 wins on raw per-token price, on fast mode, and on speed at equal effort, and it
matched Fable 5 on the one published benchmark at ~60% of the cost. But neither the price gap nor the speed
gap survives this specific pairing: Fable's halved cache read plus low effort can put it under Opus on
cost, and at high vs low it is measurably quicker, not slower (§4.2). Cache your prefix and sweep
effort before spending anything on this decision; both are worth more than the choice itself.
Number provenance — every figure above and below is labelled:
| Label | Means |
|---|---|
| Published | platform.claude.com model + pricing docs, read 2026-09-08 |
| Measured | Anthropic's own benchmark runs, quoted in the cost-optimization guide |
| Derived | arithmetic on published list prices — exact, no estimation |
| Third-party | Artificial Analysis measurements, read 2026-09-08 — not Anthropic's numbers |
| Assumption | clearly flagged; not measured for this pairing |
Contents
- Quick answer
- Price — list · the cache-read reversal
- Effort — what
highandlowactually do - Speed — published tiers · measured tok/s, TTFT and the effort ladder
- Quality — the measured numbers · what nobody publishes
- Worked cost example
- How to choose
- API differences that bite
1. Quick answer
| Verdict | |
|---|---|
| Start with | Opus 5. Anthropic's own docs say so: "start with Claude Opus 5 for most workloads" (Published) |
| Escalate to Fable when | "your evals on Claude Opus 5 at higher effort still fall short" (Published) — the trigger is a measured shortfall, not a hunch |
| Cheaper per token | Opus 5, by exactly 2x (Published) |
| Cheaper per cached token | Fable 5.1, by exactly 2x — $0.25 vs $0.50 /MTok (Derived) |
| Faster | Depends what you compare. At equal effort, Opus 5 — tiers "Moderate" vs "Slower", and only Opus has fast mode. At high vs low, Fable: 6.04s to first token vs 17.45s (Third-party, §4.2). Throughput is a tie either way |
| Higher ceiling | Fable 5.1 — it is the more capable model; that is the entire reason to pay for it |
| The trap | Judging on list price alone. Cost per completed task is what matters, and it does not track the per-token ranking |
2. Price
2.1 List (Published)
| Input /MTok | Output /MTok | Cache read /MTok | Cache read as % of input | |
|---|---|---|---|---|
| Claude Opus 5 | $5.00 | $25.00 | $0.50 | 10% |
| Claude Fable 5.1 | $10.00 | $50.00 | $0.25 | 2.5% |
| Ratio (Fable ÷ Opus) | 2.00x | 2.00x | 0.50x | — |
Both: 1M context, 128K max output, default effort high, adaptive thinking.
2.2 The cache-read reversal
This is the number people miss. Cache reads are priced as a percentage of base input — and the percentages are not the same:
- Opus 5 charges the standard 10% of its $5 input → $0.50/MTok
- Fable 5.1 charges 2.5% of its $10 input → $0.25/MTok
So on the part of an agent request that is usually largest — the replayed cached prefix — Fable is the cheaper model in absolute dollars. The 2x premium only applies to fresh input and generated output.
The more cache-heavy your loop, the more the headline 2x shrinks. Section 6 works this through.
Batch API is 50% off on both (Published). Fable 5.1 has no Priority Tier and no fast mode.
3. Effort
output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}. Both models default to high, and both
support all five levels. Effort scales thinking depth and tool-call count — it is the first lever to reach for
after caching, and it changes cost within one model without changing the model.
3.1 What each end does
Opus 5 at high | Fable 5.1 at low | |
|---|---|---|
| Thinking | Adaptive, on by default | Adaptive, always on — cannot be disabled (400) |
| Position | The API default — omitting effort gets you this | A deliberate step down from Fable's default |
| Behaviour | Full verification behaviour; thorough | Scopes to what was asked; fewer, more consolidated tool calls; less preamble |
| Docs note | low/medium are "unusually effective on this model" | low "still performs very well ... often exceeding the xhigh or even max performance of previous models" |
3.2 The measured effort curve
Anthropic's runs, long-horizon coding, Claude Opus 5 (Measured) — this is the only published same-model effort/cost curve for either of these two:
| Effort | Quality vs default | Cost vs default |
|---|---|---|
high (default) | baseline | 1.00x |
medium | −2 points | 0.50x |
low | −8 points | 0.25x |
And on research/knowledge work (Measured, run on Fable 5) the curve is far flatter — low gave up
1–3 points for a third to a half off, and medium matched the default at 70–85% of its cost. The default
"bought nothing measurable over medium on any of the four benchmarks measured."
Read that difference carefully. Effort is worth real quality on long-horizon coding and nearly nothing on
research. Whether low is safe is a property of your workload, not of the model.
4. Speed
4.1 What Anthropic publishes
| Opus 5 | Fable 5.1 | |
|---|---|---|
| Published latency tier | Moderate | Slower |
| Fast mode | Yes — up to 2.5x output tokens/sec, at $10/$50 (research preview, Claude API only) | No |
| Priority Tier | No | No |
| Long turns | — | Hard tasks can run many minutes in a single request |
Two concrete timing facts:
- Lower effort is measurably faster: 4.5 vs 7.9 minutes per problem on one research benchmark, low vs
default (Measured). That is a ~43% wall-clock cut — dropping Fable to
lowbuys back a chunk of its "Slower" tier. - Opus 5 fast mode costs $10/$50 — exactly Fable 5.1's base price (Derived). If you are willing to pay Fable money, one option is Opus 5 running 2.5x faster rather than Fable running slower.
Opus 5 caveat: it sometimes thinks before its first visible block, which raises time-to-first-token. On user-facing chat, the one-line fix is "Latency-sensitive; begin your visible answer immediately."
4.2 Measured: throughput ties, effort sets latency (Third-party)
"Moderate" vs "Slower" is the whole of Anthropic's published speed guidance — no tokens/sec, no latency, no benchmark. Artificial Analysis measures both, per effort level, against the first-party API. For the exact pair this doc is about:
| AA, read 2026-09-08 | Opus 5 @ high | Fable 5.1 @ low | Winner |
|---|---|---|---|
| Output speed | 52.1 tok/s | 52.3 tok/s | tie |
| Time to first token | 17.45s | 6.04s | Fable, ~2.9x faster |
| End-to-end, 500-token answer | 27.04s | 15.60s | Fable, ~1.7x faster |
| AA Intelligence Index | 48 | 47 | Opus, by one point |
| Measured cost per task | $3.61 | $2.37 | Fable, ~34% less |
The tier labels do not describe throughput. Both models emit ~52 tokens/sec. The gap the tiers are pointing at is time to first token, which on a reasoning model is mostly thinking time — so it is set far more by effort than by which model you picked.
The full ladder, same source:
| Effort | Opus 5 TTFT | Opus 5 tok/s | Fable 5.1 TTFT | Fable 5.1 tok/s |
|---|---|---|---|---|
low | 2.37s | 52.6 | 6.04s | 52.3 |
medium | — | — | 9.65s | ~54 |
high (default both) | 17.45s | 52.1 | 23.85s | 56.0 |
xhigh | 29.99s | 50.3 | 107.33s | 60.2 |
max | 69.92s | 53.2 | 266.80s | 68.2 |
Read down the columns, not across the rows. Opus goes from 2.37s to 69.92s across its own effort range — a ~29x swing, dwarfing the model-to-model gap at any fixed effort. Two consequences:
- Like for like, Opus is genuinely the faster model, on every rung: 2.37 vs 6.04 at
low, 17.45 vs 23.85 athigh. That is what "Moderate" vs "Slower" is really claiming, and the measurement backs it. - But this doc's pairing is not like for like. At
highvslowthe effort gap more than cancels the model gap, and Fable 5.1 atlowis the faster of the two — first token in a third of the time, a 500-token answer in a bit over half. If you picked Opus here for latency, you picked wrong.
Throughput moves the other way and barely matters: Fable actually generates faster per token as effort rises (52 → 68 tok/s), which is swamped by TTFT going up 44x over the same range.
Two more things worth pricing in:
- Fable at
xhigh/maxis a different regime. 107s and 267s to first token — up to four and a half minutes of silence. This is the "hard tasks can run many minutes" warning as a number. Stream, and set timeouts in minutes, not seconds. - AA's cost-per-task independently reproduces §6's result. Fable at
lowcompleted its task set for $2.37 against Opus athighat $3.61 — the cheaper-per-token model costing more per finished task, measured by a third party on their workload rather than derived from list price.
One vendor's single-stream measurements, not Anthropic's, re-run over time — trust the leading digit, not the second decimal. AA counts thinking time inside TTFT, which is precisely why effort moves it so much; a "TTFT" that excluded thinking would look completely different. The Fable 5.1 rows are AA's "default fallback" variants. Its Intelligence Index is one composite score, not your eval. None of this replaces timing your own workload — it just shows the published tier words are too coarse to decide on.
5. Quality
5.1 What is actually measured
The one published head-to-head (Measured, coding subset, Fable 5 not 5.1, effort not stated):
| Model | Score | Cost |
|---|---|---|
| Claude Opus 5 | 91.7% | ~60% of Fable's |
| Claude Fable 5 | 91.3% | baseline |
On that subset both models largely saturate — Opus matched Fable at 60% of the cost. Saturation is the point: where a benchmark is near its ceiling, the cheaper model wins on cost and the capability gap is invisible.
Other measured anchors:
| Finding | Numbers |
|---|---|
Fable 5 at low beat Sonnet 5 on a deep-research benchmark | while costing ~10% less per task |
Run everything at low, re-run failures at default (coding) | ~93% pass at ~$0.70/task vs 91.7% at $1.39 all-default — same pass rate, half the cost |
Same, starting at medium | ~94% at ~$0.95/task |
| Prompt caching, agent loops | cut cost 2.5x–3.7x at 81–90% hit rates |
That third row is the most useful pattern in this doc, and it beats picking a single operating point at all — see §7.
5.2 What nobody publishes
There is no public SWE-bench / GPQA / AIME table comparing Opus 5 and Fable 5.1, and the models overview page carries no benchmark scores at all. I checked rather than guessed; any such figure you see quoted for this pair is not coming from Anthropic's docs.
The nearest thing to a public number is a third-party composite: Artificial Analysis scores Opus 5 at 40 /
48 / 50 / 51 across low/high/xhigh/max and Fable 5.1 at 47 / 49 / 51 / 53 / 53 across
low/medium/high/xhigh/max (Third-party, read 2026-09-08). Read it as a sanity check, not a verdict
— one composite index, one vendor's harness. It does put Fable's low (47) within a point of Opus's high
(48), and Fable's high (51) level with Opus's max (51), which is the same story the effort tables tell.
What the docs give instead is a decision rule, which is arguably more useful: use Fable when your own evals on Opus 5 at higher effort still fall short. The capability gap is real but workload-shaped, so the only number that settles it is one from your own eval set.
6. Worked cost example
One agent turn: 200K cached prefix, 5K fresh input, 3K output. All arithmetic from §2.1 list prices (Derived).
Step 1 — identical token counts, to isolate the price difference:
| Cache read | Fresh input | Output | Total | |
|---|---|---|---|---|
| Opus 5 | 200K x $0.50 = $0.100 | 5K x $5 = $0.025 | 3K x $25 = $0.075 | $0.200 |
| Fable 5.1 | 200K x $0.25 = $0.050 | 5K x $10 = $0.050 | 3K x $50 = $0.150 | $0.250 |
Fable is 1.25x, not 2x — the cheaper cache read absorbs most of the premium.
Step 2 — now apply low effort to Fable. Assumption: low cuts generated tokens to ~1/3 of high
(3K → 1K). Conservative next to the measured Opus coding curve, where low cost 0.25x of high. Not measured
for Fable 5.1 — sweep it yourself.
| Cache read | Fresh input | Output | Total | |
|---|---|---|---|---|
Opus 5 @ high | $0.100 | $0.025 | 3K x $25 = $0.075 | $0.200 |
Fable 5.1 @ low | $0.050 | $0.050 | 1K x $50 = $0.050 | $0.150 |
Fable 5.1 at low comes in under Opus 5 at high — about 25% cheaper on this shape, despite double the
list price. The cache read is halved and the 2x premium applies to only 1K of output instead of 3K.
Kill the cache and make it output-heavy — 5K input, 20K output,
no cache — and Opus at high is $0.525 against Fable at low $0.400 if low cuts output to a third
(7K). Weaken that assumption to a half (10K) and Fable is $0.550 — Opus wins. The whole result turns on an
unmeasured assumption. The lesson is not "Fable is cheaper": it is that list price does not predict the
ranking, and you have to price your own request shape with your own measured token counts.
7. How to choose
Do this in order. Most people stop at step 2.
- Cache first. Worth 2.5x–3.7x on agent loops (Measured) — more than any model or effort choice below it,
and it costs you no quality. Verify with
usage.cache_read_input_tokens; if it is zero across repeated requests you have a silent invalidator. - Sweep effort on Opus 5 before touching the model.
lowandmediumare unusually strong on Opus 5. Byte-identical requests, one variable, hard cases included. - Try the failure re-run pattern. Everything at
low, re-run failures at default. Measured at the same pass rate for half the cost. Needs a usable failure signal — tests, a checker, a validator. - Only then reach for Fable 5.1 — when steps 2–3 leave Opus short at higher effort. That is the documented trigger.
- If you do move to Fable, re-sweep effort from scratch. Effort curves are per-model and per-workload; Opus settings do not transfer.
Quick routing:
| Workload | Pick |
|---|---|
| Long-horizon agentic coding | Opus 5, sweep medium/high/xhigh — this is what it is built for |
| Research, knowledge, summarisation | Either at low/medium — the curve is flat, high effort is wasted money |
| Latency-sensitive / user-facing chat | Opus 5 at low — 2.37s to first token, the fastest measured cell in §4.2 — + the TTFT instruction. The lever is the effort, not the model |
| Deep multi-subtopic reasoning | Fable 5.1, higher effort — every step bought ~2.4 rubric points (Measured), no free cut |
| High-volume with checkable output | Neither — Haiku 4.5 at ~1/10 Opus cost (63% vs 92% accuracy) |
| Cache-heavy loop, big stable prefix | Price both. Fable's $0.25 cache read makes it far closer than 2x |
8. API differences that bite
These break code on migration.
| Opus 5 | Fable 5.1 | |
|---|---|---|
| Disable thinking | Accepted, but only at effort high or below (400 at xhigh/max) — and it causes tool calls to leak into visible text. Use low effort instead | Rejected — always on |
Forced tool use (tool_choice any/tool) | Works | 400. Use auto + an instruction naming the tool, or strict: true, or structured outputs |
| Thinking blocks | Echo back unchanged on the same model | Same, plus preserved thinking — editing earlier turns invalidates blocks; harness must be append-only |
| Zero data retention | Fine | Requires 30-day retention. ZDR orgs get a 400 unless expressly authorised |
| Task budgets | Supported | Confirm at launch |
budget_tokens | 400 on both — removed. Use output_config.effort | |
| Assistant prefill | 400 on both — removed |
Both support 1M context, 128K output, mid-conversation system messages, and per-message effort changes
(beta mid-conversation-output-config-2026-07-01) that avoid the cache reset a top-level effort change causes.
9. Bottom line
Opus 5 at high is the right default and the docs say so outright. Fable 5.1 at low is a real operating
point rather than a compromise — low on the newer model often beats xhigh on older ones, the halved
cache read means it is nowhere near 2x the cost on a cached agent loop, and third-party measurement puts it
ahead of Opus at high on latency rather than behind it. On the one published head-to-head Opus matched
Fable at ~60% of the cost, on a saturated benchmark.
Escalate on evidence: move to Fable when Opus at higher effort measurably falls short on your own eval set. Before you spend anything on the model choice, cache your prefix and sweep effort — those two are worth more than the decision this doc is about.
Disclaimer: These documents are personal notes. The information may be incomplete, out of date or wrong, so check it before you rely on it.