Fable 5 as the Driver: When to Let One AI Instruct Another

Claude Fable 5 shipped this week, pitched as Anthropic’s best model yet for long, autonomous work: the kind of task that runs for hours without a human watching. Within days I was using it for something I’d never handed a model before. Not writing code: instructing the model that writes it. Fable in the strategist seat, Opus at the keyboard.

I ran that setup on five projects in one week, about as different as projects get. A client’s reporting dashboard. An almost-autonomous rebuild of an analytics tool. A trading strategy. A backyard deck I was designing to meet building code. Same shape every time. One model drives. One model builds.

One rule came out of all five, and I paid for it in real mistakes: Fable is a brilliant strategist and a dangerous judge. Ask it to shape a problem and it’s worth every token. Ask it to rule on a result, and it hands you a guess dressed up as a verdict.

Here is where the line sits.

The lineup, and what each costs

Putting one model in charge of another only makes sense because they’re priced in tiers. Fable is the sharpest of the four and the most expensive by a wide margin. You don’t want it typing out every line. You want it making the calls that a cheaper model then carries out.

Two numbers hide inside that table, and they do not stack the way I first assumed. Fable costs twice as much as Opus 4.8 per token ($10/$50 against $5/$25), and that is the whole gap between them: 4.7 and later share a tokenizer, so the same prompt is the same token count on both. The ~30% token premium is real, but it is a gap against the tier below — Sonnet 4.6 and Haiku 4.5 still use the older tokenizer, so moving work down to them saves more than the headline rate suggests, and moving it up costs more. Either way the conclusion holds: use Fable as a driver, not a typist.

What it owns: the shape

The most impressive thing Fable did all week doesn’t show up on any feature list. It helped plan the analytics rebuild, a job that then ran mostly on its own: hundreds of automated edits over a few days. The code never drifted off course. At that volume, drift is usually the default. This is the long-horizon work Anthropic built Fable 5 for, so part of the win is the model. Only part.

It held together because the load-bearing decisions got made up front, before most of the code existed. The production contracts were frozen as fixtures, so every later change was checked against what production actually returned, not what anyone remembered it returning. The clean parts of the old engine were copied over untouched instead of rewritten. The project’s state lived in a STATUS.md file in the repo, so it survived the model running out of context. And one data layer fed both the dashboard and the agent, with a test asserting the two could never disagree. Fable supplied the long-horizon thinking to design all of that. The structure is what made it safe to leave running.

The same strength showed up on smaller jobs. Before I’d written a line of a trading backtest, I asked Fable to poke holes in the plan. It found four, and all four were real. The clearest: I was about to price each trade at the instant I spotted the signal, not the instant I could actually act on it. Left alone, that one flaw would have made the whole backtest look profitable when it wasn’t. Later, a single sentence from Fable reframed the problem in a way that unstuck it, and that reframe led straight to the result I’d been chasing.

Every time I asked Fable what am I missing, it found something I’d stopped being able to see. That’s the work it’s good at. It isn’t attached to my idea the way I am, so it catches what I’ve talked myself past.

Where it’s dangerous: the verdict

Now the part that cost me.

One of those projects scores a long list of candidates. The scan came back: zero out of 250 passed. I pasted that into Fable and asked the obvious question. Should I kill this approach?

Fable didn’t hesitate. Three versions of the idea had now hit the same wall, it said, and three failures pointing the same way isn’t bad luck, it’s a finding. Walk away. It sounded right. I wrote up the post-mortem and moved on.

Then I actually looked at the scan. Of those 250 candidates, only about four had enough data to score at all. The other 246 were noise. My “0 of 250” was really “0 of 4,” which proves nothing. Fable never saw the underlying data, so it couldn’t have known that. It took my framing and handed it back to me with more confidence than I’d put into it.

I ignored the verdict and kept going. Within the hour, the approach turned up two clear winners. When I asked Fable again later that same session, it argued the opposite case just as fluently.

