Fable Went Dark Mid-Refactor. Watching Claude Code's Subagents Taught Me More Than Any Tutorial.

By the end of this one you'll know how the controller picks a model tier for each task, why the review loop (not the model) is where the real bill hides, and how to scope your dispatches so a "small" task stops costing 4 times its first-pass number.

I stopped reading tutorials a while back. Fable is my teacher now, or it was, until the cutoff hit while I sat at 78% context occupancy with a nasty refactor still on the table.

So I did the obvious thing. I asked Fable to write me the plan for it. Nobody knows how a model reasons about its own instruction-following better than the model itself, no? Some of its choices still surprised me, in the good way, not the "why did you touch that file" way.

Running out of resources is usually when I get creative. No more Fable sessions to lean on, no tutorial left open in another tab, so I went looking for a workaround and found it sitting right where it had been the whole time. The tool documents itself. Watch a subagent run closely enough and it teaches you how it thinks, no separate course required.

I fed the plan into Claude Code Fable high, hit go, and watched a real 7-task run execute end-to-end: subagent by subagent, review gate after review gate. A wall of "Task N: dispatched," "Reviewer: Approved," "Fix pass 2" scrolled by, and my token meter climbed in ways that felt opaque at first. This is subagent orchestration, and understanding how it actually spends tokens is the difference between it being a superpower and it being a very expensive way to write 4 files. The numbers this run left behind are a better teaching tool than any abstract explainer, so I'm laying out what it actually taught me.

What a "subagent" actually is

There's no separate cheaper AI lurking behind the scenes. A subagent is a fresh conversation: a new context window, zero memory of anything that happened before it was spawned, created on purpose by a single controlling model, handed a tightly scoped brief, and read back as a report. The controller (in this run, Sonnet 5) never lets a subagent see the full session history. It writes each subagent a self-contained packet: your single task, the file with your exact requirements, where to write your report, go.

Why bother, instead of just doing everything in a single long conversation? 2 reasons that actually matter for your token bill:

A polluted context is a slow, expensive context. Every extra paragraph of dead history, stuff like re-explaining what happened 3 tasks ago, that lingers in a single long conversation gets re-read and re-billed on every subsequent turn. Fresh subagents don't carry that tax, each pays only for its own scoped work. I've gone deeper on the real cost of bloated CLAUDE.md instructions before, and the same tax applies there too: whatever sits in context gets re-read on every turn, whether it's a bloated instructions file or 3 tasks of dead conversation history.

A subagent with a narrow job does that job better. A model told "implement exactly this, nothing else" second-guesses itself less than a model trying to hold an entire multi-task plan in its head at once.

The catch: spinning up a subagent isn't free. Each subagent re-establishes its own understanding of the relevant code from scratch. Use them for genuinely separable chunks of work, not for every tiny step. That's the actual skill, not the orchestration mechanics.

How the model-tier choice gets made

This is the part that surprised me most, and it's worth spelling out because it's a deliberate rule, not an accident. The controller doesn't pick a single model for everything. It sizes each subagent to the shape of the task:

• Mechanical, fully-specified work (the plan already contains the exact code to write) goes to the cheapest tier. This is transcription-plus-testing, not reasoning.
• Integration work (multiple files, existing patterns to follow, judgment calls about where things plug in) goes to the mid tier.
• Architecture and design decisions with real trade-offs go to the most capable tier available.

I watched this happen concretely. Task 1 of the plan was "add these 4 SQL tables, verbatim, to the schema file, and write a test that checks they exist." The plan spelled out the exact SQL. That got dispatched to Haiku, the cheap tier, and it nailed it on the first try: 76K tokens, clean review, done. No judgment required, so no expensive model required. Haiku isn't trying to become Skynet on this one, it just wants to add 4 tables and clock out.

Unrelated, but my Mac fan spins up harder running the Claude Code CLI than it does compiling an entire Rust crate. Doesn't matter for the token math below. Still annoys me every single time.

Every task after that (writing a recomputeCatalog function that has to reconcile 5 different source tables, wiring a new function into 12 existing call sites without breaking batching discipline, building a SQL query generator with EXPLAIN-plan guardrails) went to Sonnet, the mid tier, because those require reading existing code, making judgment calls, and reasoning about side effects across files. That's the rule in a single sentence: match the model to whether the task needs reasoning or just needs typing.

