Prompting Claude Fable 5.1: Every Behavior Shift and the Line That Fixes It

Claude Fable 5.1 Prompting: What Changed and How to Adapt

Anthropic says existing Fable 5 prompts should perform well on Claude Fable 5.1, but the behavior around those answers has changed: tool-call batching, progress updates, prose density, chat formatting, file-editing style, and autonomous task completion all behave differently. This guide maps each shift to a practical fix from the official prompting guide. For the model overview, see what Claude Fable 5.1 is.

Try Apidog today

Tune effort before changing prompts

Effort is the main control for intelligence, latency, and cost on Fable 5.1. Start with the default high setting, then evaluate low, medium, xhigh, and max against your own test suite. Repeat the sweep even if you already tested Fable 5; effort levels do not represent the same amount of thinking across models.

Anthropic recommends testing these hypotheses:

• Medium may approximate Fable 5 quality at lower cost.
• Low can be competitive with Opus and Sonnet on cost per task while scoring higher in some evaluations.
• Improvements over Fable 5 are largest at xhigh and max.

You can also change effort mid-conversation without resetting the cache by sending an empty-content system message with output_config and the mid-conversation-output-config-2026-07-01 beta header. See the Effort documentation and API walkthrough.

Put per-turn instructions in the right place

Fable 5.1 thinking blocks are valid only in the exact conversation that produced them. Editing an earlier turn—for example, injecting a reminder and deleting it on the next request—restarts the prompt cache and, for accounts created on or after August 31, 2026, invalidates every later thinking block.

Use one of these patterns for turn-scoped instructions.

With the mid-conversation-system-clear-at-2026-08-21 beta, append a system message after the tool result:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "Your turn-scoped instruction goes here."
}

Keep earlier copies in the conversation array. After the next user message, the API clears the older copies, so the model sees only the newest instruction and cleared copies consume no tokens.

Without the beta, place the instruction in a text block after the tool_result blocks in the same user message. Again, keep every earlier copy. Never delete or rewrite text that has already been sent.

See the preserved thinking documentation and the turn-scoped system message guide.

Use the system prompt or first user turn for session-level instructions. Anthropic reports that style instructions hold more reliably in the first user turn than in the system prompt.

Restore parallel tool calls in agent loops

When a request explicitly names several independent items, Fable 5.1 usually calls the tools in parallel. In coding and computer-use loops, however, it may issue one implied read per turn when Fable 5 batched several calls.

Measure before changing the [REDACTED PROMPT] assistant turns containing more than one tool call.

• Add the instruction only if parallelism has declined.
• Measure round trips, token usage, and wall-clock time as well.

Append this instruction after each tool-result message as a turn-scoped system message:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

Keep the word “privately.” Without it, the model may answer the reminder instead of continuing the task. A sentence near the end of the current request generally has more effect than the same sentence in the system prompt.

Make progress updates visible

Fable 5.1 often produces fewer user-facing updates during long tool-calling turns than Fable 5, especially at higher effort. Users may see no updates for several minutes or receive a final message that mentions only the last step.

Apply these fixes in order:

1. Confirm that progress updates are being returned. Between-tool notes arrive as thinking blocks and are displayed as "omitted" by default.
2. Enable display: "updates" with the thinking-display-updates-2026-08-18 beta header.
3. Render each non-empty thinking block as a status line.
4. Remove old instructions such as “hold all findings for the final response.”
5. If needed, add this to the system [REDACTED PROMPT]

If your product hides tool output, tell the model explicitly:

Only you see that command’s output. If the user needs to read any of it, put it in your reply.

Otherwise, it may run extra commands to “show” output the user cannot actually see.

Prevent premature turn endings

On complex asynchronous tasks, Fable 5.1 may describe the next action instead of taking it, or ask permission for work already covered by the request. This forces the user to reply “continue” and limits long-horizon execution.

Add this system-prompt block:

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. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission 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, 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.

Pair it with a scope rule:

• Treat the user’s request as the complete scope.
• Do not narrow, widen, or replace it.
• Finish every unblocked part and report anything omitted.
• Treat unrequested observations as suggestions, not changes.
• Add a separate sentence listing the confirmations that still require user input.

Unlike the Opus 5 prompting advice, keep instructions that tell Fable 5.1 to verify its work.

Prevent unrequested fixes and extra tests

Open-ended feature requests can produce nearby bug fixes, performance changes, extended behavior, or more test files than necessary.

Use this instruction:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

This reduces scope creep without discouraging complete implementation of the requested behavior.

Prefer targeted file edits

Fable 5.1 is more likely than Fable 5 to rewrite an entire file for a small change. The result may be correct, but it costs more output tokens and creates noisier diffs.

Add this to the system prompt or first user message:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

Reduce dense, mannered prose

Fable 5.1 generally writes better prose, but it can produce longer sentences and fewer paragraph breaks. Anthropic defines “mannered prose” as writing that uses metaphor and flourish to display the writer instead of conveying the idea directly.

Use a direct instruction:

Say what you mean and use the literal phrase when one is available. Please remove all mannered prose.

