Claude Fable 5 Practical Prompting Guide

1-1Instruct with one short principle instead of an enumeration

Because instruction-following has improved, you can steer most of the behavior with a single short principle rather than naming each desired behavior individually. With no instruction, Fable 5 at high effort can over-elaborate (listing options it will not pursue, giving verbose root-cause explanations, over-structuring PR descriptions), yet the single paragraph below is as effective as a whole list of forbidden patterns.

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 checkpoint (pausing) behavior in long-running workflows is also steered by a single principle rather than an enumeration of cases.

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.

1-2Make effort the primary control knob

effortFable 5's thinking-intensity setting (low / medium / high / xhigh). Raising it makes the model think more deeply but slower and more expensive. is the primary control for the trade-off between intelligence, latency, and cost.

• Most tasks: high by default
• Tasks where capability matters most: xhigh
• Everyday tasks: medium / low

Even low effort often exceeds the xhigh of previous models. If a task is taking longer than it needs to, or you want to work more interactively, lower the effort. High effort gives excellent verification behavior and the most rigorous output, but on routine tasks it can lead to excessive context-gathering and deliberation.

1-3State the boundaries: prevent over-work and unrequested behavior

At high effort the model can add unrequested cleanup, refactoring, abstractions, and unnecessary defensive code on its own. State the boundaries.

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.

For unrequested behavior (drafting an email that was not asked for, backing up a defensive git branch, and the like), define the boundary between what should and should not be done.

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.

1-4Prevent overplanning

To keep the model from planning in circles on ambiguous tasks, add the instruction below. The last sentence matters: it does not apply to thinking blocksThe record of the model's internal reasoning before it produces an answer. In Fable 5, only a summarized version is provided., so internal reasoning stays free.

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.

1-5Ground progress reports in evidence

In long autonomous runs, instruct the model to audit its progress against actual tool results. In Anthropic's testing, this instruction nearly eliminated false progress reports even on tasks designed to induce 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.

1-6Do not have it reproduce reasoning in the response text

Instructions that move or explain internal reasoning in the response text ("show your thinking," "explain your reasoning process," and the like) can trigger the reasoning_extraction refusalA response in which the model declines to process a request for safety reasons. In the API it is surfaced as stop_reason: "refusal". category and increase fallbackfallback. A backup path that automatically hands processing to another model when the primary model refuses or fails. to Opus 4.8.

• When migrating, audit existing skills and system prompts and remove reflection / show-your-thinking style instructions
• If you need reasoning visibility, read the structured thinking blocks from adaptive thinking
• If you need to surface progress during a long run, use a send-to-user tool (Part 2-7)

1-7Don't give only the request; include the reason (the intent)

Fable 5 performs better when it understands the intent behind a request. Rather than guessing the intent on its own, it connects to the relevant information. This is especially effective for long-running agents handling multiple workstreams.

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

1-8Write the final summary as a re-grounding

In long, tool-heavy agent conversations, you can get arrow-chain shorthand, excessive implementation detail, and references to thinking the user never saw. Have the model write the final summary not as a continuation of the working thread, but as a re-grounding for a reader seeing this for the first time.

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.

1-9Refactor existing prompts and skills by stripping them back

Skills and instructions written for previous models can be too prescriptive for Fable 5 and can actually lower output quality. If baseline performance is better, consider removing outdated instructions. A capability improvement is a good occasion to reassess which instructions, tools, and guardrails are still genuinely needed. Fable 5 is also good at updating skills on the fly based on what it learned during the work.

Part 1 Checklist

• 1
  Instead of a long "don't do" list, did you state the direction you want in one or two short principles?

  Show example
• 2
  Did you use high as the default effort, lower it for everyday tasks, and raise only the most critical tasks to xhigh?

  Show example
• 3
  Did you write down the boundary between "what may be done and what may not" so it doesn't do unrequested code cleanup, refactoring, or added features?

  Show example
• 4
  Did you make it report progress based only on actual execution results (tool output)?

  Show example
• 5
  Did you find and delete old instructions like "show your thinking" from prompts and skills (they can trigger refusals in Fable 5)?

  Show example
• 6
  Did you give not just the request but at least one line on "who it's for and what the output enables"?

  Show example
• 7
  Did you instruct the final report of a long task to be written for a "first-time reader" who can understand it immediately without having watched the process?

  Show example
