Claude Fable 5.1 prompt guide: 16 tips and an agent runtime migration checklist

Background: if the model got better, why do we still need a prompting guide?

The changes in Fable 5.1 go beyond "smarter answers." The model is better at executing complex tasks over long stretches, adaptive thinking is always on, and developers can use the effort parameter to trade off quality, latency, and cost. Meanwhile, thinking blocks are now more tightly bound to the conversation, which makes tool-loop observability, message history organization, and token allocation for long outputs more important than before.

That means the same failure can originate at very different layers:

• The model didn't search: this may just be behavioral tendency under low effort;
• The agent goes silent for a long time: the client may not be requesting or displaying progress updates;
• A multi-turn request suddenly returns 400: the client may have rewritten an old message and broken the prefix binding of a thinking block;
• The lead agent waits on a subagent that never finishes: the tool that spawns the subtask may have been designed as a blocking call;
• A long report stops halfway: thinking plus the final answer may have together exhausted max_tokens.

So despite the "Prompting" label, this guide actually covers model parameters, API configuration, message protocol, agent orchestration, code editing, and front-end rendering. Changing only the system prompt won't fix half of these problems.

The core idea: identify which layer a symptom belongs to, then apply the matching fix

The official 16 recommendations are organized as "if you see X, check chapter Y." Mapped onto a real product, they collapse into four control surfaces:

1. Thinking budget: which effort level to pick for a given task, and when to step up or down;
2. Tools and interface: how to surface progress, batch tool calls, and schedule subagents asynchronously;
3. Message history: why it must be append-only, and how to safely add temporary rules and compress context;
4. Delivery constraints: requiring full completion while preventing scope creep, whole-file rewrites, or excessive test commits.

Check before you migrate

• Stop using tool_choice: "any", and don't force a specific tool;
• Don't let older models read thinking blocks generated by Fable 5.1;
• Don't edit old messages that already contain thinking blocks.

One: Set the thinking level first (recommendation 1)

1. Don't reuse old effort settings; re-test every level

Symptom: task quality is fine, but latency or cost is higher than needed; or the team simply copied Fable 5's effort configuration over to 5.1.

Why it happens: the same label—medium or high—does not mean the same amount of thinking across different models. Fable 5.1's gains apply across all effort levels, with bigger improvements at the high end, but not every task needs the highest setting.

Anthropic suggests starting with the default high, then testing low, medium, xhigh, and max against your own evals. The company's observation is that medium roughly matches Fable 5's quality at lower cost, and that low can be very competitive on single-task cost for some workloads, so it's worth comparing against smaller models with high effort settings too.

The takeaway is not "low beats Opus and Sonnet across the board." The official language is hedged with "roughly," "often," and "competitive." Production decisions should track real task success rates, total tokens, number of tool-calling turns, wall-clock time, search trigger rate, and rework rate.

This recommendation is mostly implemented through evaluation and routing; it does not require adding a fixed prompt to the model.

Two: Fix the tool loop (recommendations 2–3)

2. Let users see progress on long tool tasks

Symptom: the agent calls tools continuously for minutes without saying anything, and the user thinks it's stuck. The final reply only explains the last step without giving a full recap.

Why it happens: Fable 5.1 puts brief progress notes into progress-update thinking blocks, but the default thinking.display is "omitted", which leaves those blocks empty on the client side. The model may well have produced progress; the client just never requested or displayed it.

First, change the API request:

{
  "thinking": {
    "type": "adaptive",
    "display": "updates"
  },
  "betas": [
    "thinking-display-updates-2026-08-18"
  ]
}

Clients should render non-empty thinking blocks as short status lines. If you also want event-by-event summarized reasoning, use display: "summarized". These are user-facing progress summaries, not raw chain-of-thought, and they are not reliable execution receipts. Whether a task actually started and finished should still be proven by the orchestrator's attempt and run IDs, tool results, and error states.

If the product needs more stable textual progress, or the front end hides command output, combine both constraints:

English
Before starting, state in one sentence what you are about to do. During longer tasks, give brief updates on what you just found and what you are doing. End with a self-contained recap covering the findings, the work actually completed, and anything still outstanding.

Only you can see the full output of this command; the user interface shows at most a few lines. Put anything the user needs to read in your reply.

