Fable 5.1 vs Opus 5 in Production: A Whole Day on Fable Used 19% of a Max Weekly Window

I ran Fable 5.1 as my agent harness’s main loop for a whole day on a Max plan, and it used 19% of the weekly window. The 5-hour window peaked at 59% and never capped. Same harness, same hooks, Opus 5 running alongside it: Fable made fewer bad tool calls per call and got blocked by my own gates more often, and at API list prices it would have cost 1.4 times Opus 5 per turn, not the 2 times the price list implies. That is the answer. This post is production telemetry from one operator on one day, not a benchmark comparison; the vendor pages and my Fable 5 vs Opus 4.8 post cover benchmarks.

TL;DR

The weekly window on my Max plan reset at 13:34 on 2026-09-04. From then to midnight the harness ran 2,443 Fable 5.1 turns and 1,120 Opus 5 turns, and the window read 19%. Over the full local day plus the sessions that spanned it, Fable 5.1 ran 4,501 turns across 29 sessions and Opus 5 ran 2,979 across 14. Fable produced 8.3 tool errors per 100 tool calls against 11.0, hit harness gates 2.9 times per 100 calls against 2.2, hit the context ceiling at the same rate per turn, and wrote 15% more output per turn. Opus 5 keeps the main-loop seat on API-equivalent cost; the plan-usage number says a Max subscriber can afford to test that rule.

How these numbers were measured

Two instruments.

Plan usage. Claude Code reports the 5-hour and 7-day window percentages to its status line on every turn. My status line writes each reading to a local file with a timestamp and the active model. That file is the source for every plan-usage figure here: 516 readings on 2026-09-04 and the following morning, read 2026-09-05. The percentages are plan-wide, so a reading taken during a Fable turn still includes whatever the Opus 5 sessions consumed. I cannot split points per model from this instrument, so I pair each reading with the turn counts from the second instrument instead.

Transcripts. A 200-line Python script (standard library only) reads every Claude Code transcript file under ~/.claude/projects/ modified since 2026-09-04 00:00 Pacific, run on 2026-09-05. Every assistant turn carries the model ID and a usage block with input, output, cache-write, and cache-read token counts, so per-model totals need no estimation. Sessions that started before midnight count in full, and a few sessions were still open when the script ran, so “one day” means “the local day plus the sessions that spanned it”.

Definitions, because each count depends on one:

• A tool error is any tool result the transcript flags as an error, from a failed command to a permission refusal. It includes environment failures, so it is an upper bound on model mistakes.
• A hook block is a tool error whose text names a hook or gate. My harness has hooks that refuse writes outside a task’s declared boundary, refuse dangerous shell operations, and refuse a done-claim with no artifact behind it.
• A classifier denial is Claude Code’s own permission classifier declining an action in auto mode.
• A compaction is a system row recording that the context window was summarized.
• An operator correction is a regex hit on my own turns for words like “no”, “wrong”, “again”, “instead”. It is a rough count and I label it as such below.

API-equivalent cost is computed at list prices from the Claude API pricing page, read 2026-09-05: Fable 5.1 at $10 input, $50 output, $12.50 per five-minute cache write, $0.25 cache read per million tokens; Opus 5 at $5, $25, $6.25, $0.50. I am on a Max plan, so these figures are what the day would have cost on the API, not what I paid.

Task mix: both models ran real work from my backlog, but not the same work. My standing routing rule sends single hard diffs to Fable and everything else to Opus 5; on this day Fable ran most of the long interactive sessions, which is the reverse of the rule. The comparison is same harness, overlapping task mix, not a controlled trial. One operator, one day, no daily series yet.

A whole day on Fable 5.1 used 19% of the weekly window and never capped the 5-hour window

reading (Pacific)	5-hour window	7-day window	model on the active turn
09-04 13:34 (weekly reset)	2%	0%	Fable 5.1
09-04 15:27	17%	3%	Fable 5.1
09-04 16:53	39%	7%	Fable 5.1
09-04 17:44 (5-hour peak)	58%	11%	Fable 5.1
09-04 20:07	2%	12%	Fable 5.1
09-04 22:44	33%	17%	Fable 5.1
09-05 00:02	8%	19%	Fable 5.1
09-05 07:12	7%	24%	Fable 5.1

Status-line rate-limit readings, 2026-09-04 13:34 to 2026-09-05 07:12, read 2026-09-05. Peak 5-hour reading across all 516 rows: 59%.

Turns behind those points, from the transcripts: reset to midnight, 2,443 Fable 5.1 turns (283 million cache-read tokens, 2.6 million output tokens) and 1,120 Opus 5 turns (112 million cache-read, 1.1 million output). Reset to 07:12, 3,017 Fable turns and the same 1,120 Opus turns. Sonnet 5, Haiku 4.5, and Opus 4.8 ran fewer than 70 turns each as hook workers and are inside the percentages too.

