Forge Field Guide No.01 · July 2026
The Fable 5 Guide
Stop prompting it like a chatbot. Start briefing it like the most capable worker you have ever hired. Here is how to actually get the best out of it.
A plain-English working guide to Claude Fable 5, published by Ferrox Labs for The Forge AI community: everyday users and builders alike. Where AI builders sharpen their craft.
One idea changes everything
If you only remember a single thing from this guide, make it this. The rest is detail.
Older models were assistants you steered step by step. Fable 5 is a worker you brief once and let run. Give it the goal, the reason, and the boundaries, then get out of its way.
The instinct most people carry over from earlier AI is to spell out every step: do this, then that, always check this first, format it like so. That style helped weaker models stay on track. With Fable 5 it backfires. The model is strong enough to plan its own route, and a wall of step-by-step instructions just becomes a cage it will obey even when your instructions are wrong for the task in front of it.
This is the official line from Anthropic, not our opinion. Their own guidance says instruction-following is now strong enough that a short instruction does the work of a long checklist, and that prompts written for older models are often too prescriptive and can make Fable 5 worse.
What this guide gives you
- The mindset shift, in plain language, so you know why the old habits stopped working.
- The one dial that controls almost everything: effort.
- Five habits anyone can use today, with real examples.
- A copy-paste prompt library taken straight from the official docs.
- A builder section for coders running agents, plus the traps to avoid.
- A one-page cheat card and a glossary for newcomers.
You do not need to be a coder. Most of this guide is about how you write your requests. Skip the builder section if it is not for you. Everything else applies whether you use Claude for work, study, or sorting out your week.
The mindset shift
From micromanaging steps to setting direction
Picture two ways of working with a brilliant new hire. One way, you hover and dictate every keystroke. The other, you explain what you need and why, set a few hard rules, and check the result. Fable 5 thrives on the second. Here is the same request done both ways.
The old way (fights the model)
- × Long numbered step lists for every task
- × "Always do X before Y" rules baked in
- × Telling it exactly which tool to use, when
- × Re-pasting context it already has
- × Asking for one tiny step, then the next
The new way (works with it)
- ✓ State the goal and the finished result you want
- ✓ Give the reason behind the request
- ✓ Name the few hard boundaries that matter
- ✓ Let it choose the route and the tools
- ✓ Hand it the whole job and review the output
An everyday example
First make a list of 5 cities.
Then for each city find 1 hotel.
Then make a table.
Then add prices in column 3.
Then sort by price...
Plan a 5-city europe trip for
my family of 4 in August, mid
budget. We care about walkable
old towns and short train hops.
Give me a day-by-day plan with
rough costs.
The model now knows who it is for, the constraints, and what good looks like. It fills the gaps with sensible judgment instead of waiting for you to feed it the next instruction. You get a finished answer in one go.
The effort dial
The single most useful setting to understand
Fable 5 has a control called effort. It decides how hard the model thinks before it answers. More effort means deeper reasoning and better results on hard work, but slower replies and higher cost. Less effort means fast, snappy answers that are still very good. Think of it as the gear you are driving in.
| Setting | Reach for it when |
|---|---|
| low / medium | Quick questions, drafts, tidying, anything where you want a fast back-and-forth feel. |
| high | Your default for almost everything. Real work that you want done properly. |
| xhigh | The genuinely hard, high-stakes jobs where getting it right matters more than speed. |
Maxing out effort on everything is the wrong default. Even on lower settings, Fable 5 often beats older models running flat out. Match the gear to the job. If a task finishes correctly but took longer than it should have, drop the effort down rather than reaching for a longer prompt.
At higher settings the model sometimes does more than you asked: extra cleanup, tidying, surveying options it will not use. That is not a fault, it is enthusiasm. The boundary prompts later in this guide tell it to rein that in.
Five habits anyone can use
No coding required. Start with these today.
Lead with the goal and the reason
Tell it what you want and why it matters. "Write a polite chase-up email to a supplier who is two weeks late, because the delay is holding up our launch." The reason shapes the tone and the choices.
Hand over the whole job, not slivers
Resist breaking a task into tiny steps. Give it the full task and let it work end to end. "Take this messy spreadsheet of expenses, categorize it, total each category, and flag anything that looks off."
Name your hard boundaries
If something must not happen, say so plainly. "Do not send anything, just draft it for me to review." One clear line beats a paragraph of caveats.
Ask for the headline first
Fable 5 can be thorough to a fault. Tell it how you want the answer. "Give me the bottom line in one line, then the detail underneath."
If it pauses, just say go
Deep in a long task it may occasionally stop and ask permission, or say what it is about to do without doing it. A simple "continue, do it end to end" gets it moving again.
Every habit is about giving direction, not dictation. You are the one who knows the goal, the audience, and the limits. Supply those clearly and the model handles the how.
Copy-paste prompt library
Verbatim from Anthropic's official guide. Drop these in as-is.
Paste these into your system prompt or the start of a chat to steer common behaviors. Each one replaces a whole checklist of fiddly instructions.
Lead with the outcome. Your first sentence after finishing should
answer "what happened" or "what did you find": the thing the user
would ask for if they said "just give me the TLDR." Supporting detail
and reasoning come after. Being readable and being concise are
different things, and readability matters more.
When you have enough information to act, act. Do not re-derive facts
already established in the conversation, re-litigate a decision the
user has already made, or narrate options you will not pursue. If you
are weighing a choice, give a recommendation, not an exhaustive survey.
Pause for the user only when the work genuinely requires them: a
destructive or irreversible action, a real scope change, or input
that only they can provide. If you hit one of these, ask and end the
turn, rather than ending on a promise.
I'm working on [the larger task] for [who it's for]. They need
[what the output enables]. With that in mind: [request].
For longer, hands-off work
When you set Fable 5 loose on a big task and step away, these keep it honest and on-scope.
Before reporting progress, audit each claim against a tool result from
this session. Only report work you can point to evidence for; if
something is not yet verified, say so explicitly. If tests fail, say so
with the output; if a step was skipped, say that; when something is
done and verified, state it plainly without hedging.
When the user is describing a problem, asking a question, or thinking
out loud rather than requesting a change, the deliverable is your
assessment. Report your findings and stop. Don't apply a fix until they
ask for one. Before running a command that changes system state, check
that the evidence actually supports that specific action.
Don't add features, refactor, or introduce abstractions beyond what
the task requires. Don't design for hypothetical future requirements:
do the simplest thing that works well. Don't add error handling or
validation for scenarios that cannot happen. Only validate at system
boundaries (user input, external APIs).
Pick the one that matches the behavior you want to change. Stacking every block into one prompt is the old habit creeping back. A short, targeted instruction is the whole point.
For builders and coders
Running agents, harnesses, and long autonomous jobs
If you are wiring Fable 5 into your own tools, three patterns matter most. Skip this section if you only use the chat.
Lean on subagents
Fable 5 dispatches parallel subagents far more readily than older models. Encourage it, and prefer async communication over blocking on each one to return.
Delegate independent subtasks to subagents and keep working while
they run. Intervene if a subagent goes off track or is missing
relevant context.
Give it a memory file
It performs noticeably better when it can record lessons from past runs and read them back. A plain Markdown file is enough.
Store one lesson per file with a one-line summary at the top. Record
corrections and confirmed approaches alike, including why they
mattered. Update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.
For autonomous pipelines, set the rules
When nobody is watching live, tell it so. This stops it blocking on a question that will never get answered.
You are operating autonomously. The user cannot answer mid-task, so
asking "Want me to...?" will block the work. For reversible actions
that follow from the original request, proceed without asking. End
your turn only when the task is complete or you are blocked on input
only the user can provide.
On long builds, have a separate, fresh-context subagent check the work against the spec at intervals. Anthropic found this beats asking the model to critique itself.
The traps to avoid
The mistakes that quietly cost you results
Custom instructions, prompt templates, and skills tuned for older models can actively make Fable 5 worse. Anthropic says so directly. When you move over, strip the old scaffolding back and only add an instruction once you see the default behavior fall short.
For builders: prompts that tell the model to echo, transcribe, or explain its internal reasoning as the response can trip a safety category and silently fall back to a different model. If you need reasoning visibility, read the structured thinking output instead of asking for it in the answer.
Fable 5 runs safety checks that refuse offensive cybersecurity work (building exploits, malware, attack tooling) and biology or life-sciences lab detail. Even some harmless requests near those topics can get caught. If you hit a wall there, that is by design, and an older model is the right tool for the legitimate version of that work.
Hard tasks can run for minutes, and hands-off jobs for hours. If you build on it, raise your timeouts and add progress indicators. If you chat with it, do not assume silence means it is stuck. It is thinking.
The one-page cheat card
Everything above, boiled down to what fits on a sticky note.
- Brief it, do not boss it. Goal plus reason plus boundaries, then let it run.
- high is your default. Use it for almost everything.
- xhigh for your hardest, highest-stakes jobs only.
- low / medium for quick, chatty, throwaway work.
- Too slow? Lower the effort before lengthening the prompt.
- Lead with the goal and the reason.
- Hand over the whole job, not slivers.
- Name your hard boundaries plainly.
- Ask for the headline first.
- If it pauses, say "continue, end to end."
- Do not paste old step-by-step templates in wholesale.
- Do not over-instruct. One line beats a checklist.
- Do not assume a long pause means it is broken.
Words you will see
A quick glossary, in case any of the terms above were new.
- Effort
- A setting that controls how hard the model thinks before answering. Higher means deeper and slower, lower means fast and lighter.
- Prompt
- What you type to the model. Your request, plus any context and rules you give it.
- System prompt
- A set of standing instructions that apply to a whole conversation or app, set once at the top rather than typed each time.
- Agent
- The model working on its own across many steps, using tools, rather than just answering a single question.
- Subagent
- A helper instance the main model spins up to handle a piece of the job in parallel, then reports back.
- Tool / tool call
- Something the model can use beyond writing text: searching the web, running code, reading a file, and so on.
Now go put it to work.
Got a result worth sharing, or a prompt that cracked something open? That is exactly what the community is for. Bring your wins, your questions, and your experiments. We figure this stuff out together.