The part that actually eats your tokens (it's not the model tier)

This next part is genuinely worth an article on its own. Task 1 (the trivial one) cost about 76K tokens for the implementer plus ~108K for its reviewer, and it was over. Clean pass, no fixes needed.

Task 3, "wire the new maintenance function into every place that writes to the database," went sideways twice. Not because the idea was hard, but because the review process is adversarial by design, and it kept catching new problems on each pass. More of a dry Dark Souls "you died," pick-yourself-up-and-try-again rhythm than any dramatic collapse. First it found that one of the writer functions was recomputing an expensive summary table on every row inside a loop that processed thousands of rows, instead of once per batch. That's the difference between a single database round-trip and thousands of them. The fix for that introduced a workaround in a script the reviewer hadn't even been asked to check, and on re-review, it caught that the fix had accidentally reintroduced the exact same per-row bug, just relocated to a different file. That's the part that stuck with me: a fix for one bug quietly resurrecting the same bug somewhere else, and no human would have caught it without a second pair of (artificial) eyes reading the diff line by line.

So Task 3's actual bill was: 1 implementer pass (227K tokens), 1 review (160K), 1 fix pass (164K), 1 re-review (160K), a second fix pass (122K), and a second re-review (140K). That's 6 full subagent dispatches, roughly 970K tokens, for what the plan described in about 25 lines of prose.

Compare that to Task 4, a similarly-sized piece of work that was well-specified and touched fewer moving parts: 1 implementer pass, 1 review, approved immediately, done in 2 dispatches instead of 6.

The lesson isn't "reviews are expensive, skip them." The bug Task 3's reviewer caught was real. A per-row database hammering pattern silently shipped would have caused actual production pain later. It's the same instinct behind why one metric triggers a Claude Code emergency: a quiet regression that slips past review does more damage than a loud, expensive one that gets caught. The lesson is: the review-loop tax is proportional to how many places a task touches and how well-specified it was going in, far more than it's proportional to which model tier you picked.

The review loop isn't overhead. It's where the real bill hides.

A cheap model doing a sprawling, ambiguous task will bounce through just as many expensive fix-and-re-review cycles as a smarter one, arguably more, since it's less likely to self-catch the issue before the reviewer does.

What this means for using Claude without burning through your budget

A few concrete habits fall out of watching this run:

Write tight briefs, not context dumps. The controller didn't paste the whole plan into every dispatch. It extracted just that one task's requirements into a standalone file and pointed the subagent at it. Every extra paragraph of dead history you paste into a prompt is context the model re-reads and re-bills, whether or not it's relevant to the step at hand.

Scope tasks to be genuinely separable before you fan them out. Task 3 was expensive not because of bad luck but because "wire a function into every writer in the codebase" is inherently a wide-blast-radius task with many places to get wrong. Give each subagent one quest, not a raid boss with an essay-length backstory. If you can split a sprawling task into narrower, single-responsibility pieces before dispatching, each piece gets a shorter, cheaper review loop.

Batch your fixes. When a review comes back with multiple findings, a single fix dispatch that addresses all of them costs less than a separate dispatch for each finding. Each dispatch pays a fixed overhead to re-establish context.

Let task complexity, not model prestige, set your tier. The instinct is to reach for the smartest model "to be safe." But a fully-specified, mechanical task doesn't get better with a smarter model, it just gets more expensive. Save the top tier for the moments that actually require judgment: architecture calls, ambiguous trade-offs, anything where a wrong guess is costly to unwind. I think this holds past 7-task plans too, though honestly I haven't pushed it to 20 tasks yet, so take that part with a grain of salt.

Expect the review loop to cost more than the implementation for anything non-trivial, and budget for it going in, rather than being surprised when a "small" task's total bill is 4 times the implementer's first-pass number. That multiplier is the review process doing its job, not waste.

After this run I stopped keeping these rules in my head. They now live as a standing block in my global CLAUDE.md, so every session starts with the routing discipline already loaded. Steal it:

## Dev mode: dispatch subagents to maximize quality per token

**Rule**: when a dev task gets the go, break the work down before writing a
single line, and route each piece to the cheapest model that does it well.
The main session's context is your most expensive resource: anything that can
happen outside of it should happen outside of it.

**Always delegate (never in the main context)**:
- Search, grep, inventories, wide file reads, counting: dispatch a subagent
  on **Haiku**. The main session gets the conclusion, never the file dumps.
- **Separable or parallelizable** implementation chunks (disjoint files,
  independent scripts, separate tests): parallel subagents. **Sonnet** for
  mechanical, well-specified edits, **Opus** for novel code.
- Audits and reviews that read and report: **Sonnet**.

**Stay direct (delegating would cost MORE)**:
- A chain of linked edits in the same handful of files, short iterations.
- Debugging in progress (the mental state of a diagnosis doesn't serialize).
- Architecture decisions, trade-offs, synthesis, final review: that's the
  main session's job, never delegated to a lower tier.

**Subagent briefs**: self-contained (absolute paths, constraints, expected
output format). Ask for structured raw data (lists, JSON, path:line), never
narrative prose. A subagent doesn't rediscover the project: hand it the
minimal context it needs upfront.

**The test before every dispatch**: does delegating keep context out of the
main session, OR does it unlock parallelism? If neither, do it directly.

**Cost differential**: Haiku is roughly 60x cheaper than Opus, Sonnet 5x.
A misrouted task multiplies the bill for zero quality gain.

Yes, this block is itself context that gets re-read on every turn. It's about 300 tokens. Those are the 300 cheapest tokens in this whole story: they're the ones that stop the 970K dispatches.

None of this requires you to understand the orchestration internals in depth. It requires a single mental shift: every subagent dispatch is a fresh, billable conversation, so the real lever isn't which model you pick, it's how narrowly you scope the work you hand it. 😅

Sources

No outside reading for this one. Just a live orchestration run, the dispatch logs, and a calculator.

This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).

---

Claude Code's subagents aren't magic, they're fresh context windows, and watching a 7-task run taught me how the controller actually spends tokens. The production CLAUDE.md template in the kit shows you how to structure instructions so they don't bloat your context on every turn, same tax that applies whether you're running subagents or a single long conversation.

→ Get the welcome kit