Two things this settles for a Max subscriber. First, the 5-hour window is the one you feel during the day, and running Fable 5.1 as the main loop with a harness that keeps context tight left it under 60% at peak; it drained back to single digits twice while I kept working. Second, a full working day plus an overnight of Fable-heavy sessions cost under a quarter of the week. Before the reset, the same plan stood at 62% for the previous week, which had a similar mix. I had expected Fable 5.1 to draw the plan down faster than that, because Fable 5 did: when it launched in June, Fable 5 usage was capped at half the weekly limit and drained visibly faster than Opus 4.8 on the same plan. That expectation did not survive the day.

One boundary. The percentages are plan-wide, so I cannot state Fable’s share of the 19 points. Fable was 69% of the turns and about 72% of the cache-read tokens in that span, which is the closest I can get; a model-weighted split would need Anthropic’s rate-limit weighting, which is not published.

Fable 5.1 errored less per tool call and got blocked more

per 100 tool calls	Fable 5.1 (2,384 calls)	Opus 5 (1,256 calls)
Tool errors	8.3 (197)	11.0 (138)
Harness hook blocks	2.9 (70)	2.2 (28)
Classifier denials (count)	19	8

Claude Code transcripts, local day 2026-09-04, read 2026-09-05.

Read the two rows together. Fewer tool errors means fewer malformed commands, wrong paths, and failed edits per call. More hook blocks and denials means Fable tried more things the harness is built to refuse: writes outside the declared task boundary, shell operations on the blocked list, actions the permission classifier judged out of scope. The gates worked in every case, which is the point of having them. What I cannot tell from one day is whether the extra pushback is Fable reading the task more ambitiously or reading the boundary less carefully. If your harness has hard gates, expect Fable 5.1 to hit them; if it does not, the error-rate row is the one that matters.

Both models hit the context ceiling at the same rate

Fable 5.1 compacted 43 times over 4,501 turns and Opus 5 compacted 30 times over 2,979, which is 0.96 and 1.01 per 100 turns. Cache-read tokens per turn were within 3% (116,873 against 113,957). There is no context-management reason to pick one model over the other in this harness, and the context management post covers what actually moves the compaction rate.

On the API the same day would have been 1.4x per turn, not 2x

	Fable 5.1	Opus 5
Sessions (as main model)	29	14
Assistant turns	4,501	2,979
Cache-read tokens per turn	116,873	113,957
Output tokens per turn	1,126	980
API-equivalent cost	$758	$359
Cost per turn	$0.168	$0.121

Claude Code transcripts priced at list, local day 2026-09-04, read 2026-09-05. Not a bill.

This section is for readers paying per token. An agent’s bill is mostly re-reading its own context, and cache-read tokens per turn were within 3% between the two models, so the behaviour that drives cost was the same. What differed was price, and the price that matters most is the cache-read rate: Fable 5.1 reads its cache at $0.25 per million tokens, a quarter of Opus 5’s $0.50 and a 75% cut from Fable 5. At that rate cache reads were 17% of Fable’s day; cache writes were the largest line at $371, then output at $253. Opus 5’s day split the other way: cache reads $170, cache writes $117, output $73.

Two boundaries on the number. The pricing page lists a one-hour cache tier at double the write price; if Claude Code uses that tier the day comes to about $980 against $429, and the ratio moves from 1.4x to 1.5x. And the sticker ratio on input and output is still exactly 2x, so a workload with small contexts and long outputs will see closer to 2x. Multiply your own cache-read share before you decide.

Fable 5.1 wrote 15% more output per turn, the opposite of the lab result

Fable 5.1 averaged 1,126 output tokens per assistant turn against Opus 5’s 980. Anthropic’s launch post quotes a coding partner seeing Fable 5.1 use half as many tokens as Opus 5, and Snorkel’s evaluation reports 58% fewer output tokens with 36% lower wall-clock. I am not disputing those results. My harness enforces terse output and runs interactive sessions where most turns are one tool call with a short note, so the room for a shorter answer is small, and Fable 5.1 defaults to High effort in Claude Code where Opus 5 runs at its own default. Token efficiency looks workload-dependent, which means it is something to measure on your own transcripts rather than take from anyone’s evaluation, including this one.

What I pushed back on, per model

My own correction turns, counted by regex and therefore a rough number, came to 29 on Fable 5.1 and 19 on Opus 5, which is 0.64 per 100 turns on both. No difference. Separately, an output validator that flags any number in an assistant message that no tool produced scanned 223 claims across both models in the window and flagged 9. That count is not split by model in the current instrument; the hook events post explains the mechanism.

