Let Claude Decide: Why Giving Fable Its Own Judgement Saves Tokens and Gets More Done
Simon Willison's post, drawing on tips from the Claude Code team, explains why letting Fable use its own judgement — on testing decisions and subagent model routing — produces better results and conserves tokens than writing rigid rules. The principle extends to non-technical Claude users who can describe their situation clearly and then delegate discretionary decisions to the model.
The Instruction That Changes How You Work With Claude
Most professionals who start using Claude Code make the same instinct-driven mistake: they try to control everything. They write exhaustive prompts spelling out every rule — when to write tests, which model to use for which task, how to format the output. It feels responsible. It feels like good management.
But the Claude Code team at Anthropic has a different view, and it’s worth paying close attention to.
In a post published on 3 July 2026, Simon Willison’s analysis at simonwillison.net shares tips from a fireside chat he hosted with Cat Wu and Thariq Shihipar from the Claude Code team. Their core message: when you’re working with Fable — Anthropic’s most capable model in the Claude Code context — you often get better results by stepping back and letting it exercise its own judgement, rather than dictating a rigid playbook.
What ‘Using Its Own Judgement’ Actually Means
Here is the clearest example from Simon Willison’s post. Consider the question of automated testing. A natural instinct is to give Claude a rule: “only run tests for large features, skip them for small copy or design changes.” That sounds sensible. But according to the Claude Code team members Wu and Shihipar, the better approach is simpler: just tell Fable to use its own judgement when deciding whether to write tests.
Why does this work better? Because Fable has enough context about what a “large feature” versus a “trivial edit” looks like in practice. When you write out a rigid rule, you are encoding your best guess. When you let Fable decide, you are trusting a model that has seen enormous amounts of code, documentation, and engineering context to make a situational call — often a more accurate one than your standing rule would produce.
This is a meaningful shift in how to think about prompting. Instead of writing rules that simulate judgement, you delegate the judgement itself.
The Token-Saving Tip: Subagent Delegation
The second insight in Willison’s post is directly practical for anyone managing Claude Code usage costs. Jesse Vincent, mentioned in the post, shared a related tip: tell Fable to use other, lower-powered models for smaller tasks, and let Fable itself decide which model is appropriate for which job.
Willison’s exact prompt, as he describes it in the post, was:
For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent
Claude Code then saved this as a memory file in the project directory, documenting the reasoning clearly. According to that saved memory — reproduced in Willison’s post — the logic is that implementation work rarely needs the top-tier model. Judgment, review, and synthesis stay in the main loop with Fable. For straightforward coding tasks, Fable spawns a subagent running a lighter model, reviews the result, and only uses its own full capacity for decisions that genuinely require it.
Willison notes in the post that this is working well: he is getting a significant amount of work done while his Fable allowance is shrinking more slowly than before.
Why This Matters If You Are Not a Developer
You might be reading this and thinking: “I don’t write code. What does subagent delegation mean for me?”
The underlying principle applies well beyond software development. Think about it this way. Claude Code’s architecture — where a capable orchestrator model can route tasks to lighter models — is a glimpse of how AI workflows are evolving. The idea of matching task complexity to model capability is something any professional can internalise, even if the technical mechanics are handled automatically.
And the broader lesson — trust the model’s judgement instead of over-specifying rules — applies to everyday Claude use, not just Claude Code.
A Concrete Scenario: A Chartered Accountancy Firm in Pune
Imagine a small CA firm in Pune with a team that prepares financial reports, client summaries, and compliance documents. They have started using Claude for drafting and reviewing work. A common instinct on the team is to write very specific instructions: “Summarise this balance sheet in three bullet points. Do not mention depreciation unless the client specifically asked. Always end with a disclaimer paragraph.”
But following the logic of the Claude Code team’s tip, the better approach is to give Claude the context it needs — who the client is, what the document is for, what the professional constraints are — and then ask it to use its judgement about structure, length, and emphasis.
A junior accountant on the team drafting a GST reconciliation summary might write: “Here is the input data. Draft a client-facing summary, using your judgement on how much detail is appropriate given this is a quarterly review rather than a year-end audit.”
The result is often more naturally calibrated than a summary produced from a rigid template-style prompt. Claude can recognise that a quarterly note should be concise, that certain line items are standard and don’t need explanation, and that a CFO-level reader needs different framing than an operations manager. You do not have to encode all of that in instructions. You describe the situation and let the model reason about it.
This does not mean abandoning structure entirely. It means reserving your explicit rules for constraints that are genuinely non-negotiable — regulatory language that must appear verbatim, formatting that a client has specifically requested — and letting Claude handle the discretionary calls.
The Honest Limitations
This approach has real tradeoffs that you should understand before adopting it.
What to Watch For Next
The direction signalled here — orchestrator models that route to lighter models based on task complexity — is likely to become a standard pattern in professional AI tooling. Anthropic’s decision to build this capability into Claude Code, and to actively coach users toward letting the model make routing decisions, suggests this is a deliberate architectural choice rather than a niche workaround.
If you are using Claude Code or plan to, the practical step is straightforward: read Willison’s post and consider adding a project-level instruction that gives Claude latitude to delegate routine tasks to lower-tier subagents. If you are using standard Claude, the softer version of this lesson still applies — describe your situation well, state your hard constraints, and then ask Claude to use its judgement on the discretionary choices rather than trying to pre-specify every decision.
The professionals who get the most out of Claude in the next year are likely to be the ones who learn when to direct and when to delegate — and who trust that the model’s judgement, given enough context, is often worth deferring to.