中文
开始工作前，用一句话说明你将要做什么。执行较长任务时，用简短更新说明刚刚发现了什么、正在做什么。结束时给出一份可以独立阅读的简要复盘，包括发现、实际完成的工作和仍需处理的事项。

这条命令的完整输出只有你能看到，用户界面最多显示其中几行。凡是用户需要阅读的信息，都必须写进你的回复。

3. Put independent tool calls in the same turn

Symptom: when the user explicitly asks for A, B, and C, the model usually parallelizes. But in coding or computer-use loops, when the model derives its own next batch of read operations, it often calls only one tool per turn.

Why it happens: explicitly parallel requests are easy to recognize; implicit independent reads that arise during environment exploration require the model to plan ahead. Each extra turn adds another model call, more context tokens, and more network round-trip time.

English
First list privately what information you need next. Then request every independent item in this turn, leaving only genuinely dependent requests for a later turn.

中文
先在内部列出下一步需要取得的信息；然后在这一轮中一次性请求所有互不依赖的项目。只有确实依赖前一个结果的请求才留到下一轮。

This reminder is best re-appended after every tool_result. Use a turn-scoped system message:

{
  "role": "system",
  "content": "Batch independent calls.",
  "clear_at": "next_user_message"
}

It requires the beta header mid-conversation-system-clear-at-2026-08-21. Append a fresh copy each turn, but do not delete or rewrite old copies; once a later user message arrives, the API makes the earlier turn-scoped reminder invisible to the model.

Three: Protect message history and control expression (recommendations 4–7)

4. Keep message history append-only

Symptom: multi-turn requests fail with 400 bound to a different conversation; or, after enabling a test configuration, the server discards earlier thinking blocks.

Why it happens: a thinking block in Fable 5.1 is bound to the exact conversation prefix that existed when it was generated, including the top-level system, the tool list, and all prior messages. For accounts created on or after 2026/8/31 at 00:00 UTC, this validation is on by default.

The right approach is to treat the conversation as an append-only log: whatever the assistant returns, put that turn back into history verbatim, including thinking blocks. New user messages, tool results, and rules keep getting added at the end. Do not edit, reorder, or delete old messages, and don't replace the top-level system or the tools that already participated in the conversation.

If you need to change rules mid-conversation, append a mid-conversation system message. For a single-turn reminder, use a turn-scoped system message with clear_at: "next_user_message". To trim context, prefer server-side compaction or context editing.

If the client does its own compression, the safest simple approach is to start a fresh history that contains only a full summary and the latest user instruction, without replaying old thinking blocks. In a test environment, set prefix_mismatch_behavior to "drop_block" and inspect input_transformations to find which old messages in your integration are being modified.

5. Cut flashy, mannered prose

Symptom: sentences get longer, paragraph density goes up, and plain information gets dressed up in metaphors that show off the writer's posture.

Why it happens: Fable 5.1 is generally a better writer, but some tasks still push it toward rhetoric instead of precision. Anthropic calls this anti-pattern "mannered prose."

English
Remove all mannered prose. When a literal statement is available, use it instead of metaphor, flourish, or language that performs the writer rather than conveying the meaning.

中文
删除所有矫饰性表达。能直接说明时就直接说明，不要用隐喻、漂亮话或写作者姿态替代准确含义。

6. Format by information structure; drop the old blanket "no formatting" rules

Symptom: replies become dense, unbroken walls of plain text; complex comparisons get no lists, headings, tables, or quotes.

Why it happens: early models overused bold and lists, so many old system prompts banned formatting outright. Fable 5.1 itself reaches for structured formatting less often, and the two together hurt readability.

English
Use lists, headings, or tables when the content has multiple parallel aspects, steps, or exact comparisons and the structure improves clarity. Use plain paragraphs for ordinary conversation, and follow explicit requests for minimal formatting.

中文
当内容包含多个并列方面、步骤或精确比较时，使用列表、标题或表格提高可读性。普通对话保持自然段；用户明确要求极简格式时，遵从该要求。

7. Paraphrase search results in your own words; keep only a few short, clearly marked quotes

Symptom: when summarizing a webpage, the model keeps the source's wording without quotation marks, and the reader can't tell paraphrase from original.