The routing rule after the day

Opus 5 keeps the main-loop seat, on a narrower argument than before. The API-equivalent gap narrowed from the 2x I assumed when I wrote the first version of this post to 1.4x measured, and the plan-usage number removed the argument I had actually been running on, which was that Fable would eat the week. It did not. What is left for Opus 5 is that the day produced no evidence Fable 5.1 finished tasks in fewer turns; it ran longer sessions with more turns each.

Fable 5.1 keeps its reservation: a single hard code diff that is novel, expensive if wrong, judgment-heavy rather than volume-heavy, and shaped like one change rather than a long run. The one number that argues for widening that reservation is the tool-error rate, 8.3 against 11.0 per 100 calls. If that holds over a week, and the weekly window stays under a quarter per Fable day, the four-condition gate gets a fifth clause for long agentic runs where each error costs a retry. One day is not a week.

Where the “Opus 5 regression” question belongs: it is a different query with a different answer, and the how to use Claude Opus 5 post carries the regression worker and the failure replay list. Nothing in this day’s telemetry contradicts it.

How the original routing call was made

The rest of this post is the routing history from the first version, kept because the queries that found this page still ask about Fable 5 rather than 5.1, and because the tiebreaker logic has not changed.

Opus 5 became my harness’s main-loop default on 2026-07-24, superseding a Fable 5 default that had held the seat since July 8. My routing notes put Opus 5 ahead or tied with Fable 5 on 9 of 13 shared benchmarks, at $5 input and $25 output per million tokens against Fable’s $10 and $50. Fable 5 kept its seat on two benchmarks in my doctrine, SWE-bench Pro (80.0 against 79.2) and DeepSWE (69.7 against 68.8), both tied to single hard code diffs. The tiebreaker in my harness is intelligence, then taste, then cost, in that order; the two models tied on the first two axes, so cost decided the seat. Fable 5.1 inherited the reservation when it shipped, and the telemetry above is the first time I have had numbers from the new pairing rather than from the release notes.

The behaviour deltas in Opus 5 that the first version listed still hold in my harness: it self-verifies without being asked, it over-delegates to subagents, its output length does not shorten with the effort setting, it expands scope when unconstrained, and thinking defaults on when the parameter is omitted from an API call. Guardrails tuned for Opus 4.8 point the wrong way on Opus 5.

Reproduce it on your own transcripts

The plan-usage half needs nothing but a status line that writes the rate-limit percentages Claude Code already hands it to a file with a timestamp; mine is a few lines of shell. The transcript half is a script that reads local transcript files, computes per-model turns, token usage, tool errors, hook blocks, compactions, and list-price cost, and writes a Markdown dossier. It sends nothing anywhere. It currently lives in my private harness repository with operator-specific paths baked in; I will publish a cleaned copy with the seven-day rerun, and until then the definitions above are enough to rebuild it in an afternoon (the transcript files are newline-delimited JSON, and each assistant row carries message.model and message.usage). The first thing to do with the output is the thing I have not yet done: run it over seven days and look at the series, not the total.

Corrections

2026-09-05: the first computation of this day priced Fable 5.1 cache reads at 10% of the input rate, the multiplier every other model uses, and put the API-equivalent day at $1,115. The pricing page lists Fable 5.1 cache reads at 2.5% of input ($0.25 per million tokens). The corrected figure is $758, and the per-turn ratio moved from about 3x to 1.4x. The correction is in the tables above; the wrong number is recorded here so the drift is visible.

What to do next

If you are on a Max plan, write the rate-limit percentages to a file today and read them after your next Fable-heavy day; the weekly number is the one that decides whether the routing question is even open for you. If you pay per token, run the transcript script over your last week and read the cache-read share first, because it decides whether the price gap you will see is 1.4x or 2x. Then read the error and gate rows together, because a model that errors less and gets blocked more is a different operating profile from one that does either alone. My rule flipped in sixteen days last time. This time it held, on one number, for one day.

Sources

• Introducing Claude Fable 5.1 and Mythos 5.1 (Anthropic, September 2026; the source for the cache-read price cut, the High effort default in Claude Code, and the partner token-efficiency quotes)
• Claude API pricing (Anthropic, read 2026-09-05; Fable 5.1 cache hits at 0.025x base input, all other models at 0.1x)
• Introducing Claude Opus 5 (Anthropic, July 24, 2026)
• Introducing Claude Fable 5 and Mythos 5 (Anthropic, June 9, 2026)
• Claude Code status-line rate-limit readings and transcript files under ~/.claude/, 2026-09-04 to the morning of 2026-09-05, read 2026-09-05 with the instruments described above; the SWE-bench Pro, DeepSWE, and 9-of-13 figures in the routing history are from my internal routing notes, not a public leaderboard