Fable 5 came out yesterday. I’ve spent the day since pointing it at real work, and it has already changed how I run Claude Code.

Here’s the short version. For months the lineup was Opus, Sonnet, Haiku, top to bottom: Opus planned and reviewed, Sonnet wrote the code, and Haiku handled the menial stuff like wording, comments, and content cleanup. Fable landing on top shoved everyone down a rung. Fable supervises now, Opus does the building, Sonnet inherited the grunt work, and Haiku is the one left without a chair.

The whole thing works because the phases of a coding task don’t want the same model. Planning and review are judgment work: a few early calls carry most of the weight, and getting them right matters far more than anything that happens later. Implementation is throughput work: the calls are already made, so what’s left is executing the spec cleanly. Claude Code lets you swap models between those phases with a single command.

So my loop right now is about as simple as it gets: Fable plans, Opus builds, Fable reviews.

Why split the roles

Two reasons. One is about where to spend your best model. The other is about who’s allowed to grade the work.

Spend judgment where it counts. A plan is maybe one percent of the tokens a feature burns through, but it sets most of the outcome. Which files you touch, how the data flows, which edge cases you remember to handle: get those wrong and no amount of tidy implementation will save you. So put your strongest reasoning model on the few hundred words that decide everything, and let a fast, capable model handle the typing.

Nobody should grade their own homework. A model reviewing its own code carries the same blind spots it had while writing it. If it missed the race condition the first time through, it’ll almost certainly miss it on the read-through too, because it’s still attached to the choices it just made. Hand the diff to a different model and you get eyes that haven’t seen those choices yet. It’s the same reason human teams keep the author and the reviewer separate.

Phase 1: Plan with Fable

For planning I want the model with the most room to think, so I reach for the million-token-context build of Fable. In Claude Code you select it by running /model claude-fable-5[1m], or by running /model and choosing the 1M Fable variant from the picker. The [1m] tag is the million-token context window, and that headroom is the whole point: a planner that can hold the relevant slice of the codebase in view at once makes far better calls about what to touch and what might break.

From there, drop into plan mode with Shift+Tab. Plan mode lets Claude read the codebase without editing anything, so what you get back is a plan you sign off on before a single line of code is written. Describe what you want, then let it dig around.

A good plan comes back with more than you asked for: the files it intends to touch, the order to work in, edge cases the ticket never mentioned, and a rough test strategy. This is the moment to argue with it. Push back now, while it’s cheap. Rewriting a few lines of plan costs nothing; rewriting a few files of implementation costs a lot.

When the plan looks right, have it written to a file in the repo, something like docs/plans/rate-limiting.md. That file is the handoff to the implementor, and committing it next to the code earns its keep on a team. The plan becomes something people can read, comment on, and sharpen before anyone writes a line, and it leaves behind a record of why the change was built the way it was.

Phase 2: Implement with Opus

Now hand the work to the implementor. Switch to Opus and point it at the plan file:

Implement docs/plans/rate-limiting.md. Follow the plan as written; if something in it doesn’t survive contact with the code, stop and tell me instead of improvising.

The plan is the contract now. Opus’s job is to build it, not to relitigate the architecture halfway through. In my experience a model handed a concrete plan stays far more on the rails than one handed a vague one-liner.

One rule keeps this from falling apart: when the implementor hits something the plan didn’t see coming, go back to the planner. Say the middleware order turns out to collide with an existing CORS handler. Don’t let Opus improvise a workaround on the spot. Take the thirty-second detour instead. Switch to Fable, explain the conflict, get the plan patched, switch back. Decisions belong to the model you trust to make them.

Phase 3: Review with Fable

Implementation done, tests green. Don’t merge yet. Switch back to Fable and give it a cold read:

Review the diff against main for correctness issues. The plan is in docs/plans/rate-limiting.md; check that the implementation actually honors it.

This is where the whole approach pays off. The reviewer never wrote this code, so it isn’t attached to it. What comes back is the kind of thing an author, human or model, tends to skate right past:

The plan puts the limiter ahead of auth, but the 429 path returns before the request logger ever records the attempt. So repeated abuse from a single IP never shows up in the logs, which means the plan’s “limits apply to unauthenticated probes” intent is only half met.

That’s not a syntax error, and no test would have caught it. It’s a judgment call about whether the code honors what the plan was actually trying to do. It’s the kind of catch you want your strongest model making, and the kind the model that wrote the code usually misses, because it made that call itself and never thought to question it.

Feed the findings back to Opus to fix, or apply them yourself if they’re small.

Skip the manual switching

If hopping between models by hand gets tedious, you don’t have to. Subagents in Claude Code can pin their own model, so you can run the whole session on Fable and let it spin up Opus subagents to do the building. The planner and reviewer stay resident while implementors come and go. Same shape, no switching.

It works well beyond code

None of this is really about code. Plan, build, check is just how careful work tends to go. Writing goes outline, draft, edit. Data analysis goes hypothesis, queries, sanity-check. Infra work goes design, change, verify. The shape is always the same: put your sharpest judgment at the two ends, where you decide what to do and then check whether you actually did it, and let the fast model handle the stretch in between. Any time the middle of a job is just “execute against a spec,” the one who wrote the spec and the one who executes it don’t have to be the same.

Caveats

Worth being honest about when all of this is just ceremony. A two-line bug fix doesn’t need a planning phase. Exploratory hacking, the kind where you don’t know what you’re building until you’ve built it, has no spec to hand off, because figuring it out is the actual work. And if you don’t understand the problem well enough to judge a plan, fix that first. A plan you can’t evaluate is just vibes with numbered steps.

My rough rule: under thirty minutes, just use whatever model is already loaded. Past that, the split earns its keep, usually in the review phase, the moment a fresh set of eyes catches the thing you were about to ship.