Claude Fable 5 as the head,
everything else as hands

One morning we switched our main Claude Code model to Claude Fable 5, the new family Anthropic positions above Opus. It is genuinely smarter, and it comes with a higher price per token and a quota that burns much faster. Using it the way we used Opus, letting it hunt for files, write boilerplate, and fix typos, would be hiring the most expensive brain in the house to walk paperwork between desks.

So we set a new rule before real use: Fable is the "head" only. It plans, decomposes, and synthesizes. All hands-on work belongs to cheaper "hands". Less than an hour later the rule got its first real test: assessing whether a tool our automation depends on every day should move to its new Rust port (the same tool rewritten in Rust).

This post covers how the team is set up, what the first task produced, and exactly where things broke. Every number comes from a real working session on July 3, 2026. None of them are invented.

Part 1Why the most expensive model should only be the "head"

Picture one task you would hand to an AI coding agent, say "assess whether we should move to the new version of this tool". Inside it are several levels of work mixed together. Some of it needs real thinking, like weighing risk and making the call. Some of it just needs care, like checking which machine runs which commands. And some of it is pure labor, like reading a repo end to end and summarizing what is in there.

Run all of that on one model and you pay big-model prices for every level. You also lose something less visible: the lead model's context fills up with detail. Fifty files in, the brain you wanted for decisions is packed with the contents of files it skimmed on the way, with less and less room left to think.

The shape that fits better is two roles. The head thinks, the hands do. The head is the orchestrator: it takes the problem, plans, splits the work, routes each piece to the right hands, then synthesizes the results into an answer. The hands are subagents that do the work in their own separate context and send back only conclusions. The detail in between never flows back to bury the head.

Cost points the same way. A Fable-class model burns quota fast enough to force the question of which work deserves that brain (we broke down per-model pricing in our Claude Code pricing post). Once you are forced to choose, it turns out most of the work never needed the big model at all.

Part 2Claude Code subagents: setting up head and hands

Claude Code ships with a subagents mechanism (official docs). You create short agent files under .claude/agents/ naming each agent, pinning its model, and describing the work it takes. Our team is currently three agents plus one peer from another vendor.

The Claude Code community calls this shape the claude orchestrator, or the orchestrator pattern. What decides whether it works is not the number of agents but the rules written for the head. Ours are three lines.

1. The head never does grunt work. Any search, read-through, or mechanical job gets delegated immediately, even when the head "could just do it". Every token the head burns on this work is quota taken away from thinking.
2. Show the plan before acting. The head must lay out what goes to whom before dispatching, so a human can see it and object before money flows out.
3. Never pin the head inside a daemon. Always-on automation runs fine on small or mid models. The expensive model is called per occasion, only when real thinking is needed.

The actual agent files and the full routing rules are bundled as a toolkit at the end of this post. Enter your email and take them. The skeleton described here is enough to assemble your own either way.

One small lesson with a price tag before trusting the cross-vendor peer: we tested whether Codex was reachable by sending the word ping and asking for pong back. That single-word answer cost 26,800 tokens, because an agent of this class wakes up with its entire context, not just your question. Even "checking that the tool works" has a price, and it belongs in your cost math.

Part 3The first real task: a migration assessment with 4 agents

The job that came in: a CLI tool (a program driven from the command line) that our automation uses on two machines has a new Rust port. Worth moving? Questions like this are easy to answer badly, because the smart-sounding answer ("Rust is faster, migrate") and the correct answer live in different places.

Split into three views, fired in parallel

The head cut the survey into three pieces with no dependencies between them, then fanned them out to three hands running at once.

• Inventory of machine one (Haiku): everywhere the Mac touches this tool. Which commands, which services, which cron jobs.
• Inventory of machine two (Haiku): the same sweep on the other server.
• Reading the Rust port's repo (a bigger model): does the port cover the commands we use, is the config compatible, is the machine-to-machine protocol compatible.

The results were more interesting than expected. The part of the tool we actually use is tiny: 5 integration points and roughly 9 commands, out of a much larger feature set. The port's repo brought both good news and worries. The good news: config works with the same files, and the protocol was proven compatible against a real test fixture, not just documentation. The worries: the port was 8 days old with 470 commits, most of them machine-generated code, and one flag our system leans on every day is gone from the port.

