Field notes ยท from two hands-on evals
Saving money with Fable 5
Fable 5 is the most capable Claude model - and the priciest way to burn a Claude subscription. Two hands-on evals (a solo-vs-delegation orchestration test, and a coding-subagent shootout) point to a simple playbook for using it economically. Takeaways first, evidence below.
Same feature. Same workers. Different manager.
Claude spend to manage one real coding task through the same pool of cheap workers
of solo Claude-plan burn when Fable delegates the grind to a flat pool of cheaper models
management cost with Opus as the flat manager - cheaper than Opus doing the work solo ($4.69–$5.23)
faster: solo beat flat delegation on wall clock at this task size (614s vs 1044s avg)
All numbers from the two eval reports summarized below; small sample sizes throughout (n=1–3 per cell).
The three setups, in one picture
"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.
Five ways to spend less
-
1
Don't use Fable 5 as the manager. Opus does the same job for a third of the price.
Every token Fable writes costs more ($0.19–0.25 per 1k output tokens, all-in, vs Opus's $0.12–0.13). Swapping only the manager took the bill from $6.08–$6.76 down to $2.13, and every quality check still passed. The extra cost of delegating was really the extra cost of Fable.
-
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.
One model working alone finished ~40% faster than flat delegation and ~55% faster than nested - even though the delegated runs used several workers at once. Writing instructions, checking the work, and stitching the pieces together ate up all the parallel speed-up at this task size.
-
4
Never stack managers on managers.
The two-hop setup (Fable managing Opus managers managing workers) lost on everything: most expensive ($7.87), slowest, most Claude tokens burned. It also produced the one real delegation bug - a worker that didn't know which repo it was in baked its temp-folder path into a committed test. (One run only.)
-
5
Pick workers by task type, not one favorite model.
No worker won everything. Opus 4.8 was the only one that always finished the job properly (tests run, work committed, 9/9). GPT 5.5 scored best on judged quality and code review, but its sandbox can't make git commits - the manager has to commit for it. GLM 5.2 beat pricier models on API design 3 times out of 3, but had one run where it barely tried - check its work.
So where does Fable 5 fit?
Honest answer: in these two evals, Fable 5 never won a measured category - but it was only ever tested as a manager, the one place its extra capability can't pay for itself. Routing work doesn't need the smartest model in the room; it needs a cheap, reliable one. Fable's case is the task itself being too hard for everything else. At a glance:
The evidence
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 passed all four. A blind GPT 5.5 judge then scored each diff against the spec. Solo ran twice, Fable-managed flat twice, Opus-managed flat once, nested once.
Wall clock
Seconds to complete the feature, lower is better
Both delegated shapes ran workers concurrently and still lost to one model alone - overhead beat parallelism at this task size.
Claude cost, management layer
Dollars of Claude usage; workers ride other plans, so this is not a total-system claim
Managing the worker pool costs less than doing the work at the same model's prices - if the manager is Opus, not Fable.
Claude-plan burn
Output tokens across all Claude layers per run, lower preserves more subscription headroom
Cache reads tell the same story: solo ~6.1M vs flat ~1.2–2.3M. Nested forfeits the headroom win - its Opus managers put the grind back on the Claude plan.
Show the full data table
| Cell | Wall clock | Claude cost (mgmt) | Workers | Fidelity (blind, 1–5) |
|---|---|---|---|---|
| Solo (Opus, avg of 2) | 614s | $4.96 | none | 5 |
| Flat (Fable manager, avg of 2) | 1044s | $6.42 | 2 gpt + 2 glm | 4 |
| Flat (Opus manager, n=1) | 904s | $2.13 | 2 gpt + 2 glm | 4 |
| Nested (Fable → Opus x2, n=1) | 1353s | $7.87 | 1 gpt + 6 glm | 4 |
Plan burn per cell (all Claude layers): solo ~80 turns / ~6.1M cache reads / ~39k output; Fable-flat ~44 / ~2.3M / ~30k; Opus-flat 31 / 1.2M / 22k; nested 26 / 4.6M / 76k.
The blind judge 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. Every run, solo or delegated, skipped real atomicity; nothing was "lost in the delegation telephone game" except one verified nested-only defect. Treat the fidelity gap as judge noise pending a re-judge. Also: nested and the Opus-manager cell are n=1, and Opus ran at default effort vs Fable at high, so effort is conflated with model choice.
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.