Why it happens: a generic instruction like "don't copy the source" is too vague. Anthropic recommends giving the model a full few-shot example inside the system prompt—user question, retrieval action, a good answer, and a <rationale>—so it can see the right way to compare and paraphrase.

You can use the shortened bilingual template below, then replace it with your own tool names and business cases.

English
<example>
<user>Retrieve Source A and Source B on the same event and compare them.</user>
<response>State the facts both sources confirm in your own words, then compare what each emphasizes. Keep at most one necessary short phrase verbatim and mark it with quotation marks; paraphrase everything else.</response>
<rationale>The answer is organized around agreement and difference rather than walking through each article. Source views are reported indirectly, and the only verbatim phrase is clearly marked.</rationale>
</example>

中文
<example>
<user>检索来源 A 和来源 B 对同一事件的报道，并比较两者。</user>
<response>先用自己的话说明两者共同确认的事实，再比较各自强调的角度。只保留一个确有必要的短语原文，并明确加引号；其余内容全部转述。</response>
<rationale>回答按共同点与差异组织，没有逐篇复述；来源观点使用间接引语，唯一的原文短语有明确引号。</rationale>
</example>

Four: Let long tasks finish cleanly while limiting scope (recommendations 8–10)

8. Require the model to complete the task, not announce it

Symptom: the model ends with "next I will modify…" but never actually modifies anything; or it keeps asking "should I continue?" for steps that were already part of the original request.

Why it happens: in a long task, the model may treat a single turn as a progress report. The fix is to define the autonomy boundary clearly while still keeping stopping points for destructive operations and genuine scope changes.

English
You are operating autonomously. The user is not watching in real time and cannot answer repeated confirmations during execution. Proceed with every reversible step already authorized by the request and consistent with its intent. Stop only for destructive actions or genuine scope changes that require the user's decision.

Before ending, inspect your final paragraph. If it is still a plan, a question, a list of next steps, or a promise of unfinished work, keep using tools and complete the in-scope work. End only when the task is complete or blocked on information only the user can provide.

中文
你在自主执行任务。用户不会实时守在电脑前，不能回答执行途中的重复确认。凡是原请求已经授权、符合原意且可逆的步骤，直接执行；只有破坏性操作或必须由用户决定的真实范围变化才停下询问。

结束前检查最后一段：如果它仍是计划、问题、下一步清单，或承诺尚未完成的工作，就继续使用工具把范围内的工作做完。只有任务完成，或确实缺少只有用户才能提供的信息时，才结束本轮。

This rule needs one explicit exception: when the user is only asking a question, describing a problem, or requesting a diagnosis, the deliverable is an analysis—not permission to automatically implement fixes.

9. Tell the context compressor what must be preserved

Symptom: after a long conversation is compressed, the model forgets rejected alternatives, the user's exact wording, the current completion boundary, or exact code identifiers, and starts investigating from scratch or repeating questions.

Why it happens: "summarize the conversation" only asks for shorter; it doesn't define which information, if lost, would break subsequent execution. Server-side compaction is already tuned for this. If you write your own client-side summary, you have to provide a preservation contract.

English
Create a summary that a new context window can use to continue the work. Preserve completely: (1) obstacles and how they were resolved; (2) approaches proposed, tried, or rejected and why; (3) the user's explicit preferences, constraints, decisions, and boundaries, keeping their wording where possible; (4) the exact current state and completed scope; (5) unresolved, promised, or required next work; and (6) hard-to-reconstruct details such as names, numbers, dates, exact wording, links, and code identifiers.

Prefer completeness over brevity for these items. Compress the assistant's explanations and reasoning to their conclusions and produced results.

中文
请生成一份可供新上下文继续执行的摘要。必须完整保留：
1. 已遇到的阻碍及处理结果；
2. 提出、尝试或否决过的方案及原因；
3. 用户明确提出或确定的偏好、限制、决定与边界，尽量保留原话；
4. 当前具体进展和已经完成的范围；
5. 仍未解决、已经承诺或下一步必须处理的事项；
6. 难以重建的精确细节，包括名称、数值、日期、原句、链接和代码标识符。

上述内容宁可写长也不要遗漏；助手自己的解释和推理只保留最终结论与产出。

10. Implement only what the request asks for, and keep permanent tests in check

