Claude Code · JUL 13, 2026
Run Fable 5 as the orchestrator and Sonnet 5 as the workers
Anthropic's plan-big, execute-small pattern — 96% of Fable 5's performance at 46% of the price — recreated in plain Claude Code with two sessions and a markdown file.
Anthropic published a pattern where Fable 5 plans and Sonnet 5 does the work, and the combo scores 96% of full Fable 5 performance at 46% of the price. Their version runs on the Managed Agents API. I run the same split in plain Claude Code with two sessions and a markdown file, and this guide is the full recipe.
No API key, no beta headers, no code. You need Claude Code, a plan that lives in PLAN.md, and the discipline to keep the expensive model away from the boring work.
Why split the models
Fable 5 is the smartest model Anthropic ships, and it's priced like it. On the BrowseComp benchmark, running everything on Fable 5 costs $40.56 per problem. Running everything on Sonnet 5 costs $16.01 but gives up 13 points of accuracy. The interesting dot is the one in the middle:

Fable 5 as the lead with Sonnet 5 workers: 86.8% accuracy at $18.53 per problem. That's 96% of the all-Fable score at 46% of the all-Fable price. The reason is simple — most tokens in agentic work get burned on execution. Reading files, grepping, running tests, browsing. None of that needs the expensive model. Judgment does.
The same logic applies if you're on a Claude subscription instead of the API: Fable 5 eats your usage limits far faster than Sonnet 5, so pushing the token-heavy work down a tier stretches how much you get done before hitting the cap.
The pattern
One Fable 5 session acts as the orchestrator. It reads the codebase, makes the calls that actually require intelligence, and writes a plan. Sonnet 5 workers pick up the plan and loop on execution until the tasks are done. The orchestrator never greps; the workers never architect.

In the official version, the orchestrator delegates over the Managed Agents API and the results stream back automatically. In my version, the delegation is a markdown file and the streaming back is me pasting. More manual, same economics.
The receipts
The whole pattern comes straight from Anthropic. Here's the thread from the Claude Devs account, benchmark charts included:
Their numbers come from the plan-big-execute-small cookbook, which builds the whole thing with the Managed Agents API — a coordinator agent with a roster of worker agents, each running in its own session thread. If you're building a product, read the cookbook. If you just live in Claude Code like me, keep reading: everything below needs zero setup.
Session one: Fable 5 writes the plan
Open Claude Code, switch the model with /model, and pick Fable 5. Then give it the orchestrator job. The one rule that makes this work: Fable is not allowed to touch the code. Its only deliverable is PLAN.md.
You are the orchestrator on this project. You do not write code. You do not execute tasks. Your only deliverable is a plan.
Here's what I want built: [describe your feature or task]
Do this:
1. Read the codebase and understand what the work actually requires.
2. Break it into self-contained worker tasks. Each task will be executed by a separate Sonnet 5 session with zero memory of this conversation — so every task must carry its own context: which files to touch, what done looks like, and what NOT to touch.
3. Write it all to PLAN.md: the goal at the top, then numbered tasks, each with files, steps, acceptance criteria, and any gotchas you can see coming.
4. If something is genuinely ambiguous, put it under "Open questions" at the bottom instead of guessing.
Do not start implementing. When PLAN.md is written, stop.The phrase “zero memory of this conversation” is the load-bearing wall. It forces Fable to write tasks that stand alone, which is exactly what a fresh Sonnet session needs. The first time I ran this without it, the plan said things like “update the component we discussed” — useless to a worker that wasn't in the room.
Session two: Sonnet 5 does the work
Open a new terminal tab, start a fresh Claude Code session, and switch to Sonnet 5 with /model. Both sessions share the same filesystem, so PLAN.md is already sitting there — the file is the message bus.
You are a worker on this project. The plan in PLAN.md was written by a stronger model. Your job is execution, not redesign.
Read PLAN.md and execute task 1.
Rules:
- Follow the plan. If the plan and the codebase disagree, or a step doesn't make sense, do not improvise an architecture decision — write the question to WORK.md and move on to what you CAN do.
- Log everything to WORK.md as you go: files changed, commands run, test results, anything you skipped and why.
- When the task is done and tests pass, stop.Because Fable wrote the tasks to be self-contained, you can fan out: open three tabs, point each Sonnet session at a different task number, and let them run in parallel — same shape as the diagram above. For most of my work one worker at a time is plenty.
Close the loop
When the workers stop, go back to the Fable session — it still has all its planning context — and have it review the work log:
You're the orchestrator again. The workers are done. Read WORK.md and review it against PLAN.md:
- Did each task meet its acceptance criteria? Check the actual code — do not trust the log.
- Answer any open questions the workers wrote down.
- If anything is wrong or incomplete, write the fix-up tasks into PLAN.md as a new round.
- If everything holds, say so and summarize what shipped.
Do not fix anything yourself. Plan the fixes; the workers execute them.Then it's just laps: workers execute the new round, Fable reviews again. On a typical feature, Fable gets touched two or three times total — the opening plan and a review or two. Sonnet burns everything else. That ratio is where the savings live.
The whole loop, compressed
- Fable 5 session → orchestrator prompt →
PLAN.md - Fresh Sonnet 5 session → worker prompt → executes, logs to
WORK.md - Back to the Fable session → review prompt → approve or new round
- Repeat until Fable signs off
The flip side: Sonnet with a Fable advisor
The same thread has a mirror-image strategy that I use for smaller tasks. Instead of Fable leading, Sonnet 5 runs the whole show and only phones Fable 5 when it's stuck. On SWE-bench Pro, that setup gets ~92% of Fable's score at ~63% of the price, with Fable called about once per task.

The manual Claude Code version: work in a Sonnet 5 session as normal. When it hits a wall — a gnarly bug, a design fork, a refactor it keeps botching — have it dump the situation into QUESTION.md, open a Fable session, and ask for a ruling. Paste the ruling back. One expensive call instead of an expensive afternoon.
My rule of thumb: orchestrator pattern for multi-file features and refactors where the plan is the hard part, advisor pattern for day-to-day work where Sonnet is fine 95% of the time.
Next steps
Run it once on a real feature and watch where the tokens go — that's the fastest way to feel the trade. Then make it yours:
- Save the three prompts as a Claude Code skill so
/orchestratekicks off the whole flow. - Add a
DECISIONS.mdwhere Fable logs the reasoning behind the plan — gold when you come back to the code in a month. - When you outgrow the manual loop, graduate to the Managed Agents cookbook and let the API do the pasting for you.

Written by
@atareh
AI architect & creator. Writing, designing, and producing in AI and tech. Previously head of product at a healthtech SaaS; background in molecular science. Founded gogray.today in 2017.
Related
Keep reading.
Made by @atareh · x / twitter · instagram