Spend your expensive model on judgement, not on typing

Fable came back for a short, limited window this month. I burned through 70% of a week's allowance in a single day, because I let it do everything: planning, implementation, verification, testing, all Fable. That's the wrong way to spend a scarce resource, and the fix generalises well past Fable specifically.

Plan and check, never build

Whatever's expensive or rate-limited in your setup, a premium model, a tightly-capped plan, a slower and pricier reviewer, should only ever do two jobs: plan the work, and check it afterwards. The actual building, the line-by-line implementation once the shape is decided, goes to whatever's cheap and plentiful.

Same quality bar on the output, a fraction of the spend on the expensive thing.

That's the whole trick, everything else below is just the mechanics of running it.

Where this came from

I've got a Claude Max plan, so as soon as Fable re-released I went all in on it. Fable planning, Fable building, Fable verifying, Fable testing, all of it. That torched 70% of my weekly usage in one sitting, on a Friday, with the weekly allowance not rolling over for another two days and Fable's access window cutting off the day after that. So I needed a way to actually get value out of the remaining access without spending it all on work a cheaper model could do just as well.

The loop that worked

I was building a genuinely large feature for the heating platform, so there was a real plan to slice up. Here's the loop, in order:

Plan the whole thing with the expensive model first. Fable took the full feature and chopped it into slices, each slice broken down further into phases. This is the one part worth spending premium capacity on, getting the shape of the work right before a single line of implementation exists.

Hand each phase to a cheap model to build. Sonnet did the implementation on each phase (Opus is the better call here if you've got the credits for it, I didn't, that day). This is the grunt work, matching code to an already-decided shape, and it doesn't need the expensive model's reasoning to do it well.

Check locally after every phase, not just at the end. Once a phase is implemented, run a typecheck and the full unit suite immediately. It's fast enough to run constantly, and it catches most regressions before they compound into the next phase.

Skip the expensive suite per-phase. Sonnet also looks up what end-to-end tests will eventually be needed for that phase, but doesn't run them yet. Running the full E2E suite after every single phase burns tokens and wall-clock time for signal you don't need yet, since you haven't finished the slice.

Verify the whole slice with the expensive model once it's done. Once every phase in a slice is built and locally checked, bring Fable back, not to build anything, just to check the finished slice against its own original plan. This catches drift early, while it's still cheap to unpick.

Run the expensive test suite once, after verification, not before. The full E2E suite runs a single time per slice, only once Fable's confirmed the slice matches the plan.

All the expensive checking, none of the repeated cost.

Repeat slice by slice, and at the very end, one last full pass: Fable checks the entire finished feature, writes up whatever still needs fixing, and hands that list to Sonnet or Opus to action.

Why the default gets this backwards

Left to its own devices, an agentic workflow tends to spend its most expensive model on the most repetitive part of the job, because that's the part with the most raw token volume. Implementation is verbose. Every function, every test, every fix is more tokens than the plan that describes it. If the expensive model is doing all of it, you're paying premium rates for volume, not for judgement.

Planning and verification are different in kind, not just in size.

Deciding how to slice a feature, and confirming afterwards that the result actually matches the plan, are genuinely judgement calls that benefit from a stronger model's reasoning. Writing the code that fills in an already-decided shape mostly doesn't need that. Cheaper models are entirely capable of it, especially with a clear phase-level plan already in hand and a typecheck plus test suite catching the obvious mistakes immediately after.

It generalises

None of this is specific to Fable. Any time you're pairing a scarce or costly resource with a cheap, abundant one, the same split holds: expensive resource plans and verifies, cheap resource executes. A tightly rate-limited plan, a pricier API tier, even a slow human reviewer whose time is the genuine bottleneck, all behave the same way.

Put the scarce thing at the start and the end of the loop, never in the middle doing the typing.

A few common questions

Does this only apply to Fable? No. Swap Fable for anything scarce and expensive, a capped API tier, a pricier reviewer, even a person's time, and the split still holds: the expensive one plans and checks, the cheap one does the work in between.

Why not just run the full test suite after every phase, to be safe? Because a phase isn't finished work, a slice is. Running the expensive suite before the slice is done just burns tokens checking code that's still going to change.

What's the actual order? Plan the whole feature with the expensive model first. Then for each phase: build cheap, typecheck and unit test locally. Once a slice's phases are all built and checked, bring the expensive model back to verify it against its own plan, run the expensive suite once, and move on to the next slice.

Which cheap model should do the building? Whichever you can afford, Sonnet or Opus both do the job. It's grunt work against an already-decided plan, not a judgement call, so it doesn't need the expensive model's reasoning.

The result

Same output I'd have got from letting Fable build everything, at a fraction of the token burn, because the expensive model only ever touched the decisions, planning up front and checking at the close, never the actual grind in between. Worth trying any time you're rationing something scarce against a cheaper alternative that can do the legwork just as well.