What you'll see: The model finishes an open-ended coding task successfully, but then refactors nearby files, fixes unrelated bugs, extends behavior that was never requested, and commits a pile of tests that were only meant as temporary debugging aids.

Why it happens: Without explicit scope constraints, a directive to "complete the task thoroughly" can easily be read as license to fix every related problem at once. Official evals show that explicitly limiting extra work significantly cuts down on unrelated changes, without reducing the success rate on the actual request.

English
Implement only the behavior explicitly required by this task. If you find an unrelated pre-existing bug, performance concern, cleanup opportunity, or extension, do not change it here; report it as a follow-up. Use the interpretation most directly supported by the request and surrounding code instead of implementing every possible reading.

Use scratch scripts and quick checks as needed, but do not automatically commit them as permanent tests. Add focused tests only when the task asks for them or the repository already keeps tests for this kind of change, sized like neighboring tests. Implement every requested behavior completely.

中文
只实现本任务明确要求的行为。如果发现与本任务无关的旧 Bug、性能问题、清理机会或功能扩展，不要在本次修改中处理；在最终总结中列为后续建议。采用最符合请求文字和现有代码的解释，不要同时为其他可能解释也构建一套实现。

可以使用临时脚本和快速检查验证工作，但不要自动把它们提交为永久测试。只有任务明确要求，或仓库已经为同类改动保留测试时，才按相邻测试文件的规模增加聚焦测试。必须完整实现请求中的全部行为。

Five: Improve reliability in retrieval, editing, and long outputs (recommendations 11–14)

11. Trigger search explicitly at low effort

What you'll see: The model recognizes a name and answers from memory, but the information is stale because the name belongs to a fast-moving AI model, dev tool, or current event.

Why it happens: At low effort, Fable 5.1 calls search and retrieval tools less often than Fable 5 does. Sometimes simply raising the affected turn to a higher effort setting is enough; in other cases, you need to explicitly tell the model which facts must be verified.

English
When a query centers on a name you do not confidently recognize, or on a fast-moving area such as AI models, developer tools, prices, or current status, search before answering. Include the name exactly as the user wrote it in at least one query. Partial familiarity is not a reason to skip verification.

中文
当问题围绕你不能确信认识的名称，或来自数月内就可能变化的领域，例如 AI 模型、开发工具、价格和当前状态时，先检索再回答。至少一次搜索必须包含用户输入的名称原文。对名称有部分印象不是跳过搜索的理由。

12. Reduce false refusals through prompt wording and tool output design

What you'll see: A legitimate code review request returns stop_reason: "refusal".

Why it happens: Fable 5.1's safety classifier can still be triggered by certain phrasings, by niche languages that lack syntactic context, or by Base64 data that tools write directly into the conversation.

The official guidance suggests this typical rewrite:

English
Avoid: Does this program compile and run without errors?
Prefer: Are there any bugs in this program? Identify their locations and causes.

中文
不推荐：这段程序能否无错误地编译运行？
推荐：这段程序是否存在 Bug？请指出位置和原因。

For uncommon languages, give the model the official grammar or language documentation as background. Raw Base64 in tool output should be removed from the model's context and replaced with file references, MIME types, dimensions, hashes, or other controlled metadata. Just adding an outer tag around the data doesn't help. Clients must also parse stop_reason rather than treating an HTTP 200 status as task success.

13. Prefer local edits for small changes, don't rewrite the whole file

What you'll see: A change that touches only a few dozen lines causes the model to re-emit thousands of lines, increasing output token usage, latency, and the risk of merge conflicts.

Why it happens: Fable 5.1 is more inclined than Fable 5 to rewrite text files in full, even when the final content is nearly identical.

English
Minimize the tokens used to edit files when doing so does not affect the result. Prefer surgical, targeted edits for small changes. Rewrite the whole file only when it is short or most of its contents must change.

中文
在不影响最终结果的前提下，尽量减少编辑文件所需的 token。小范围改动优先采用外科手术式的局部修改；只有文件很短或大部分内容都需要变化时，才重写整份文件。

14. Reserve enough token space for long outputs at xhigh and max

What you'll see: The model spends a long time thinking before answering, and then a long report, code file, or large table gets cut off by max_tokens.

