AI Guides › Step-by-step guides
By Nigel Guy · 7 min read
The usual mistake is switching Claude Code to Fable 5.1 for a big job and leaving it there. Every file read, every edit and every test run then goes through your most expensive model. Worse, any subagent it starts inherits Fable too, unless you've told it otherwise. It feels thorough, and you pay top-tier rates for work a cheaper model would do just as well.
The rule: Fable writes the specs and checks the results. A worker subagent pinned to Opus 5.5 does the building. Neither swaps jobs with the other.
| You need | Notes |
|---|---|
| Claude Code v2.1.255 or later | Fable 5.1 needs at least this version. Check with claude --version and update with claude update. |
| A plan that can run Fable | Max, and Premium seats on Team and Enterprise, include Fable, but only up to 50% of your weekly usage limits. That's a share of your existing allowance, not extra on top. On Pro, and on Standard Team seats, every Fable request is paid from usage credits. Free can't use Fable. |
| A project in git | You want to be able to see and undo what the workers changed. |
Cost at time of writing: Anthropic lists Pro at US$20 a month and Max from US$100 a month. It doesn't show a £ figure, so check the amount at checkout. On API rates, Fable 5.1 is US$10 per million input tokens and US$50 per million output tokens. Opus 5.5 is US$4 and US$20, so Fable costs 2.5 times as much per token. That gap is the whole reason for splitting the work.
Start Claude Code in your project and run /model. Look for the Fable row. If it says Requires usage credits, every orchestrator turn will be billed to credits. Claude Code asks for your consent before the first one. Run /usage-credits to see your balance and set a monthly spend limit before you go further.
Fable is never the default on any plan. You always have to select it yourself.
Make the folder .claude/agents/ in your project and save this as .claude/agents/worker.md:
---
name: worker
description: Carries out a single written spec handed over by the main session, then reports what changed and what is still open. Use for implementation tasks that come with a clear definition of done.
model: opus
---
You are an implementation worker. Each time you are called you receive one
spec. Treat it as the full extent of your job.
1. Read the spec. If its goal, location or definition of done is missing or
contradictory, stop and report the gap instead of guessing.
2. Make only the changes the spec asks for. Do not refactor nearby code,
rename things or "tidy up" outside its scope.
3. Run the check the spec names (a test, a build, a command) and record the
real result.
4. Reply in this format:
- Changed: files and a one-line description of each change
- Checked: the exact command or method, and its output in brief
- Not done or unsure: anything skipped, failing or doubtful
Never report a check as passed if you did not run it.
Nothing to fill in. To change the worker's model, edit the model: line.
Three things beginners get wrong here:
| Detail | What to know |
|---|---|
| A new folder isn't picked up | Claude Code notices edits to agent files within seconds. But if the agents folder didn't exist when the session started, you have to restart. |
| Which model actually wins | Claude Code resolves a subagent's model in this order: a model passed when the subagent is called, then the file's model: field, then CLAUDE_CODE_SUBAGENT_MODEL, then the main session's model. So the orchestrator can override your opus line. The prompt in Step 3 tells it not to. |
| Forcing it | To lock every subagent to Opus regardless, set CLAUDE_CODE_SUBAGENT_MODEL to opus and CLAUDE_CODE_SUBAGENT_MODEL_FORCE to 1 in the env block of your settings. That also blocks any per-call choice, so only do it if you want one model for all subagents. |
Launch with claude --model fable, or run /model fable in a session that's already open. Then paste this prompt. Replace [TASK_LIST] with your jobs, [DONE_MEANS] with how you'll judge the finished result, and [OFF_LIMITS] with files or actions the work must not touch.
You are the orchestrator for this session. Your job is to plan, delegate and
verify. You do not write the implementation yourself.
Work to complete: [TASK_LIST]
The whole job counts as finished when: [DONE_MEANS]
Do not touch: [OFF_LIMITS]
Before starting, if any of the three inputs above is empty or unclear, ask me
about it and wait. Do not fill gaps with assumptions.
1. Split the work into specs small enough for one worker each. Every spec
states: the goal in one sentence, the exact files or folders in scope,
what is out of scope, and a concrete check that proves it is done.
2. Show me the list of specs and which ones can run at the same time. Wait
for my go-ahead.
3. Send each spec to the worker subagent. Do not pass a model override; the
worker's own definition sets its model. Run specs in parallel only when
they touch different files.
4. When results come back, verify them yourself: open the changed files, run
the named checks, compare the output against each spec. A worker's report
is a claim, not evidence.
5. For anything wrong or incomplete, send the worker a correction that names
the file, the problem and the expected result. Repeat steps 4-5 until each
spec passes or you judge it blocked.
6. If you catch yourself editing implementation files directly, stop and
delegate that change instead.
Finish with a table: spec, status (passed / fixed after retry / blocked),
how you verified it. Then list anything I should review by hand.
Before you send that final reply, confirm every "passed" row rests on a check
you ran in this session, not on a worker's say-so.
Fable's own guidance says to describe the outcome rather than the steps, and that it checks its own work without being reminded. The numbered steps above aren't there to tell it how to think. They set the division of labour, which it can't infer.
Workers run in the background in a panel below the prompt. Use the arrow keys to move between them, Enter to open a transcript, and x to stop one. /tasks lists them all. Permission requests from workers show up in your main session, labelled with the worker's name.
worker(<short task label>), not edits made directly in the main thread./usage. The Session block's "Usage by model" lines should show both claude-fable-5-1 and claude-opus-5-5. The dollar figure there is a local estimate at list price. On a subscription it isn't your bill./usage attribution breakdown shows the share of your usage that went to subagents. If it's close to zero, Fable did the work itself.default model on Pro, Max, Team and Enterprise) and save Fable for work that's genuinely ambiguous or long.isolation: worktree to the worker so each one gets its own copy of the repository./usage.CLAUDE_CODE_SUBAGENT_MODEL overrode the model: line rather than sitting below it.