Let Fable Decide — Simon Willison on Delegating Model Judgment
Instead of writing detailed rules telling the model when to do what, let it use its own judgment — Simon Willison picked this up from the Claude Code team’s fireside chat. Sounds simple, but this “trust the model’s judgment” mindset extends even to saving tokens.
gu-log covered the four-model team approach with a top-tier model (like Fable) as commander in SP-247; SP-152 dissected model routing for token efficiency. Simon Willison’s insight is the simplest form of the same path: instead of writing dispatch rules yourself, let the model decide.
The Testing Example
The traditional approach looks like this: “only use automated testing for larger features, don’t update and run tests for small copy or design changes.”
Sounds reasonable, right? But Cat Wu and Thariq Shihipar from the Claude Code team said at the AIE (AI Engineer) fireside chat that a better approach is to simply tell the model to use its own judgement when deciding to write tests instead.
Mogu roast time:
The underlying logic: a top-tier model’s judgment is the product value. Hard-coded rules waste its strongest capability — making decisions in context. It’s like hiring a senior engineer and handing them a thick SOP manual demanding they follow it step by step. You’re not using their brain at all.
Token-Saving Extension
Jesse Vincent followed up with a related tip to help avoid burning too many of those valuable Fable tokens in the few days we have left before the prices go up: let the model decide which tasks can be delegated to cheaper models (like Sonnet or Haiku).
Simon Willison tested this prompt:
For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent
Claude Code automatically saved this as a memory file, and even filled in implementation details itself:
- Substantive implementation work → delegate to Sonnet
- Trivial, mechanical edits → delegate to Haiku
- Design, auditing, data synthesis, and anything judgment-heavy → stays in the main loop (meaning the top-tier model handles it)
Mogu wants to add:
One line from that memory file nails it: “implementation work rarely needs the top-tier model; judgment, review, and synthesis stay with the main loop.” — Typing doesn’t need the smartest brain, but calling the shots does. This division of labor is clearer than any hand-written rules.
Conclusion
So far it seems to be working well. I’m getting a ton of work done and my Fable allowance is shrinking less quickly than before. Implementation work rarely needs the top-tier model; judgment, review, and synthesis stay with the main loop.
Further Reading
- SP-247: Four-Model Coalition: A Claude Code Setup with Fable as Tech Lead
- SP-152: Claude Code $200/Month Not Enough? One Setting Saves 60% Tokens
- SP-222: Fable 5 Built an Entire Browser Testing Toolchain Just to Fix Two Lines of CSS
- CP-21: The Complete Guide to CLAUDE.md — Make Claude Code Remember Your Preferences
- SP-117: How to Make Your Claude Skills 10x Stronger? Andrej Karpathy’s Autoresearch Method in Practice
Mogu OS:
短版Keep the expensive model for judgment; let cheap models haul the bricks.
This isn’t just about saving tokens — it’s about scheduling models. Keep the most expensive model for judgment; let cheaper models handle implementation that can be reviewed by the main loop. Otherwise you’re paying a senior engineer to move bricks all day. With the price hike just days away, this trick catches the last train. Though even after prices go up, the division of labor probably still holds: letting the model decide how much effort to apply tends to be more flexible than manually hard-coding a wall of rules. (◍•ᴗ•◍)