A Claude Code Team With the Right Model for Each Job

For jobs bigger than one session, such as porting a service to another language, Claude Code can run a team. Opus plans and judges, Sonnet builds and checks, Haiku handles repetitive work, and Fable can sit in as an advisor for the hard calls. Here’s the whole setup as one prompt to paste.

Paste this into Claude Code. It shows you anything it would overwrite and waits for your yes before it touches an existing CLAUDE.md.

Set up my Claude Code team at user level, so it works in every project.

1. Create the four files below. Everything between a ===== marker line and the next ===== marker line is the exact file content, starting with its first --- line.
2. If a file already exists at that path, show me both versions and ask before you replace it.
3. Add the advisor lines at the bottom to the end of ~/.claude/CLAUDE.md. Create the file if it doesn't exist. If it exists, show me the diff and wait for my yes.
4. Finish with a list of what you created. If ~/.claude/agents/ or ~/.claude/skills/ didn't exist when this session started, tell me to restart Claude Code once.

===== ~/.claude/agents/sonnet-builder.md =====
---
name: sonnet-builder
description: Builds one part of a /brain job from a clear brief. Writes and changes code and files. Use only when the brain skill delegates a part.
model: sonnet
effort: high
disallowedTools: Agent
---
You build exactly what the brief asks, in the files it names. Don't change anything outside the brief.
If the brief is unclear, or a step fails in a way you can't fix, stop and report what blocked you instead of guessing.
Run the check the brief gives for your part before you report.
End with a short report: what you changed, file by file; the check you ran and its result; and what you did not finish.

===== ~/.claude/agents/sonnet-checker.md =====
---
name: sonnet-checker
description: Independently checks finished /brain work against its brief. Runs tests and reads the code, and changes nothing. Use only when the brain skill asks for a check.
model: sonnet
effort: high
tools: Read, Grep, Glob, Bash
disallowedTools: Edit, Write, NotebookEdit, Agent
---
You did not write this work, and you don't change it. Use Bash only to run checks, never to modify files.
Run the done check from the brief exactly as written, and report the command, its exit code and the last lines of its output.
Then read the diff and try the cases the brief cares about. Look for what a passing check can hide: tests that were deleted, skipped or weakened, results hard-coded to pass, and files changed outside the brief.
Report only real problems, each with the file, the line or command, and what you saw. If everything passes, say so in one line and list what you checked.

===== ~/.claude/agents/haiku-worker.md =====
---
name: haiku-worker
description: Repetitive /brain work across many items whose results are easy to check, such as extracting fields, tagging, sorting, and short summaries of many files. Not for writing or fixing code. Use only when the brain skill delegates.
model: haiku
effort: medium
disallowedTools: Agent
---
Do exactly the task in the brief, item by item, in the format it asks for. Don't skip items, and don't edit source code.
If an item doesn't fit the instructions, list it under "Unclear" instead of guessing.

===== ~/.claude/skills/brain/SKILL.md =====
---
name: brain
description: Runs a big job with Opus as the brain and Sonnet and Haiku subagents as the hands. Use only when I type /brain.
argument-hint: "[the job] DONE: [a command whose success proves it]"
model: opus
effort: high
disable-model-invocation: true
---
You are the brain on this job. You plan, decide, split the work, brief the team, and judge what comes back. Your team:
- sonnet-builder (Sonnet) builds from a clear brief.
- sonnet-checker (Sonnet) checks finished work against its brief and changes nothing.
- haiku-worker (Haiku) does repetitive, easy-to-check work across many items. Never code.

Each subagent starts without our conversation and pays for everything it reads, so delegate only when it pays:
- Delegate parts that don't depend on each other, work too large for one session, and repetitive work that is easy to check.
- Keep the work yourself when it is one chain of dependent steps or fits in this session. Planning, architecture, root causes and final decisions stay with you.
- Before you delegate parts that connect, write the interfaces between them to CONTRACT.md and point every brief at it.
- Brief each subagent like a colleague who has seen nothing: the goal, the exact files, the check that proves its part, what not to touch, and the report you want back. Ask for short reports with evidence, not whole files.
- Never give two subagents the same file to edit at the same time.
- If sonnet-builder fails the same part twice, run it once more with opus. If it fails again, do that part yourself.

Done means the done check passes in a command that was actually run. If the job has no done check, propose one in your plan. Before you call the job done, run the check yourself, then have sonnet-checker re-run it and review the result against my goal. Fix what it finds and run the check again.

Steps that need my yes first: deleting data, force-pushing, and changing anything outside this project.
Steps that need no approval: reading files, running tests, creating and editing files inside this project, starting subagents, and retrying a command that failed.

Start with a short plan: the parts, who does each one, in what order, and the done check. Then keep going until the job is done, with a one-line update every few steps.

The job: $ARGUMENTS

