Prompting Claude Fable 5June 2026

Orientation

Reading Anthropic, Prompting Claude Fable 5 — the official guide this chapter and all that follow adapt.

1.1The mindset shift

Fable 5 is built for end-to-end work that would take a person hours, days, or weeks — and Anthropic's strongest advice is to point it at your hardest unsolved problems first. Teams that test it only on simple tasks consistently underestimate it.

Every recommendation in the official guide is framed as a delta from Opus 4.8. If your prompts, skills, or CLAUDE.md files were tuned for earlier models, parts of them now actively hurt: step lists, tool nudging, and enumerated "always do X" rules become constraints the model obeys even when they're wrong for the task. Capability improvements at this level are a good prompt to re-evaluate which instructions, tools, and guardrails are still needed at all.

1.2Where it's stronger

The capability jumps worth designing around: long-horizon autonomy (multi-day goal-directed runs with instructions retained throughout); first-shot correctness (well-specified complex systems often land in a single pass); vision (dense technical images read far more accurately, with the model cropping and preprocessing noisy images on its own); enterprise output (spreadsheets, slides, financial analysis, and documents at professional quality); code review and debugging (meaningfully higher bug-finding recall, including across repository history); ambiguity (hand it a tangled multi-threaded request and ask it to decide next steps); and delegation (far more dependable at dispatching and coordinating parallel subagents).

Behavior

2.1Longer turns by default

Single requests can run many minutes at higher effort; autonomous runs can stretch to hours. This is the biggest migration shock: raise client timeouts, add streaming and progress indicators, and restructure harnesses to check in asynchronously rather than blocking. To stop the model from overplanning on ambiguous tasks:

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 in user-facing messages. If you are weighing a choice, give
a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

2.2Effort levels

Effort is the main dial trading intelligence against latency and cost. Fable's lower settings often still beat prior models at their maximum — drop the effort if tasks finish fine but take too long, or when you want a snappier interactive feel.

High effort buys rigorous verification, but it also tempts the model into gold-plating. To prevent unrequested refactors and speculative engineering:

Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a
helper. Don't design for hypothetical future requirements: do the simplest thing that
works well. Avoid premature abstraction and half-finished implementations. Don't add
error handling, fallbacks, or validation for scenarios that cannot happen. Trust
internal code and framework guarantees. Only validate at system boundaries (user input,
external APIs). Don't use feature flags or backwards-compatibility shims when you can
just change the code.

2.3Instruction following

You no longer need to enumerate every unwanted behavior — one short instruction steers a whole family of them. Un-steered at high effort, Fable can survey options it won't take, over-explain root causes, and over-structure write-ups. A brief brevity instruction handles all of it:

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.

The way to keep output short is to be selective about what you include (drop details
that don't change what the reader would do next), not to compress the writing into
fragments, abbreviations, arrow chains like A → B → fails, or jargon.

The same principle governs checkpoints in long workflows — define the category, not the case list:

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.

Long Runs

3.1Ground progress claims

On long autonomous runs, require every status claim to trace back to a tool result. Anthropic reports this nearly eliminated fabricated progress reports, even on tasks designed to provoke them:

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. Report outcomes faithfully: 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.

3.2State the boundaries

Fable can occasionally act when you only wanted analysis — drafting an email nobody asked for, creating defensive backup branches. Make the line between assess and change explicit:

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 (restarts, deletes, config edits), check that the evidence actually
supports that specific action. A signal that pattern-matches to a known failure may have
a different cause.

3.3Parallel subagents

Fable delegates readily — lean into it. Tell it when delegation is appropriate, prefer asynchronous communication over blocking on each subagent, and keep subagents long-lived so they retain context across subtasks: cheaper through cache reads, and you're never bottlenecked on the slowest one.

Delegate independent subtasks to subagents and keep working while they run. Intervene
if a subagent goes off track or is missing relevant context.

For self-verification on long builds, fresh-context verifier subagents beat self-critique. Tell the model to establish a checking method and run it on a schedule:

Establish a method for checking your own work at an interval of [X] as you build. Run
this every [X interval], verifying your work with subagents against the specification.

Memory & Edge Cases

4.1Construct a memory system

Fable shines when it can record lessons across runs, and a folder of Markdown files is enough — the rules matter more than the infrastructure:

Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.

To seed the system from existing history:

Reflect on the previous sessions we've had together. Use subagents to identify core
themes and lessons, and store them in [X]. Make sure you know to reference [X] for
future use.

4.2Rare cases of early stopping

Deep into a long session, Fable can occasionally announce its next step ("I'll now run X") and end the turn without doing it, or ask permission it doesn't need. A simple "continue" recovers it. For unattended pipelines, prevent it up front:

You are operating autonomously. The user is not watching in real time and cannot answer
questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For
reversible actions that follow from the original request, proceed without asking.
Offering follow-ups after the task is done is fine; asking permission after already
discussing with the user before doing the work is not. Before ending your turn, check
your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or
a promise about work you have not done ("I'll…", "let me know when…"), do that work now
with tool calls. End your turn only when the task is complete or you are blocked on
input only the user can provide.

4.3Rare cases of context-budget anxiety

In very long sessions, Fable may offer to summarize and hand off to a fresh session — usually because the harness is showing it a remaining-token countdown. Hide those counters where you can; where you can't, reassure it:

You have ample context remaining. Do not stop, summarize, or suggest a new session on
account of context limits. Continue the work.

Communication

5.1Give the reason, not only the request

Fable performs better when it knows why you're asking — intent lets it connect the task to the right information instead of guessing. Especially for agents spanning multiple workstreams, frame requests like this:

I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].

5.2Readable summaries

After many tool calls, Fable's working shorthand — arrow chains, invented labels, references to reasoning you never saw — can leak into its final message. Separate the working voice from the reporting voice:

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity
there is good). Your final summary is different: it's for a reader who didn't see any of
that.

If you've been working for a while without the user watching (overnight, across many
tool calls, since they last spoke), your final message is their first look at any of it.
Write it as a re-grounding, not a continuation of your working thread: the outcome
first, then the one or two things you need from them, each explained as if new. The
vocabulary you built up while working is yours, not theirs; leave it behind unless you
re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete
sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels
you made up earlier. When you mention files, commits, flags, or other identifiers, give
each one its own plain-language clause. Open with the outcome: one sentence on what
happened or what you found. Then the supporting detail. If you have to choose between
short and clear, choose clear.

Scaffolding

6.1Create a send-to-user tool

For long asynchronous agents, add a client-side tool that surfaces a message to the user verbatim without ending the turn — deliverables, progress updates with real numbers, or mid-loop replies. Tool inputs are never summarized, so content arrives intact. Render the input directly in your interface and return a simple acknowledgement:

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

Skip it for agents that only narrate routine progress — the model's own summaries are usually fine there.

6.2Migration checklist

Five moves when bringing existing systems over. Start at the top of your difficulty range: assign something harder than you'd give prior models, and let Fable scope it and ask clarifying questions. Make self-verification explicit, with fresh-context verifier subagents rather than self-critique. Refactor old prompts and skills: skills written for prior models are often too prescriptive and degrade Fable's output — strip them back and compare against default behavior; Fable also updates skills on the fly as it learns. Never ask it to echo its reasoning: "show your thinking" instructions can trip the reasoning_extraction refusal and bounce requests to Opus 4.8 — audit migrated prompts for these, and read structured thinking via adaptive thinking instead. And add the send-to-user tool anywhere your experience depends on verbatim mid-task delivery.