Restore useful formatting

Older models often overused bullets and bold text, so many prompts contain anti-formatting rules. Fable 5.1 tends to use less formatting, which means those rules can now suppress structure the reader needs.

Replace blanket anti-formatting instructions with a conditional rule:

Use lists when asked or when the content is multifaceted enough that they aid clarity. Honor explicit requests for minimal formatting. Use plain prose in conversational or emotional exchanges.

Mark quotations in summaries

When summarizing documents, Fable 5.1 is more likely than Fable 5 to reproduce source passages without clearly marking them as quotations.

Add one complete example to the system prompt containing:

1. The user’s request.
2. A correct response that summarizes each source in the assistant’s own indirect speech.
3. At most one short, clearly marked quotation.
4. A one-sentence explanation of why the response is correct.

Replace any tool-call placeholders in Anthropic’s example with your own tool name.

Make low-effort search behavior explicit

At low effort, Fable 5.1 may search and retrieve less often than Fable 5, particularly for named products and models it recognizes but has stale knowledge of.

Use either of these fixes:

• Raise effort for affected turns with per-message effort.
• Add this guidance to the system [REDACTED PROMPT] state. Search before answering, and include the name exactly as the user wrote it in at least one query.

Control long deliverables at xhigh and max

At xhigh and especially max, Fable 5.1 may draft a long deliverable in its thinking and then reproduce it in the final response. This doubles latency and output tokens.

Prefer high unless evaluations show a measurable gain at higher effort. If you use xhigh or max:

• Set max_tokens high enough for both thinking and the final response.
• Tell the user message that all content produced in one reply, including reasoning, counts toward one limit of approximately max_tokens.
• Explain that composing the deliverable in reasoning and then repeating it in the reply doubles the turn without improving the result.
• Keep earlier copies of that instruction in later requests.

Reduce false refusals on benign coding tasks

Fable 5.1’s classifiers produce fewer false positives than Fable 5 at launch, and finding vulnerabilities in source code is permitted. False positives can still occur.

Try these changes:

• Ask, “Are there any bugs in this program?” instead of “Does this program compile without errors?”
• Provide documentation for lesser-known languages.
• Remove tools that inject base64-encoded data into context.
• Keep fallback behavior configured regardless of the expected result.

See the refusal handling guide.

Preserve details during client-side compaction

Fable 5.1 responds well to explicit compaction requirements. Server-side compaction already preserves these details. For client-side compaction, instruct the model to write inside <summary> tags and retain the following in order:

1. Difficulties and how they were resolved.
2. Approaches that were proposed or rejected, and why.
3. Everything requested or decided, stated exactly.
4. The current state.
5. Open items.
6. Hard-to-reconstruct details such as names, numbers, and links.

End with:

Do not call any tools while writing this summary; respond with text only.

This is important when the summarization request still includes the conversation’s tools.

Use architecture for subagents and vision

Two improvements are architectural rather than prompt-based.

For coding tasks:

• Let the lead agent continue while subagents work.
• Have the subagent-starting tool return immediately.
• Deliver each subagent result in a later user message.
• Give the lead agent a separate tool it can call when it wants to wait.

For dense charts and nested tables:

• Provide a crop tool that returns a selected region at a larger size, or
• Provide a container with basic image libraries.

At low effort, the model may skip cropping, so inspect tool-call logs to confirm it used the capability when needed.

Test prompt changes in Apidog

Treat every fix as a before-and-after experiment:

1. Save the first three turns of your agent loop as a request sequence in Apidog.
2. Parameterize the system prompt.
3. Run the sequence with and without one snippet at the same effort.
4. Compare task success, latency, and token usage.

Useful assertions include:

• Tool batching: Count tool_use blocks per assistant turn.
• Targeted edits and prose density: Compare usage.output_tokens.
• Autonomy: Assert that the final paragraph does not start with “Next, I”.
• Progress: Verify that non-empty update blocks are displayed.

Download Apidog to build the test sequence. The Claude Code guide shows which instructions belong in CLAUDE.md.

FAQ

Do my Fable 5 prompts work on Fable 5.1?

Anthropic says they should perform well without changes. The main differences are behavioral: fewer batched tool calls in some loops, fewer progress updates, denser prose, less chat formatting, whole-file rewrites, and scope creep on open-ended tasks.

What effort level should I use?

Start at high and run an evaluation sweep. Anthropic reports that medium can approximate Fable 5 at lower cost, while low can be competitive with Opus and Sonnet on cost per task.

Where should I put a per-turn instruction?

Use a turn-scoped system message with:

"clear_at": "next_user_message"

Place it after the tool results and keep earlier copies in the conversation. Editing earlier turns invalidates later thinking blocks and restarts the cache.

Should I remove “verify your work” instructions?

No. That advice was specific to Opus 5’s over-verification behavior. Keep verification instructions for Fable 5.1.

How do I stop whole-file rewrites?

Add this sentence to the system prompt or first user message:

Minimize tokens used to edit files and surgically edit rather than rewrite when doing so does not affect the result.