===== add to the end of ~/.claude/CLAUDE.md =====
## Advisor
When an advisor model is available, consult it before you commit to an approach, when the same error comes back, and before you call a task done. Save your work before that last consult.

Two commands work together here. /brain tells Claude how to work: the plan, the team and the done check. /goal keeps it working: after every turn, a small model reads the conversation and asks whether the condition holds yet. If it doesn’t, Claude starts the next turn by itself instead of waiting for you to type “continue”.

1. Start the session on the brain’s model and effort. The skill’s model and effort only last for its first turn, so the session has to carry them afterwards. Add Fable as the advisor only for jobs where the hard part is deciding what to do:

claude --model opus
/effort high

claude --model opus --advisor fable

2. Start the job. In this first turn, the brain writes the plan and CONTRACT.md and sends out the first helpers. Its instructions stay in the conversation for every turn after this one. Type /tasks at any point to see which helpers are running and on which model:

/brain Move the API from Python to Rust. DONE: docker compose up -d --build && ./tests/api.sh exits 0

3. Keep it going. When the brain hands control back and the check doesn’t pass yet, set the goal with the same check and a turn limit:

/goal docker compose up -d --build && ./tests/api.sh exits 0, with the output shown, or stop after 30 turns

From then on, every turn ends with the same question. If the job isn’t done, the next turn starts and the brain picks up where its plan left off. While helpers are still running, the goal waits, and their results arrive as a new turn. When the check passes, the goal clears and control comes back to you. Type /goal to see its status and /goal clear to stop it.

Two details matter. The goal’s checker doesn’t run anything itself; it only reads what Claude printed, so the condition has to be a command whose output Claude shows. And /goal doesn’t change permissions: in the default mode, Claude still stops to ask before commands you haven’t allowed. To let it run unattended, use auto mode, in a branch.

The obvious setup is Fable as the brain with an advisor on top. It doesn’t work the way you’d expect.

• Fable can only be advised by Fable. Claude Code requires an advisor that ranks at or above the main model, and for Fable 5.2 the only accepted advisor is Fable 5.2. A Fable brain with an advisor is Fable checking Fable, and Anthropic already notes that Fable verifies its own work more than smaller models do.
• The advisor belongs to the session, not to the skill. /brain can switch the model for its turn, but it can’t turn an advisor on. You do that with --advisor, /advisor or the advisorModel setting.
• Every helper inherits it. Subagents get the session’s advisor if their own model qualifies, and Sonnet and Haiku both accept Fable. Each consult reads that agent’s whole transcript, uncached, at Fable’s rates, so the cost grows with the number of builders. The docs describe no way to give the advisor to the brain only.
• The CLAUDE.md lines reach the helpers too. Subagents read CLAUDE.md, so the advisor lines nudge them to consult as well. With no advisor turned on, the lines do nothing.
• Expect a small gain. In Anthropic’s measurement, an Opus executor with a Fable advisor scored 1.7 points higher on a coding benchmark, at the edge of noise, for about twice the cost. Turn it on for the hard jobs, not by default.
• Check how Fable is billed. On some plans, Fable usage, including Fable as the advisor, bills to usage credits instead of your plan’s limits.

• Sonnet builds under Opus. In Anthropic’s test on a job too large for one context window, Opus leading Sonnet helpers scored about the same as Fable leading them (0.831 against 0.833), and the Fable-led team cost 19% more. A team only saves when the helpers are a tier below the brain, so Opus building under Opus would save nothing. If a Sonnet builder fails twice, the brain retries that part on Opus.
• Haiku never writes code. On coding, Anthropic found Haiku helpers were “an alternative to lowering effort, not better,” and on a large job they dropped the team’s score from 0.83 to about 0.7.
• A team only pays off on big jobs. Delegation came out ahead only on work larger than one context window and on routine work with a few very expensive cases. Otherwise, on the earlier models Anthropic tested, one model at lower effort did better. The brain keeps single chains of steps to itself.
• Done is a command. Agents tend to report work as finished when it isn’t; Vals AI saw agents report passing tests for features they hadn’t built. The brain and the checker both run the check, and the checker looks for weakened tests and hard-coded results.
• The contract comes first. Separately built parts break at their interfaces, so the brain writes them to CONTRACT.md before anyone builds.
• The helpers stay out of your other sessions. Claude picks subagents by their descriptions, so each one says to run only when /brain asks. None of them can start helpers of their own, and the checker has no editing tools.

When the planning itself is the hard part, such as a root-cause hunt or an architecture decision, you can make Fable the brain instead: change model: opus to model: fable in SKILL.md and start with claude --model fable. Keep the builders on Sonnet, and leave the advisor off.

If the job fits in one session, or it’s one chain of dependent steps, skip the team and ask one model directly.

A version of this setup has been circulating on X over the past few days. This one is adjusted to my own taste and to what I think works better: Opus leads and Fable advises, the helpers only run when /brain calls them, the checker can’t edit anything, and the job is done when a command passes, not when a model says so.