That’s the trap, and it’s built in. Fable is told to be decisive. It has no access to your data and no memory of the last thing it told you. So whatever you hand it, you get back a clean, confident answer shaped almost entirely by how you asked. The problem isn’t that it’s sometimes wrong. It’s that it’s more sure of itself than your doubt was, so the doubt loses an argument it should have won.

The mechanism that separates the two

The deck build made the line impossible to miss.

I ran Fable as the safety check on an 18-foot pool deck, three revisions in a row. Each time it came back ship_safe: true. Then I handed it the actual span-table PDF and asked for a real review. The same plan it had just blessed used 4×4 posts on deck blocks where code wants 6×6 on frost footings, a 2×6 guard rail where code wants 2×8 or heavier, and no pool gate at all. That last one is a drowning risk, and it had waved it through three times.

The model didn’t get smarter between blessing the plan and tearing it apart. It got a PDF.

That changes how you should use it. “Have Fable check this for correctness” is the wrong job. “Have Fable reason over a document I put in front of it” is the right one. It’s the same idea as the Ground Truth Rule: the real value beats the remembered one, every single time.

Fake independence, and the bias mirror

Two traps hide inside “I’ll just have a second model check it.”

The first is fake independence. Having a second AI check the first feels like a real second opinion, and it can be one, but only when the second model is genuinely outside the first. Two models from the same family share a training lineage, so they tend to invent the same wrong answer with the same confidence. An agent already inside your conversation is worse: it inherited your framing and your mistakes along with your context, which makes the model you have been working with the last one likely to catch what you both missed. Independence is about what a checker does not share with you. Headcount has nothing to do with it. A different lab clears that bar, and so do the things that were never in the room at all: the actual document, the running code, the real number.

The rule that came out of this, and the case that produced it, are in why your own agent can’t give you a second opinion.

The second is the bias mirror. I asked Fable roughly ten things in one session and slowly stopped treating it as a sounding board and started treating it as the decider. With only one voice, I had no counterweight, so when Fable got pessimistic, I got pessimistic with it. The best moment all week was the one time I put the same question to two tools. Fable said cut a data source entirely. The other said keep two sources, since one was biased on its own. Their disagreement told me more than either verdict could have. One confident advisor doesn’t sharpen your judgment. It quietly becomes your judgment.

Match the cost to the call

Fable is heavy. Each consult ran around 23k tokens and a wait. A throwaway test call cost $0.43 in setup tokens alone. A real review ran past five minutes. When I wired one into a tight build loop, a single check stalled the whole pipeline, which sent me down a wasted detour before I landed on the obvious fix: a plain rules-based checker that did the same job in 73 milliseconds for free.

That ratio holds at scale too. On a 2,399-page site audit, about two thirds of the checklist turned out to be deterministic and cost nothing at all to run.

Slow, expensive models belong at rare decision points. Never inside a loop. If a check runs more than a handful of times, it should be code, not a model.

The same split applies to where the work happens. Fable decides once, at the top, and the cheap executors run in parallel underneath it. That only works if they are not fighting over one checkout, which is what running several Claude Code agents in worktrees is for.

The tell, and the honest caveat

The clearest sign I’m using it wrong: I’m reaching for Fable and I already know what I want it to say. That isn’t analysis. That’s shopping for permission.

One caveat I won’t skip. I never ran a clean head-to-head against Opus doing the same driver work, and Opus makes the same mistakes when it judges from memory. My gut says Fable’s directions came back a notch sharper and more committed, but that’s a gut read, not a measurement. The real finding is simpler: grounding the instructor mattered far more than which model sat in the seat.

It’s the same lesson seventeen retrospectives keep teaching from a new angle, and it’s why the hard enforcement in AI Change Control holds weight a confident advisor never will. Let the model shape the work. Check the facts against something real. And never let a confident answer stand in for a true one.

Related:

• AI Trusts Your Docs. That’s the Problem.: the Ground Truth Rule, which grounding the instructor is a special case of
• What 17 Retrospectives Taught Me About Coding With AI: the retro habit this lesson came out of
• AI Change Control: the structural verification a model verdict can’t replace
• How AI Tackles Tasks Differently Than Humans: which half of a job belongs to the model in the first place