• 8
  Did you revisit whether the detailed instructions and skills built for older models are still needed (over-instruction actually lowers quality)?

  Show example

2-1Tune infrastructure on the assumption of long turns

At high effort, a single request can take minutes, and autonomous runs can go for hours. This is one of the biggest changes teams encounter.

• Adjust client timeouts, streaming, and user-facing progress indicators before migrating
• Restructure the harness to check on runs asynchronously rather than blocking on them (e.g., scheduled jobs)
• Pair with the overplanning-prevention instruction for ambiguous tasks (Part 1-4)

2-2Operate the safety classifiers and refusal/fallback

Fable 5 runs safety classifiers aimed at the following.

• Offensive cybersecurity techniques (building exploits, malware, attack tools)
• Biology/life-science content (experimental methods, molecular mechanisms)
• Extraction of the model's summarized thinking

2-3Check for API parameter changes

Details are in the model introduction document; items to check when migrating:

• adaptive thinkingThe approach in which the model adjusts the amount of internal thinking on its own based on problem difficulty. only (no extended thinking budget)
• thinking output is summarized-only
• the refusal stop reason and fallback handling

2-4Build a memory system

Fable 5 does especially well when it can record and reference lessons from previous runs. A note space as simple as a single 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. 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 bootstrap 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.

2-5Design for parallel subagents

Fable 5 dispatches and manages parallel subagentssubagent. An auxiliary AI instance that the main agent hands off part of the work to. It works in parallel in its own independent context. more aggressively and more reliably than previous models.

• Have it use subagents often, and provide explicit guidance on when delegation is appropriate
• Prefer asynchronous communication over blocking between the orchestratororchestrator. The main agent in the conductor role, which divides work among multiple subagents and consolidates the results. and its subagents
• Long-lived subagents that retain context save time and cost through cache reads, and also avoid being bottlenecked by the slowest subagent

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

2-6Explicit self-verification: a fresh-context verification subagent

A separate verification subagent with fresh context is better than self-critique. For long-running work, instruct as follows.

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.

2-7Build a send-to-user tool

For long, asynchronous agents, build a client tool that delivers, without ending the turn, a message the user must see exactly as written. Targets: partial deliverables (a generated code snippet, a draft message), progress updates with concrete numbers, and direct answers to questions that came in mid-run. Tool input is not summarized, so the content arrives intact.

{
  "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"]
  }
}

• The tool definition alone is not enough: without phrasing in the system prompt that elicits the call, it will rarely call it
• Leaking narration or internal reasoning through this tool defeats its purpose (user-facing content only)
• For an agent that only narrates routine progress, the model's own summary is enough (no tool needed)

Between tool calls, when you have content the user must read verbatim (a partial deliverable, a direct answer to their question), call the send_to_user tool with that content. Use send_to_user only for user-facing content, not for narration or reasoning.

2-8Handling edge cases: early termination and context worries

Patterns that appear rarely in the later part of long sessions, and how to handle them:

System reminder for autonomous pipelines:

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.

Context reassurance line:

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

2-9Start at the top of the difficulty range

Pick tasks harder than what you would hand to previous models, and let Fable 5 scope them itself, ask clarifying questions, and execute. If you evaluate it only with easy tasks, you will underestimate the range of its capability.

Part 2 Checklist

• 1
  Did you adjust timeouts, streaming, and progress indicators so a single request taking several minutes doesn't get cut off?

  Show example
• 2
  Did you build a fallback path that automatically hands off to Opus 4.8 when the model refuses a request?

  Show example
• 3
  Did you reflect the changed API options (adaptive thinking only, thinking provided as a summary only, no thinking budget) in your code?

  Show example
• 4
  Did you provide a note space (a markdown file is enough) and recording rules for the model to write down lessons it learns while working?

  Show example
• 5
  Did you set criteria for using subagents to divide the work, and build a structure that doesn't stall waiting for them to finish?

  Show example
• 6
  Did you have the work checked periodically by a separate verification agent with clean context, rather than by the model itself?

  Show example
• 7
  Did you build a channel (the send_to_user tool) to deliver intermediate results to the user verbatim even mid-task, and include instructions on "when to use it"?

  Show example
• 8
  Are you not showing the remaining token count to the model? If you must, did you add a "context is ample, keep going" reassurance line?

  Show example
• 9
  Did you add a "don't ask, just carry it through to the end" reminder to automated pipelines that run unattended?

  Show example