Fixing Overplanning: One Line to Make It Act Once It Has Enough

Whenever a task gets ambiguous or effort is set high, Fable 5 tends to overthink: re-deriving facts already established in the conversation, listing options it was never going to take anyway, dragging out the preamble. The instruction below tells it to act as soon as it has enough information.

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.

A related engineering-side note that pairs with this section: long-horizon autonomy means the model can work unsupervised for a long stretch — hours or even days without losing the thread. The trade-off is that a single request runs longer: at higher effort, on tasks that require gathering context and self-verification, one request may take dozens of minutes, and autonomous runs may stretch to hours. Before migrating, tune your client-side timeouts, streaming display, and user-facing progress indicators accordingly — ideally switch your engineering framework to periodic async polling of task status instead of blocking and waiting for a hard return.

How to Set the Effort Tier, and How to Stop It From Refactoring Code on Its Own

Effort is Fable 5's main dial for balancing "smart, slow, expensive," with four tiers: low, medium, high, xhigh. Default to high; use xhigh for the most capability-hungry tasks; dial down to medium or low for routine work. The key point: this generation's low tier often beats the previous generation's xhigh. If a task gets done but slower than it needs to be, drop a tier. Click each tier below to see what it's for.

Bumping the tier up has a side effect: at higher effort, Fable 5 tends to do extra work on its own — adding features, refactoring, adding unnecessary validation. To stop this "cleanup on its own initiative," add the snippet below:

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.

Making Summaries Sound Human, and Knowing When to Actually Stop and Ask

This generation follows instructions so tightly that one line can steer a whole category of behavior — no need to spell out every case individually. This section gives two: one to fix verbosity, one to draw the line on when the model should genuinely stop and ask the user.

Left unconstrained, Fable 5 tends to sprawl: reviewing options it won't take, long-winded root-cause explanations, heavily structured PR descriptions, a comment on every line explaining what the next line does. A short precision instruction works just as well as listing every individual quirk:

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 goes for "pausing to ask the user" in long workflows — you don't need to enumerate every scenario. Only three situations genuinely call for a stop: an irreversible or destructive action, a real scope change, or information only the user can provide. Hit one of these, ask, and end the turn — rather than dropping a promise and stopping mid-stream.

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.

Fixing Fake Progress Reports: Make It Back Up Claims With Evidence

When running long autonomously, the model can fabricate progress reports — claiming a step is done when it isn't. Anthropic's fix: have it self-audit before reporting. Every claim gets checked against an actual tool-call result from this session, and anything unverified must be stated explicitly.

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.

Drawing the Line: Don't Take Action While Just Analyzing

Fable 5 occasionally acts on its own initiative — drafting an email nobody asked for, or creating a "just in case" git branch as a backup. The instruction below stops that, separating "should report" from "should act."

Two core boundaries. First: 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 it and stop, don't go fix things before anyone's asked. Second: before running a command that changes system state (restart, delete, config edit), confirm the evidence actually supports that specific action — a signal that pattern-matches a known failure might have a different cause.

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.

Using Parallel Subagents Well, and Building a Self-Accumulating Memory System

Fable 5 dispatches parallel subagents more readily than the previous generation, and holds up better in sustained async communication with long-running subagents. It comes down to three things: dispatch more, be clear about when to delegate, and receive messages asynchronously instead of blocking on each subagent returning one by one. Click below to compare the old and new orchestration styles.

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

Now give it a memory system that accumulates experience

Fable 5 does especially well when it "can record past lessons and reference them later." Give it somewhere to write notes — a single Markdown file is enough. The writing rules:

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.

If you want to cold-start this memory from existing session history, have it review past sessions, use subagents to distill themes and lessons, and store them in a designated file:

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.

Keeping It From Stalling: No Getting Stuck Waiting for Permission Mid-Run

Two small quirks that only surface occasionally in very long sessions, each with a fix from the doc.

First: late in a conversation, it may state "I'll go run X now" without actually issuing the matching tool call, or stop and ask "want me to…?" even when it already has enough information. A simple "continue" or "go ahead and do it end to end" gets it moving again. Add the system reminder below to autonomous pipelines to prevent this at the root:

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.