Why it happens: At xhigh, and especially at max, the model may draft large portions of the final artifact in its thinking phase, only to re-write that content later in the visible reply. Both the thinking and the reply consume the same per-response output limit.

The preferred approach is to start with high for long artifacts, and only move to xhigh or max when evaluation proves that the higher effort level improves quality. If you genuinely need the higher setting, set max_tokens generously and append the bound below to the user message.

English
Reasoning, drafting, and the final reply all count toward a total limit of about [max_tokens] tokens in this turn. Use reasoning to analyze inputs, verify dependencies, settle the structure, and resolve difficult decisions. Write the complete article, code, or table only once in the final reply. Do not draft the full deliverable in reasoning and then repeat it in the answer.

中文
本轮 reasoning、草稿和最终回复共同计入约 [max_tokens] token 的总上限。请在 reasoning 中分析输入、核对依据、确定结构并解决困难决策；完整文章、代码或表格只在最终回复中写一次。不要先在 reasoning 中全文起草，再在回复中重复一遍。

Six: Make subagents truly parallel, and give vision tools for zooming (recommendations 15–16)

15. The main agent shouldn't be blocked by subagent launch tools

What you'll see: The main agent delegates a subtask, then just waits for the result — so-called parallelism doesn't actually reduce wall-clock time.

Why it happens: If the tool call that "launches" the subagent doesn't return until the subtask completes, the model never gets a chance to do other useful work. Writing "run in parallel" in the prompt won't change a blocking tool interface.

A proper dispatch design has three components:

1. The subagent launch tool returns a task handle immediately;
2. The main agent continues with all work that doesn't depend on that result;
3. When the subagent finishes, inject the result back into the main agent via a subsequent user message. Also provide a wait tool that the model can call only when it truly needs to block.

The official observation is that models sometimes still choose to wait, but when the launch interface is non-blocking, the agent runs that do continue with other work achieve real wall-clock savings, with roughly equivalent average quality, tokens, and cost.

16. Dense charts and detailed diagrams need a crop-and-zoom tool loop

What you'll see: The model understands the overall thrust of an image, but misreads small text, coordinates, legends, or local relationships in a dense chart.

Why it happens: Squeezing an entire high-density image into a single visual input forces a finite number of visual tokens to carry both the global layout and the fine details. Fable 5.1 works better with an iterative observation approach: look at the full picture, decide which regions need closer checking, then crop, zoom, and re-read before returning to the full frame to confirm spatial relationships.

The full solution is to give the vision agent a container with the original image plus basic image-processing libraries like PIL and OpenCV. A cheaper alternative is to provide only a crop tool: the model submits coordinates, and the tool returns the enlarged region. The key is letting the model decide, based on its first pass, which region it needs to examine second.

Putting all 16 recommendations into practice: a risk-ordered migration checklist

If you just paste every bilingual prompt into a single system prompt, you end up with a huge rule set and no clear way to tell which rule made a difference. A safer migration order looks like this:

1. Check interface compatibility first: Remove the forced tool_choice, and verify how the thinking block is read and what fallback exists.
2. Next, inspect the message prefix: Log several real requests in a row to confirm that old system and tools sections and history messages haven't been edited.
3. Set up effort evaluations: Compare success rate, cost, latency, search triggers, and rework rate per task family.
4. Fix observability: Enable progress updates and use scheduler state to prove whether tasks are actually running.
5. Optimize the tool loop: Add batching reminders and make the subagent launch interface non-blocking.
6. Pair delivery rules: Require thorough completion on one side, and limit scope, tests, and whole-file rewrites on the other.
7. Handle output quality last: Only then add rules for style, formatting, citations, low-effort search, long outputs, and vision cropping.

The final evaluation shouldn't just ask whether the answer "feels more like 5.1." Compare whether the same task fails less often, involves less idle waiting, and uses fewer ineffective tool rounds; whether the agent can still continue after history compression; whether long artifacts are complete; and whether the model did everything it was authorized to do without touching anything outside that scope.

That's the core argument of this guide: prompts still matter for Fable 5.1, but they're now only one part of the agent runtime. Fix the interfaces and message protocols first, then use symptom-specific prompt changes as a final correction layer. That's the path to a stable, explainable, and measurable migration.