How to use Fable as the orchestrator and Opus as the executor in Claude Code

Fable 5.2 is the most capable model you can pick in Claude Code. At API prices it also costs twice as much as Opus 5.5.

So there’s a setup that gives Fable only the thinking. Fable reads the job, writes the plan and splits it into tasks. Each task goes to a sub-agent that runs on Opus 5.5, and Fable checks what comes back.

It takes one environment variable and one paragraph at the end of your prompt. I ran it on a real job from one of my Mac apps, and I’ll show you the setup, the prompt, what the session did and what it cost.

The two roles

Fable is the orchestrator. It runs in the main session, the one you type in.

Opus is the executor. It runs in sub-agents, which are separate Claude sessions that the main one starts for a task. A sub-agent has its own context window, so the files it reads and the test output it goes through never reach the main session. Only its final report does.

Pick Fable for the main session

Open Claude Code in your project, type /model and move to Fable 5.2.

Be careful with Enter here. It makes Fable the default for every new session. Press s to use it only in this one.

Alternatively, you can start the session on Fable from the shell:

claude --model fable

Set the sub-agents to Opus

If you skip this step, the workers run on Fable too. Claude Code decides which model a sub-agent runs on by going down this list, and it stops at the first one that’s set:

With nothing set, a sub-agent gets to the last row, and you pay Fable prices for all the reading and the test runs.

The simplest fix is the environment variable. Set it before you start Claude Code:

export CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-5-5
claude --model fable

To set it once for every session, put it in the env block of ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_SUBAGENT_MODEL": "claude-opus-5-5"
  }
}

You can also write opus. The alias follows the newest Opus, so it changes when a new one comes out.

Notice that the variable is in the third row. It’s a default, and Claude can still pass another model when it starts a sub-agent. To close that door, add CLAUDE_CODE_SUBAGENT_MODEL_FORCE set to 1 next to it. The sub-agents docs have the full rules, including the built-in Explore agent. On a Claude subscription it already runs on Opus when the main session is on Fable.

Add the orchestrator prompt

Write your job as you normally would: what to build, which files matter, how you’ll know it’s done. Then add this at the end:

You lead this job, and your part is the thinking: you write the plan and you make the architecture and strategy decisions.
Break the work into tasks and hand each task to its own sub-agent running on Opus 5.5.
Follow up with each sub-agent until its task is finished.
While the sub-agents work, wait. Don't do their tasks yourself.
When one reports back, review what it did, then hand out the next task.
Deal with everything that doesn't need me, and stop only when you need me to decide something.

Here’s what each line prevents:

This is the loop the prompt sets up:

The job I gave it

The job comes from Clip Joiner, a Mac app I built that joins the clips a camera splits a recording into. Its engine and its command line tool had to learn to read AVI clips from a trail camera and join them into one .mov. When I shipped that feature, the commit touched 33 files.

I went back to the commit before that feature, with its tests already written. So the job has a clear end: scripts/test.sh passes and the app builds.

The prompt names the design document to read, the files not to touch and that finish line. It ends with the six lines above. I started the session like this:

export CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-5-5
claude --model claude-fable-5-2 --permission-mode acceptEdits

I also passed an --allowedTools list with the test and build commands, so nobody had to stop and ask for permission.

The plan

Fable spent almost two minutes reading the design documents and the tests. Then it started the first sub-agent and wrote this:

The plan is set and the first of four tasks is running on Opus 5.5:

1. AVI reader, its errors, and a skeleton of the missing API so the tests compile (running now).
2. The join into a .mov and its check, through the existing plan, writer and verifier.
3. Scanner, inspect and the command line tool.
4. Docs, then the app build.

The tasks run one after the other because they share one build folder and one test binary. I'm waiting for the first report, and will review it before handing out task 2.

I expected several workers at the same time. Fable chose one at a time, because two workers building in the same folder would break each other’s test runs.

Check which model the workers run on

While a sub-agent is running, type /tasks. The panel shows what it’s doing, and the second line ends with its model.