The head synthesizes, and refuses to trust reports alone

At this point three reports agreed on "probably migratable, with conditions". But all of it came from reading. Nobody had touched the real binary yet. So the head dispatched a fourth job: a smoke test against the real thing, built so that failure costs zero. Install the new port side by side with the old one under a different name, point it at the same config, and run read-only commands exclusively. The live system is never touched.

The smoke test is where the whole exercise paid off, because it caught what all three read-based reports could not see.

• The command group we use most does not actually work. In the new port those commands are JS plugins the port cannot load yet. Two of our health-check system's three probes broke instantly. The painful part: during the repo read we had concluded the plugin gap "does not affect us", because neither machine's config declared any plugins. In reality, the everyday commands themselves are the plugins.
• The command syntax changed. The old tool takes a port number as a trailing argument; the new one requires a flag. Every place our automation calls the old shape would break silently.
• Cross-version interop is still unresolved. The new client calling the old server returns an error that cannot distinguish a signing problem from a request-shape problem. Only a real paired test will tell.

So the verdict was neither "migrate" nor "don't". It was right direction, wrong time. Parked, with explicit conditions for when to come back and retest. The binary and the test procedure are kept ready. All of this ended with zero damage, and the head never read a single repo file itself.

Part 4What broke, and when the head must act itself

A green test that did not mean pass

Before the smoke test we already had a test suite for the health-check system. Against the new port it ran 5/5, all green. Stopping there would have meant concluding "compatible". Then the smoke test against the real binary broke 2 of 3 probes. Why the contradiction? The suite mocks the layer that calls the binary, so it was testing its own logic without ever touching the real thing. Green across the board, proving nothing. We call this false-green.

The defense that actually works is a positive control: before trusting any checker's green, find a case you know must fail and confirm the checker turns red on it. If the case that should break still comes back green, what you are reading is not a test result. It is an illusion.

An orchestrator is not someone banned from touching anything

The "head never does grunt work" rule has a flip side worth watching. While synthesizing the reports, the head found 3 gaps where the reports disagreed. The options: dispatch another round to the hands (wait again, pay again), or run a 30-second grep itself. It chose the grep, and that was the best-value decision of the day. The head's job is knowing what to delegate, and what is cheaper to do itself in half a minute. The line is not "never touch". It is "never trade thinking time for work the hands can do".

The trap we got caught in twice in one day

The last lesson is not technical. It is about the orchestrator's own behavior. Once "delegate" is in your hand, everything starts to look delegatable. That day we got caught twice. First, a bug fixable in two lines that we routed into someone else's queue instead. Second, a bar we invented ourselves, "this post needs 2-3 real worked examples first", when the evidence from one session was already enough. Self-set bars become excuses not to act, dressed up as prudence. If you are about to set up your own orchestrator, expect this trap to ship with the package.

A quiet agent is not a dead agent

A small note that saves real money: the agent reading the repo went quiet long enough that the instinct said kill it and restart. The truth was the work ran deep. A nudge asking for progress, instead of a kill, showed the job was moving, and the result that came back was deeper than the head could have produced itself. Killing a working agent means paying twice to get the answer later.

Part 5Using this on your own work

Where to start

1. Create your first three agents. A few lines each under .claude/agents/: a deep thinker, a fast worker, a searcher. Pin models per the table in Part 2.
2. Write rules for the head. At minimum one line: on any search or mechanical work, delegate. Never do it yourself.
3. Make the first task read-only. An assessment, a survey, an audit. Failure costs zero, which makes it the perfect practice field.
4. Always require a smoke test against the real thing. Read-based reports are not the answer yet, and never trust a green test until you have seen it turn red.
5. Log every time the head sneaks work in itself. The first week you will find it doing grunt work more often than you expect. Write it down, adjust the rules.

When to skip all this

Small tasks, single-file tasks, tasks where you already half-know the answer: one mid-tier model working directly is cheaper and faster. Orchestration has a fixed overhead of its own (planning, dispatching, waiting), and it only pays off when the task is big enough for the tiering to earn it back. Just like a single pong at 26,800 tokens taught us.

If one principle sticks, let it be this: pay premium for thinking, pay budget for doing, and never let delegation become the excuse for not acting. As for this team's second task, it did not wait until next week. It arrived the same afternoon. Read on in the update below.

