AI Guides › Workbench
By Nigel Guy · 7 min read
The usual move with a stronger model is to carry on prompting it the way you prompted the last one: a vague goal, a hopeful tone, and a quick "continue" whenever it stops. Claude Fable models behave differently enough that this goes wrong in three predictable ways. They run for longer than you expect, they occasionally do something you never asked for, and they hand work to sub-agents more readily than earlier models. Each failure has a short, specific fix.
The rule: give a Fable model three written decisions up front: when it stops, what it may not touch, and who is allowed to delegate. Everything else can be a plain statement of the goal and why you want it.
One naming note before the kit. The prompting guidance Anthropic published for Claude Fable 5 has since been joined by Claude Fable 5.1, released on 1 September 2026, which Anthropic's docs list as the latest version. The docs say existing Fable 5 prompts should perform well on 5.1 without changes, so the kit below works for both. Check which one you are actually running.
| Block | What it does | Cost | Best for | Catch |
|---|---|---|---|---|
| Stop rule | Tells the model when to carry on and when to halt and ask | Free: it is text in your prompt | Long, unattended runs | Can make it ask fewer questions about ambiguous requests, so check it on your own tasks |
| Fence | States what is out of bounds and that questions get findings, not changes | Free | Anything that touches files, systems or messages | Only covers what you thought to fence; keep it short |
| Delegation rule | Says when sub-agents are welcome and that the lead keeps working | Free, but sub-agents use more tokens | Work that splits into independent parts | Only works in a tool that actually supports sub-agents |
Where you pay for the model itself: in the API, Fable 5.1 is listed at $10 per million input tokens and $50 per million output tokens, which is about £7.50 and about £37 at time of writing. Check the £ price at checkout or in your billing dashboard, because exchange rates move. In consumer apps, access depends on your plan and the app, which I could not verify; check the model picker.
Fable models do long turns. On hard tasks at higher effort a single request can run for many minutes, and autonomous runs can stretch to hours, according to Anthropic's guide. Two problems follow. The model can overplan on ambiguous work, and deep into a long session it can end a turn by announcing what it will do ("I'll now run the tests") without doing it, or ask permission for a step you already requested.
Use this as your system prompt or the top of a task brief. Fill in the bracketed parts.
You are working for me on [PROJECT_OR_GOAL]. I will not be watching in real time, so questions you ask mid-task will block the work.
Context: this is for [WHO_IT_IS_FOR], and they need [WHAT_THE_RESULT_ENABLES].
Definition of done: [DONE_MEANS, e.g. "all tests pass and a short summary is written"].
Rules for stopping:
1. If a step follows directly from what I asked and can be undone, do it without asking.
2. Stop and ask only for: a destructive or irreversible action, a real change to the scope, or information only I can give. If you hit one, ask clearly and end your turn.
3. Before you finish, read your last paragraph. If it is a plan, a question, or a promise ("I'll...", "next I will..."), do that work now instead.
4. Before reporting progress, check each claim against something you actually ran or read this session. Say plainly what is verified and what is not.
5. If you are missing an input that only I can supply, list exactly what you need rather than guessing.
Final message: open with the outcome in one sentence, then the detail, written for someone who has not seen your working.
Fill in the project, audience, outcome and definition of done. The last two rules come straight from the problems Anthropic describes: invented progress reports on long runs, and summaries written in the model's own working shorthand.
Anthropic's guide says Fable 5 can occasionally take unrequested actions, giving the examples of drafting an email nobody asked for and creating defensive git-branch backups. The fix is to state limits, and to separate "I'm thinking aloud" from "make the change".
Scope: the task is [TASK_IN_ONE_SENTENCE]. Touch only [ALLOWED_FILES_FOLDERS_OR_SYSTEMS].
Do not: [LIST_OF_THINGS_OFF_LIMITS, e.g. send messages, delete anything, change settings outside the folder, install software].
If I am describing a problem, asking a question or thinking out loud, your deliverable is an assessment. Report what you found and stop. Do not apply a fix until I ask.
If you notice something else worth doing, such as a nearby bug or tidy-up, do not do it. List it under "Follow-ups" at the end.
Before any command that changes state (restart, delete, overwrite, config edit), check that the evidence supports that specific action. If it is ambiguous, say what you would do and why, and wait.
If the request is ambiguous, pick the reading the wording most directly supports, state your assumption, and carry on. Ask only if the readings would produce materially different work.
Fill in the task, the allowed area and the off-limits list. Keep the "do not" list to things that would genuinely hurt; a long list dilutes the short one.
Anthropic describes Fable 5 as significantly more dependable at dispatching and sustaining parallel sub-agents, and says it dispatches them more readily than earlier models. Its advice is to give explicit guidance on when delegation is appropriate and to avoid blocking on each sub-agent. For Fable 5.1 it adds that on coding tasks, letting the lead agent carry on while sub-agents run lowers average completion time at similar quality and cost, though the model still often chooses to wait.
You may delegate to sub-agents, but only for subtasks that are independent of each other and clearly bounded, for example [GOOD_SPLITS, e.g. "searching different parts of the codebase", "reading separate documents", "checking the finished work with fresh eyes"].
Do not delegate: [KEEP_IN_LEAD, e.g. final decisions, anything touching live systems, the summary to me].
For each sub-agent, give it: the goal, why it matters, the files or sources it may use, what to return, and the same fence that applies to you. Sub-agents inherit my scope limits; they do not widen them.
While sub-agents run, keep working on the parts that do not depend on them. If one goes off track or lacks context, step in.
Before you report a sub-agent's result as done, check it against the actual output, not its own summary.
Fill in the good splits and the keep-in-lead list. The guide also says fresh-context verifier sub-agents tend to beat self-critique, so "checking the finished work" is the first split worth allowing.
Effort is a separate dial. Anthropic's docs list high as the default and suggest testing low, medium, xhigh and max against your own checks; drop it where quality holds and cost or waiting matters.