Field notes ยท from three hands-on evals
Saving money with Fable 5
Fable 5 is the most capable Claude model - and, as a manager, still the priciest way to burn a Claude subscription. Three hands-on evals (a solo-vs-delegation orchestration test at n=2, a coding-subagent shootout, and a difficulty/domain follow-up) found exactly one place it wins outright - as a worker on open-ended, exploratory tasks - and confirm it loses everywhere else measured. Takeaways first, evidence below.
Six Opus 5 cells were added across the orchestration and difficulty/domain evals. Headline: Opus 5 has the lowest per-token rates on this page but is the most volume-hungry model measured, so it costs more than Opus 4.8 in both roles where the two ran head to head. The newest model is not automatically the cheapest.
Separately, a bug in the S-Log3 objective checker has been fixed. It had produced a false "all models fail identically" result that this page reported as a model finding for several weeks. All four cells actually pass. Full correction in Evidence 3.
Same feature. Same workers. Different manager.
Claude spend to manage one real coding task through the same pool of cheap workers, across effort levels
*Bars for the two Opus rows show the midpoint of their range, since a single-length bar can't draw a range; the labels give the actual span. Both Opus rows are two runs of the same configuration, not two settings. In one run of each pair the eval script passed --effort high explicitly; in the other it passed no --effort flag at all - and Anthropic's docs state that omitting the parameter is equivalent to high on both models. So these ranges measure run-to-run variance, not an effort discount: $2.13–4.74 for Opus 4.8 (a 2.2x spread) and $3.59–4.56 for Opus 5 (1.3x). Do not read the low end of either range as a setting you can choose. Opus 4.8's cheap run got there by burning 2.9x fewer total tokens (1.34M vs 3.88M) while its per-token rate was actually higher ($1.59/1M vs $1.22/1M) - it simply did less work that time. This is also the main reason every n=1 figure on this page is labelled as directional.
Sonnet 5 manages, high effort ($3.29, 1066s): same flat prompt, same external gpt/glm worker pool as every other bar on this chart - unlike the Sonnet-manager-with-Sonnet-workers confound check further down, this run isolates the manager-model swap alone. Fidelity held at 5 (median, 3 samples × 2 judges), same as every other cell.
All numbers from the three eval reports summarized below; small sample sizes throughout (n=1–3 per cell, except the orchestration eval's fidelity scores at 3 samples × 2 judges per cell).
Six ways to spend less
-
1
Don't make Fable 5 your manager, at any effort level. Every other Claude model measured does the same job for less.
Fable runs a per-token rate tax, not a volume tax: it blends to $1.9–2.7 per million tokens regardless of effort, while Opus blends to $0.86–1.6 per million. Fable-low-effort even used fewer total tokens than Opus-4.8-high-effort and still cost more, because its rate stayed ~1.8x higher. Swapping the manager took the bill from $6.08–$6.76 down to $2.13–$4.74 with Opus 4.8, $3.59–$4.56 with Opus 5, and $3.29 with Sonnet 5 - every quality check still passing. Each Opus range spans two runs of one configuration, so read them as bands, not settings.
One catch on the newest option: Opus 5 is the slowest manager measured (1347s on its high-effort run, against 904–1066s for Opus 4.8 and Sonnet 5). It buys you savings against Fable and costs you wall clock against the others.
-
2
Want your Claude plan to last longer? Hand the heavy work to cheaper models.
With flat delegation, the workers did the grinding (over a million input tokens of it) on GPT and GLM plans. The Claude plan only paid for managing: about a third of the solo run's burn. The trade-off is time - the job took 50–70% longer.
-
3
In a hurry on a small task? Let one model just do it - but make it Opus 4.8 specifically.
Opus 4.8 working alone finished ~40% faster than flat delegation and ~55% faster than nested, even though the delegated runs used several workers at once. A Fable-solo baseline closes the loop: at 852s and $12.77, Fable alone was slower than every delegated shape and 2.4–2.7x pricier than Opus 4.8 solo - the single most expensive cell measured across either eval.
Opus 5 does not inherit this win, and that's the sharpest "newer isn't cheaper" result on the page. Solo Opus 5 took 877s and cost $6.73: 43% slower and 36% pricier than solo Opus 4.8, and slower than three of the flat delegated cells. Its per-token rate was actually the lowest of any solo cell ($0.775/1M vs $0.78–0.81) - it just spent 8.68M tokens over 101 turns against ~6M and ~80 turns, consistent with Anthropic describing Opus 5 as more thorough and more inclined to verify its own work. So this one is version-specific now: go solo with Opus 4.8, not Opus 5 and not Fable.
-
4
Skip nested orchestration - confirmed on a second run.
A repeat nested run landed close to the first on cost ($7.86 vs $7.87), with a narrower but still real wall-clock gap versus flat delegation. Nested still wins under no objective measured: most expensive or tied for it, slowest or tied for it, highest management-token burn, and the one verified second-hop bug (a worker with no project context hardcoded its sandbox path into a committed test). Fidelity was not actually lower, once re-judged with a proper rubric - see point 5 below.
-
5
Pick workers by task type, not one favorite model.
- Opus 4.8 — most reliable end-to-end executor (9/9 commits), and cheapest on a tightly-scoped hard algorithmic task ($0.75 vs Fable's $1.04–1.33).
- GPT 5.5 — best all-round on judged quality and code review, but its sandbox can't commit in git worktrees - the orchestrator must commit for it.
- GLM 5.2 — won the API-design taste task 3/3 against pricier models, with one catastrophic lazy run in nine - verify its output.
- New wrinkle — on an open-ended design task, Opus 4.8 explored 2.3x more tokens than Fable and its lower rate wasn't enough to offset that volume - Fable-high came in cheaper in dollars there, the first time Fable-as-worker beat Opus on price.
- Opus 5 — lowest per-token rates measured anywhere here ($0.73–1.66/1M) and correct on both hard tasks, but the most volume-hungry model measured by a wide margin, so route it by how tightly scoped the task is. On the narrow hard task the volume stayed in check and it was near-cheapest ($0.79 vs Opus 4.8's $0.75). On the open-ended design brief it ran to 7.95M tokens - 16x Fable-high - for $5.78, the priciest worker cell on this page, and scored the lowest taste (3.5). Prefer it where "done" is well defined; avoid it where the brief is vague and cost matters.
- Sonnet 5 — run as manager on the same hero-chart task with the original gpt/glm worker pool: $3.29, 1066s, cheaper than both Fable ($6.42) and Opus-high ($4.74), and the lowest $/1M-token rate measured ($0.61). Also run as both worker and manager in a follow-up confound check (same task, worker pool fixed to Sonnet 5 so cross-vendor overhead can't explain the gap) - as manager there too, Sonnet undercut both Fable and Opus on cost and wall clock. As a plain worker riding a Claude manager, it's the priciest total-Claude-spend combination measured, because - unlike GPT/GLM - its token grind lands on the same Claude plan as the manager. Fidelity held at 5 across every Sonnet cell. See the hero chart above and the confound-check chart below.
- Queued — Grok 4.5 hasn't been run as a worker in either eval yet.
-
6
Don't trust a quality score based on one AI reading a diff once - and don't trust your "objective" checker either.
"Fidelity" here just means how closely the finished code matched the spec, scored 1-5. The first check graded each diff a single time and found delegated work scoring a point lower than solo work - looked like a real cost of delegating. A slower re-check (three separate readings per diff, by two different AI judges, using a fixed checklist instead of open judgment) found no difference at all: solo, flat, and nested all landed at the same top score across all ten cells. The lesson generalizes beyond this eval - a single AI grading pass is noisy; get it re-checked multiple times before trusting a quality score.
The sharper version of this bit us in the other direction. Our S-Log3 "objective" checker - deterministic code, no LLM judgment anywhere - was itself wrong, and we published its verdict as a model finding for weeks (see the correction in Evidence 3). A hand-written checker is a hypothesis too. The tell was that every model failed with a byte-identical wrong value: when that happens, verify the expected constant against an independent implementation before concluding anything about the models. Also check that a checker's own assertions are mutually consistent - ours asserted a value at a point its own continuity test proved could not hold it.
The evidence
"Solo," "flat," and "nested" are three ways of getting the same coding task done. The same real feature was built under each shape and measured on time, cost, and quality.
One strong Claude model works alone: reads the spec, writes the code, runs the tests, commits.
A Claude manager (Fable 5 or Opus) splits the task and hands pieces directly to cheaper workers on other subscriptions, then integrates and verifies.
Fable 5 delegates to Opus middle managers, who delegate to workers. Two hops between the spec and the code.
The workers throughout: GPT 5.5 (via codex, on a ChatGPT plan) and GLM 5.2 (via opencode, on a Z.AI plan) - so their token grind lands on those subscriptions, not the Claude plan.
One real feature (a preset pack/unpack command plus UI) was built under each orchestration shape, from frozen prompts in isolated git worktrees, with identical acceptance checks: the test suite, a typecheck, a byte-identical CLI round trip, and a UI render check. Every cell across ten runs passed all four. Fidelity was re-collected with a rubric-anchored method (3 samples × 2 judge models per diff, with two contested spec checks scored objectively by code inspection instead of judge opinion) after the original single-sample judging proved noisy. Solo (Opus 4.8) ran twice, solo Fable once, solo Opus 5 once, Fable-managed flat twice at high effort and once at low, Opus-4.8-managed flat twice at high effort (once with the flag explicit, once relying on the default), Opus-5-managed flat twice on the same basis, Sonnet-5-managed flat once at high effort with the same original gpt/glm worker pool, and nested twice. The three Opus 5 cells were added on Aug 5, 2026 and carry acceptance results but no rubric fidelity re-judge, so they are marked "not judged" below rather than assigned a score. A follow-up confound check reran the same flat task with the worker pool fixed to claude-sonnet-5 (via the Agent tool) under three different managers - Fable, Opus, and Sonnet 5 itself, all at high effort - isolating manager-model cost from cross-vendor delegation overhead.
Wall clock
Seconds to complete the feature, lower is better
Every delegated shape ran workers concurrently and still lost to Opus 4.8 working alone - overhead beat parallelism at this task size. Solo alone doesn't guarantee a win, though: Fable-solo and Opus 5-solo were both slower than several delegated shapes. Opus 5 is the slowest manager measured at high effort (1347s) and among the faster ones with no effort flag (868s) - the same configuration on paper, since Opus 5 defaults to high effort, which puts a floor under how much of this chart is run-to-run noise.
Claude cost, management layer
Dollars of Claude usage; workers ride other plans, so this is not a total-system claim
Managing the worker pool still costs less than doing the work yourself at the same model's prices, for every Claude manager measured. Fable solo remains the single most expensive cell. The newest model does not automatically move you down this chart: Opus 5 solo ($6.73) is the second-priciest cell here and 36% above Opus 4.8 solo, while Opus 5 as manager ($3.59–4.56) lands between Sonnet 5 and Opus 4.8-high.
Effective rate
Dollars per million total tokens (incl. cache) - shows the tax is per-token, not per-task-volume
Fable blends to $1.9–2.7/1M tokens regardless of effort; Opus blends to $0.78–1.6/1M, and Opus 5 sits at the bottom of that band in every role it ran. It's a rate tax, not a volume tax. But note what this chart can't tell you: Opus 5 has the best rate of any Opus cell here and still produced the second-priciest bill on the cost chart above. Rate only sets the price per token - the model decides how many to spend.
Confound check: manager model, worker pool held fixed
Same flat-delegation task, workers fixed to claude-sonnet-5 (via the Agent tool) so cross-vendor overhead can't explain the gap - total Claude-side spend, n=1 each
With external (GPT/GLM) workers, Fable-manager cost $6.42 because the worker grind rode other subscriptions. Swap those workers for Sonnet 5 and Fable-manager jumps to $9.65 - the workers' cost now lands on the same Claude plan as the manager. Sonnet-as-manager was also fastest (720s vs 855s Fable, 871s Opus) and cheapest per token ($0.64/1M vs Opus's $0.88/1M and Fable's $1.39/1M in this same-vendor stack). Fidelity held at 5/5 (median) for all three, rejudged the same rubric-anchored way as every other cell.
Show the full data table
| Cell | Wall clock | Claude cost (mgmt) | Workers | Fidelity (rejudge median, 1–5) |
|---|---|---|---|---|
| Solo (Opus 4.8, high effort (default), avg of 2) | 614s | $4.96 | none | 5 |
| Solo (Fable, high effort, n=1) | 852s | $12.77 | none | 5 |
| Flat (Fable manager, avg of 2, high effort) | 1044s | $6.42 | 2 gpt + 2 glm | 5 |
| Flat (Fable manager, low effort, n=1) | 1276s | $5.27 | 3 gpt + 3 glm | 5 |
| Flat (Opus 4.8 manager, high effort - default, no flag, n=1) | 904s | $2.13 | 2 gpt + 2 glm | 5 |
| Flat (Opus 4.8 manager, high effort - explicit, n=1) | 1057s | $4.74 | 2 gpt + 2 glm | 5 |
| Solo (Opus 5, high effort - default, n=1) | 877s | $6.73 | none | not judged |
| Flat (Opus 5 manager, high effort - default, no flag, n=1) | 868s | $3.59 | 5 gpt + 1 glm | not judged |
| Flat (Opus 5 manager, high effort - explicit, n=1) | 1347s | $4.56 | 2 gpt + 4 glm | not judged |
| Flat (Sonnet 5 manager, high effort, n=1) | 1066s | $3.29 | 1 gpt + 4 glm | 5 |
| Nested (Fable --effort high → Opus x2, no effort flag, avg of 2) | 1207s | $7.87 | 1–7 gpt/glm mix | 5 |
| Flat (Fable manager, high effort, n=1) — Sonnet 5 workers | 855s | $9.65 | 4 sonnet-5 | 5 |
| Flat (Opus manager, high effort, n=1) — Sonnet 5 workers | 871s | $5.37 | 4 sonnet-5 | 5 |
| Flat (Sonnet 5 manager, high effort, n=1) — Sonnet 5 workers | 720s | $4.59 | 4 sonnet-5 | 5 |
Plan burn per cell (all Claude layers): solo Opus ~80 turns / ~6.1M cache reads / ~39k output; solo Fable ~6.3M / ~43k; Fable-flat high ~44 turns / ~2.3M / ~30k; Fable-flat low ~2.25M / ~17.4k; Opus-flat, no effort flag, 31 turns / 1.2M / 22k; Opus-flat high ~3.63M / ~35.9k; nested avg ~26 turns / ~4.1M / ~72k; Fable/Opus/Sonnet-manager-with-Sonnet-workers cells ~6.1–7.1M combined tokens each, all high effort.
The three Sonnet-worker cells above are a separate confound check (see the "Confound check" chart), not directly comparable to the GPT/GLM-worker rows on Claude cost - their worker spend rides the same Claude plan as the manager, while GPT/GLM workers ride other subscriptions entirely.
The original blind judge (one sample per diff) scored solo 5/5 and every delegated run 4, but reading the diffs directly found the same two deviations (non-atomic unpack, no export-set selector) present in the solo runs too - just unflagged. A follow-up re-judge (3 samples × 2 judge models per diff, those two checks scored by code inspection instead of judge opinion) confirmed it: all ten cells land at median 5. Nothing was "lost in the delegation telephone game" except one verified nested-only defect - a worker with no project context hardcoded its sandbox path into a committed test, which the rubric's granularity doesn't register as a fidelity-score difference. Nested and both Opus-manager cells remain n=1–2, so treat magnitudes as provisional.
Cells labelled "default, no flag" never had --effort passed at all (solo Opus 4.8, one Opus 4.8-manager run, one Opus 5-manager run, solo Opus 5, and the nested run's Opus secondmates). This is not a lower effort tier. Anthropic's documentation states that omitting the effort parameter produces exactly the same behavior as setting it to high, on Opus 4.8 and Opus 5 alike - so each "default" run and its explicit --effort high twin were running the same nominal configuration.
That makes those two pairs the most useful noise measurement on this page, because the only thing separating each pair is the run itself. Opus 4.8: $2.13 vs $4.74, a 2.2x spread. Opus 5: $3.59 vs $4.56, 1.3x. The token accounting confirms the mechanism rather than an effort discount - Opus 4.8's $4.74 run had the lower per-token rate ($1.22/1M vs $1.59/1M) and cost more only because it burned 2.9x more total tokens (3.88M vs 1.34M, mostly cache reads from more turns). It simply did more work that time.
Two consequences. First, don't read the cheap end of either range as a setting you can reach for. Second, a 2.2x spread within one configuration is wider than most of the between-model gaps this page reports, so every n=1 comparison here should be read as directional only - which is why the effort-level conclusions rest on the per-token rate columns, where the pattern is stable, rather than on single-run dollar totals.
Four models ran as coding subagents, each inside its own vendor's agent CLI - GLM 5.2 (opencode), GPT 5.5 (codex), Opus 4.8 (Claude CLI), Composer 2.5 (cursor-agent) - across four tasks: a treacherous test-runner migration, a fuzzy-spec feature, a code review with seven seeded bugs, and an API-design taste task. Three runs per cell, frozen identical prompts, isolated worktrees pinned to fixed commits, blind scoring by two judges (Fable 5 and GPT 5.5). Note this compares model+harness pairs, not pure models - which is how subagents are consumed in practice.
| Task | GLM 5.2 | GPT 5.5 | Opus 4.8 |
|---|---|---|---|
| Migration - judge median (1–5) | 3.00 | 4.00 | 3.67 |
| Migration - tests green | 2/3 | 2/3 | 3/3 |
| Fuzzy spec - judge | 4.08 | 4.17 | 3.54 |
| Review - recall of 7 seeded bugs | 4 | 5 | 4 |
| API taste - judge | 4.25 | 3.62 | 3.62 |
| Commits made | 7/9 | 0/9 harness | 9/9 |
| Median wall clock, edit tasks | 327s | 223s | 246s |
Judge score = mean of 3–4 rubric dimensions averaged over two judges. GPT's 0/9 commits is a codex sandbox limitation (it can't write git metadata in worktrees), not model behavior. All lanes ran on flat subscriptions, so the meaningful cost metric is plan burn - Opus produced 2.2–2.5x the output tokens of the others (thinking included), the main driver of its subscription burn.
Composer 2.5 also ran but was halted at half its runs when the Cursor plan hit its cap ($19.77 of $20) - too little data to rank. What exists: it failed the migration in both attempts and never committed by choice, but posted the best single code-review run (6/7 bugs) and tied-best on taste, each at n=1.
The Opus lane ran with contaminated context: the user's "shortest working diff wins" plugin hooks fired inside every cell, and no other lane carried an equivalent directive - direction of bias unknowable. The two judges also disagreed systematically: the GPT 5.5 judge marked Opus-authored artifacts down 2–3 points in four separate sets. Treat merged judge scores as approximate.
A follow-up eval ran solo Fable (high and low effort) and solo Opus (high effort) on two new tasks: a genuinely hard, narrowly-scoped algorithmic problem (implement a closed-form curve inverse, graded by an independent numerical checker for round-trip identity, monotonicity, and domain clamping) and an open-ended visual-design task (redesign a debug UI page, graded by acceptance checks plus a blind taste judge, 2 samples). n=1 per cell - a first pass to check direction, not yet at the n=2 bar the orchestration eval uses. A second, structurally different hard task was added later: implement a real-world camera-log curve (Sony S-Log3's exact reverse-OETF formula) into an existing LUT-profile pipeline, with an independent objective checker (not the agent's own tests) verifying the mid-gray value at code value 420, the value where the two branches meet, the black point, branch continuity, and monotonicity. That checker had a bug in its mid-gray constant, corrected on Aug 5, 2026 - see the correction below.
| Cell | Cost | $/1M tokens | Objective check | Taste (median of 2) |
|---|---|---|---|---|
| Hard task, Fable high | $1.04 | $2.97 | PASS | - |
| Hard task, Fable low | $1.33 | $3.26 | PASS | - |
| Hard task, Opus 4.8 high | $0.75 | $2.02 | PASS | - |
| Hard task, Opus 5 high | $0.79 | $1.66 | PASS | - |
| Design task, Fable high | $1.60 | $3.31 | pass | 4.5 |
| Design task, Fable low | $1.12 | $3.19 | pass | 4.5 |
| Design task, Opus 4.8 high | $1.96 | $1.78 | pass | 4.0 |
| Design task, Opus 5 high | $5.78 | $0.73 | pass | 3.5 |
The rate tax holds on both tasks (Fable $2.97–3.31/1M vs Opus $0.73–2.02/1M, wider than the manager-role gap) and doesn't move with effort. But total cost is volume × rate: on the hard task Opus 4.8's exploration stayed close to Fable's (372k vs 349k total tokens) so its rate advantage held and it was cheapest overall. On the design task Opus 4.8 explored ~2.3x more (1.10M vs 482k tokens), and that volume outweighed its rate advantage - Fable-high ended up cheaper in dollars, the first cell in either eval where Fable-as-worker beat Opus on price.
Opus 5 pushes that volume effect to an extreme, and it is the clearest new result on this page. On the design task it recorded the lowest blended rate of any cell in either eval ($0.73/1M) and still spent the most of any worker cell ($5.78) - because it explored 7.95M total tokens against Fable-high's 482k, roughly 16x. It also took 807s against 103–229s for the other three, and scored the lowest taste of the four (3.5). Cheapest per token, most expensive per task, slowest, and worst-judged, all in the same cell. A per-token price list tells you almost nothing about what a model will cost you on open-ended work.
Taste still shows no clear winner among the Fable and Opus 4.8 cells, and n=1 with 2 judge samples is far too little signal to rank them - but the ordering now runs opposite to spend across all four cells (3.5 at $5.78, 4.0 at $1.96, 4.5 at $1.12–1.60). More exploration did not buy better design judgment in any cell measured. Fable-low wasn't a reliable win on the hard task either - it used more tokens than Fable-high despite lower effort and cost the most of the three. One shared gap: none of the design-task diffs added the tests the spec asked for - the same uniform under-implementation pattern seen in the orchestration eval's contested checks.
Every cell here is n=1, one design-taste judge model at 2 samples, and the objective hard-task checker doesn't verify that the implementation avoided numerical root-finding as the spec asked (a closed-form-vs-iterative distinction that would need a manual code read).
The Opus 5 cells were added Aug 5, 2026. On the design task its two taste samples split 3 and 4, so the 3.5 median rests on a judge disagreement rather than a consensus - worth keeping in mind before reading the taste ordering as settled. Its cost and volume figures are not judge-dependent and are the more solid part of that result.
This section is also where our one retracted claim lived: the S-Log3 "all models fail" result was a bug in our checker, not a model finding. Corrected above.
Second hard task: a real-world camera-log curve
| Cell | Cost | $/1M tokens | Wall clock | Objective check |
|---|---|---|---|---|
| S-Log3 curve, Fable high | $1.94 | $2.77 | 203s | PASS |
| S-Log3 curve, Fable low | $2.01 | $2.98 | 181s | PASS |
| S-Log3 curve, Opus 4.8 high | $1.06 | $1.58 | 128s | PASS |
| S-Log3 curve, Opus 5 high | $1.21 | $1.23 | 205s | PASS |
The familiar cost pattern repeats - Fable's rate premium showing up regardless of effort, and Opus 5 posting the lowest blended rate of the four at $1.23/1M - though Opus 4.8 is still the cheapest and fastest in absolute terms. All four cells pass the objective checker.
The earlier writeup said all three returned "the exact same wrong number" (0.01125 instead of ~0.18) at the branch pivot, and attributed it to every model writing the boundary as > instead of >=. Re-checking the harness against Sony's published formula, the diagnosis was backwards and the models were right.
Our checker conflated two different code values. In the S-Log3 reverse OETF, 10^((cv-420)/261.5) reaches 10^0 - and so linear 0.18 - only at code value 420. The checker asserted 0.18 at the branch break instead (code value 171.2102946929), where the correct value on both branches is 0.01125. An independent reimplementation of Sony's formula returns 0.011250000000007374 at the break: byte-identical to what every model produced.
That trailing float is itself the proof. The lower branch returns exactly 0.01125; only the upper branch produces the ...007374 rounding artifact. So the models had evaluated the upper branch - they used >= and took the path the spec asked for, the exact opposite of what we published.
The contradiction was visible in our own output the whole time: the checker's continuity test passed on every cell, and a function cannot be continuous at the break while also jumping to 0.18 there. With the constant corrected, all four cells pass every check - black point, branch continuity, monotonicity, and plumbing included. No model-behaviour conclusion on this page ever rested on the retracted claim, and the cost and speed figures are unaffected.
So where does Fable 5 fit?
Everywhere above, Fable loses on cost, speed, or both. Two things it's actually shown, with evidence:
-
1
It's cheaper on open-ended, exploratory work - because the alternative overspends.
Fable's per-token rate is still higher than Opus's everywhere measured. But on a design task with no tight spec to anchor to, Opus 4.8 explored ~2.3x more tokens (1.10M vs 482k) chasing the open-ended brief, and that volume outweighed its lower rate. Fable-high ended up cheaper in dollars - the first cell in either eval where Fable-as-worker beat Opus on price.
Opus 5 widens this gap rather than closing it. On the same brief it explored 7.95M tokens - about 16x Fable-high - and cost $5.78, roughly 3.6x Fable-high, despite carrying the lowest per-token rate on this page ($0.73/1M). This is now two Opus generations pointing the same way, which makes it the best-supported claim in Fable's favour.
Dollar cost, same open-ended design task
n=1 per cell still one run per model on one task - but the direction now replicates across two Opus generations.
-
2
It's better for design work, too.
A blind taste judge scored Fable-high and Fable-low tied at 4.5, ahead of Opus 4.8-high's 4.0 and Opus 5-high's 3.5 - despite both Opus cells spending more and exploring more. Across all four cells the taste ordering runs exactly opposite to spend, and Opus 5 sits at the bottom of both. More spend didn't buy better design judgment in any cell measured; Fable's cheaper output was judged just as good or better.
Blind taste score, median of 2 judge samples (1–5)
n=1 per cell single design task, one judge model, 2 samples per cell - suggestive, not conclusive. The two Opus 5 samples split 3 and 4, so its 3.5 median rests on a disagreement, not a consensus.
Both points come from the same design task, so treat this as one coherent data point rather than two independent confirmations - but it now has an Opus 5 cell pointing the same way as the Opus 4.8 one, which is more than it had before. Everything else this page measured - management, solo work on a normal task, speed - Opus won outright; see the numbers above.
Untested: Fable 5 as a reviewer, not a doerno cell run for this
None of the three evals above tested this shape. It's a distinct role from everything measured so far: Opus (or the worker pool) still writes the diff; Fable 5 only reads spec + diff and judges it, then either approves or sends it back for changes. That's closer to the blind-judge role the eval's own fidelity scoring used (gpt-5.5 and GLM 5.2 as judges) than to Fable-as-manager or Fable-as-worker.
- Review is a bounded-context task - reading a spec and a diff, not running tool loops or writing code. The eval's rate tax showed up on management and authoring volume; a review pass could burn far fewer tokens per call than either role tested.
- The re-judge findings in Evidence 1 show single-sample, unanchored judging missed real defects (the two contested checks were absent everywhere, but only got flagged inconsistently) - a more capable reviewer model, used carefully with an anchored rubric, is exactly the kind of fix that closed that gap.
- It reuses spend where Fable's extra capability is plausibly the bottleneck (catching subtle spec deviations) rather than where it's irrelevant (grinding through routine edits), which is the same logic behind "pay for capability where capability is scarce."
- The rate tax measured in Evidence 1 is per-token, not volume-dependent - a small review call still runs at Fable's ~1.9-3.3x rate premium over Opus. Cheap in absolute dollars, but not rate-competitive with a cheaper reviewer (e.g. a smaller Claude model or one of the existing judge models).
- A review-then-revise loop is another hop, and Evidence 1's nested-delegation cells found each hop adds wall clock and one class of real risk: a second-hop context loss (the worker that hardcoded its sandbox path). A review hop that sends work back for changes could reproduce that pattern rather than avoid it.
- Better judgment doesn't fix a bad rubric. The eval's own single-sample judging noise came from unanchored scoring criteria, not judge model weakness (gpt-5.5 and GLM 5.2 agreed on every diff once rubric-anchored). A stronger reviewer model may not help if the failure mode is the checklist, not the checker.
Speculative This is reasoning from the existing evidence, not a new measurement - no cell in any of the three evals ran Fable 5 as a blind reviewer feeding back to Opus. It would need its own eval: same spec, Opus (or the worker pool) writes, Fable 5 reviews against a rubric, and the loop is timed and costed like every other cell on this page.