UpdateThe second task arrived the same afternoon

This post went live at noon. By the afternoon the same team had its second real task, so here is the follow-up we promised. The job: six Discord bot daemons whose code had been copy-forked six ways (570 lines each, every fix paid six times) needed collapsing into one shared core, leaving each bot a short launcher of about 30 lines that states only how it differs from the others. The hard part: all six were live in production and none of them was allowed to go down.

The assembly line was longer this time. The head planned and decomposed. The deep thinker read all six real code forks and produced a design. The cross-vendor engineer (Codex) implemented it. Then the deep thinker came back to review the engineer's work against its own design, before a canary rollout: restart one bot, watch it, then roll the rest of the fleet.

The part worth telling is that each verification layer caught a different failure, and all three layers actually fired.

• The designer caught the head being wrong. The head's brief claimed two files were "byte-identical" because a local diff tool lied (it was wrapped by an output-compressor that reported files as identical when they differed). The designer did not take the brief on faith, ran md5 checksums, and found all six files differed. Trusting that brief would have broken the design from page one.
• The engineer caught the designer's miss. During implementation, Codex found that one fork used a different version of a verification module than the other five, something the design never mentioned. Implemented as designed, that bot would have crashed on boot. The engineer switched to injecting the dependency from outside and documented why.
• The reviewer caught the engineer, before rollout. The review pass found two defects the fully green test board could not see: one guard condition had its logic flipped from OR to AND (a silent behavior change on one bot), and a try/catch had been dropped on exactly the bot scheduled to be the first canary. Four lines of fixes, applied before the restart, not after.

The outcome: 222/222 tests green, and green that had passed a positive control. All six bots restarted with zero crashes, shipped across 7 repositories in a bit over an hour. The number I like most is the reviewer's four lines, because they are the difference between a quiet system and a silent misbehavior you only notice days later.

The principle that the reviewer must not be the author, ideally from a different vendor, gets its own deep dive in our post on headless code review with Codex. The one lesson the second task added to the first: a good head is not the one that delegates well, it is the one that builds verification layers so the team catches each other, including catching the head itself.

Third taskTwo days later: a head that builds new hands

Two days later (July 5) the third task came in, and it differed from the first two on the main axis. In both earlier jobs the head was dividing work among "hands it already had". This time the head had to build new hands: add 3 more bots to the fleet, bringing it to 9, without setting each one up step by step the old way.

The hard question in this job was not "how do you set up a bot". We knew that. It was which inputs only a human can decide, so everything else can be derived. Once that question is answered, adding a bot leaves only a few human touchpoints: give it an identity (a charter), create its Discord app, approve the three privileged permissions a human must grant, invite it to the room, and hand over the token. The scripts and the charter walk the rest: the runner, the port, the thing that keeps it running, how it discovers its siblings in the fleet, and the shared rules every bot lives by.

Three things are worth telling.

• Three gates designed to fail loud. With many bots sharing one core, the scariest failure is one bot impersonating another. So we placed three gates that halt the boot on any mismatch, instead of warning and moving on: shared rules missing, no boot; name tag not matching the token, no impersonation; assigned room colliding with another bot's, stop. Every gate was proven with a positive control: feed it input known to be bad and watch it actually fail, rather than trusting that it would.
• The gate that lied to the whole fleet. During an end-to-end test (running the real thing start to finish) on the second new bot, we caught one central gate holding a stale, misnamed variable. The effect: the entire fleet silently degraded to read-only, even though every piece passed its tests in isolation. It is the other face of the false green from the first task: green piece by piece, broken once assembled for real. Fixed, then re-proven across the whole set.
• Even handing over a token has traps. Pasting the token into a terminal prompt failed twice, because invisible control characters leaked into the value. What worked was sending it to the head to write into the config file itself, then deleting the message. Even a secret in transit deserves a safer path than pasting it raw.

The one lesson the third task added to the first two: a mature head does not just delegate well, it can grow its own team. And the heart of growing is knowing exactly what must stay a human decision, then designing the machine to walk everything else.

How to pick which tier plays the head and which the hands: Claude Opus vs Sonnet vs Fable 5: which model for which work