Second: in very long sessions, it may occasionally propose starting a new session, offer to summarize and hand off, or cut its own workload short on its own initiative. This is usually triggered by the engineering framework showing the model a "remaining token countdown." Try not to expose the specific context-remaining number to it; if the framework must display it, add a reassuring line:

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

Explaining the "Why," a Dedicated User-Facing Channel, and a Final Checklist

The last two improvements plus a dedicated channel, then a landing checklist to wrap up.

Add the "why" to your requests

Fable 5 performs better when it understands the intent behind a request: with that context, it can tie the task to relevant information rather than guessing at intent on its own. This matters especially for long-running agents driving multiple workflows — tell it why you're asking:

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

Speak plainly when wrapping up a long session

In agent conversations heavy with tool calls and context, Fable 5 tends to produce hard-to-read text: dense arrow-chain jargon, implementation details buried deep, references to internal thinking the user never saw, overly technical phrasing. Add a communication-style addendum to make it switch back to plain language for the final summary, instead of continuing the working shorthand:

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.

Add a dedicated user-facing channel: the send-to-user tool

For long-running async agents, give it a way to push content out mid-turn that the user must see verbatim — a deliverable (a generated code snippet, a drafted message), a progress update with concrete numbers, or a direct answer to something the user asked mid-task. The tool's input is the message to display; once the model calls it, you render the input straight to the interface, and the tool result just returns a simple confirmation. The key: the tool input is never summarized — the content arrives verbatim.

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

Defining the tool alone isn't enough: without a calling instruction in the system prompt, Fable 5 rarely calls it on its own. Pair it with a prompt, and restrict it to user-facing content only — don't let narration or internal reasoning leak into this channel:

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.

Landing checklist

The doc closes with a recommended set of scaffolding changes — just follow along:

1. Set a higher difficulty ceiling. Pick a task harder than what you'd have assigned to the previous generation, and let Fable 5 scope it itself, ask clarifying questions, and execute. Testing it only on easy tasks will make you underestimate its ceiling.
2. Explicitly schedule self-checks in long runs. An independent, fresh-context verification subagent is usually more reliable than self-critique. Add this to long-running tasks:
   Instruction template for periodic self-checks during long runs

   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.

3. Re-audit old skills and prompts. Skills written for the previous generation are often overly granular for Fable 5, and can actually drag down output quality. A lot of that old rule-by-rule style can just be deleted — check the default behavior first. Fable 5 can also update skills on the fly as it works.
4. Don't let it restate its internal reasoning. Verbatim-restating internal reasoning inside the reply text is a hard line for this generation. ⚠ Prompts, skills, or harness instructions that ask the model to echo, transcribe, or speak its internal reasoning as reply text may trigger Fable 5's reasoning_extraction refusal category, causing the request to auto-downgrade back to Claude Opus 4.8. When migrating, audit old skills and system prompts for instructions like "reflect" or "show your thinking" and remove them. For reasoning visibility, use the structured thinking blocks from adaptive thinking instead, and surface progress via the send-to-user tool during long runs.
5. Install the send-to-user tool. Give long-running async agents a client-side tool that delivers messages to the user verbatim without ending the turn.

This doc is the fix: a dozen-plus instruction snippets you can paste straight into your system prompt, each one targeting a specific quirk — overplanning, unsolicited refactors, verbosity, when to stop and ask, fake progress reports, building a memory system, dispatching parallel subagents, and a dedicated channel that must reach the user verbatim. Take the most typical one, "overplanning," as an example:

The instruction fixes "overthinking." But when it runs unsupervised for hours, there's a trickier problem: it might fake its progress, claiming a step is done when it isn't. That's exactly the mechanism the next section covers.

The one place in the whole doc with actual effect data: force it to verify evidence before reporting every step of progress. Follow "XiaoHu" through it,

People have no feel for "how much faster" in the abstract — time is what lands. The doc's most concrete comparison: some systems that used to take days of back-and-forth iteration got correct in a single pass with this generation.

All figures above are from Anthropic's internal testing and early-tester self-reports, unreproduced by any third party.