If it says Fable 5.2 there, the variable didn’t reach the session. Stop, set it, and start again.

In my session Fable also passed model: opus itself every time it started a sub-agent, because the prompt names Opus 5.5. That’s the first row of the table above. All five workers ran on Opus 5.5.

The brief

A sub-agent starts with an empty context, so the brief is everything it knows about the job.

The brief Fable wrote for the first worker is 6,471 characters long. It has five parts: the whole job for context, the task, the constraints, how to verify the work, and what to report back. This is the last part:

## Report back (short, plain facts)
- Files added/changed.
- The public API of AVIFile and AVIError as you wrote it (signatures), and the list of TODO stubs left.
- The tail of the test output: how many checks passed/failed, and that every failure is one of the expected not-yet-implemented AVI checks (list the failing lines' prefixes).
- Every place where the design in docs/picked-clips.md part B couldn't work as written or where you decided something it doesn't say (don't edit the docs; a later task does, from your notes).

Fable asked for facts it can check, and it planned ahead. The same brief tells the worker to keep what “task 2 will need”, and to mark every stub with a TODO comment “so the next agent finds them”.

The loop

When a worker finished, Fable looked at the result and wrote the next brief.

The session went through five tasks:

The fifth task wasn’t in the plan. The docs worker found three code comments that no longer matched the code. Fable didn’t edit them. It wrote a short brief and gave them to one more worker.

In the whole session Fable ran 8 shell commands, read 2 files and started 5 sub-agents. It never had to send a worker back, because all five finished at the first try.

Be careful with what “review” means. After the first two tasks Fable ran one shell command to read the diff. After the other three it went by the worker’s report, then ran the full tests and the app build itself at the end. If you want the tests run after every task, say so in the prompt.

The final report

The session ended after 55 minutes and 17 seconds, and it never stopped to ask me something. The report opens with the test results:

All 2472 checks passed
2 of 147 command line checks failed:
** BUILD SUCCEEDED **

The two failures are checks about absolute paths that fail in that folder with any setup, and the prompt said to ignore them. I ran the tests and the build again myself, and I got the same three lines.

The report continues with the files changed, the decisions Fable took where the design was open, and a list of things for me to look at.

One of those things is a help sentence in the command line tool that the new feature made slightly wrong. Fable noticed it and left the wording to me.

What it cost

I had already run this same job twice, with other setups: Fable 5.2 alone, and Fable planning with one Opus sub-agent that wrote all the code, one piece at a time.

Claude Code logs the tokens of every request, for the main session and for each sub-agent. I added them up at API list prices.

The orchestrator prompt gave me the most expensive run and the slowest one. It cost almost twice as much as Fable alone, and took almost three times as long.

Fable’s part is what went down. It cost $4.19, where Fable alone cost $10.73. That’s 61% less. Its context was also half as full at the end, 172,788 tokens against 341,199.

The money went to Opus. Each worker starts from zero, so it reads AGENTS.md, the design document and the tests before it writes a line. Then it carries all of that on every turn. $6.42 of the $16.51 is context read back from the cache.

Each setup ran once, and the first two ran headless with claude -p, so take the times loosely.

When I’d use it

I’d use this setup when Fable is the thing I run out of. On some plans Fable is billed to usage credits instead of the plan’s included limits, and the /model picker tells you with “Requires usage credits” on the Fable row. There, a session where Fable does 61% less is worth more than the total at API prices says.

I’d also use it for a job I want to leave alone for an hour. This one ran for 55 minutes with no question, and the report told me what to check.

I wouldn’t use it for a job one session can finish in twenty minutes. Fable alone did this one in 18 minutes and 56 seconds, for half the price.

And I wouldn’t expect it to be faster. Workers run at the same time only when their tasks don’t touch the same files and the same build, and mine did. For a job that splits cleanly, like the same change in several separate packages, I’d tell Fable in the prompt that the tasks are independent and can run in parallel.

Want me to talk about your product? You can sponsor this site.