Long tasks keep asking “Should I continue?”: Claude Fable 5.2’s official guide says change these two things first

Claude Fable 5.2’s official prompting guide puts effort first. The API already defaults to high, but the official guidance still recommends writing it explicitly, and also running evaluations with medium and xhigh. The original poster min heo’s summary is even more direct: first mark effort as high, then clearly say “finish the job.” The official guide covers Fable 5.2 and Mythos 5.2.

The official guide doesn’t present it as a magic spell. effort affects how long the model thinks, how many times it calls tools, how long a single turn runs, and how many tokens it burns.

effort levels

• low: fast turnarounds, clearly defined tasks, and high-concurrency scenarios. The official guide says 5.2’s coding benchmark scores at low are close to 5.1’s performance at higher effort.
• medium: interactive coding, chat, and everyday knowledge work.
• high: difficult coding, research, long-running agent tasks, and unattended tasks. This is the API default.
• xhigh: the hardest long-duration coding and agent tasks, where you’ve measured a benefit in your own tests. The official internal coding benchmark score rises slightly, while token consumption is much higher.
• max: testing the model’s upper limit, or the few tasks where time and tokens aren’t sensitive, such as open scientific questions and math.

The official guide’s core judgment is this: most capability gains can be obtained at high. Going from medium to high improves scores on most coding and knowledge-work evaluations, and also increases tokens and time. Above high, the gains are uneven and depend on the task. So start with high, then use your own evaluations to decide whether to drop to medium or move up to xhigh. Someone in the comments mentioned that the API defaults to high, while Claude Code defaults to medium, so the same model can feel different depending on the entry point. That difference is worth confirming first.

Long tasks stopping early

Fable 5.2 sometimes lists the remaining work and asks the user whether to continue, or stops when it hits an ordinary obstacle such as a timeout. The official guide recommends adding a “Finish work” requirement to the system prompt: don’t stop with work the user asked for still owed; it’s fine to ask for status clarification and open decisions, but continue with the parts that don’t depend on the user’s answer; when encountering errors, timeouts, lock files, empty results, or tool failures, diagnose first, retry when possible, and switch tools when possible. Genuinely high-risk or irreversible actions should still require confirmation.

Anthropic replayed recorded sessions from an agentic coding product under medium. After adding this prompt, sessions that ended with unfinished work even though they could have continued dropped by about half. The cost was roughly a 30% increase in output tokens. Endings that asked for permission or proposed continuing largely disappeared, but endings that “list the remaining work and then stop” remained. The official guide reminds you that even if the model asks less, you can’t skip your own risk-confirmation steps.

Approvals also need to be specific. Don’t just reply “Go.” Write “Yes, run the migration on the staging database.” Approval rules that are too broad will suppress everyday actions. In simulated tasks with no human approval, the official guide observed that after a rule listed “sending messages to people outside the conversation” as requiring approval, the model also blocked about half of routine requests to colleagues and other teams.

Code ownership

Code ownership is a counterintuitive prompt. In official tests on small coding tasks, when the prompt didn’t mention ownership or described the codebase as someone else’s, the model tended to append to the existing structure, even if that meant duplicating code. After writing “You are the owner and long-term maintainer of this codebase, and its design is up to you.”, the duplicate-code consolidation rate rose from under 10% to about 75%. Output tokens rose by about 70% to 80%, and the model also made unrequested changes, many of them new tests and documentation. When the user owns the code and wants only minimal changes, don’t include this sentence. The official guide adds one more point: even when the same prompt said “No drive-by refactors, renames or cleanups,” the model still consolidated duplicate code in more than half of runs.

Long turns, subagents, and old prompts

Long agent turns can appear silent; it may be that the client isn’t rendering them. Fable 5.2 writes progress updates between tool calls and puts them in thinking blocks. By default, thinking.display is omitted, and the text in those blocks is empty. Clients that render only text will look as if the connection dropped. Set display to updates or summarized, and then render non-empty thinking blocks. In interactive scenarios, you can also count in the harness how many consecutive tool calls happen without any user-facing text and add a reminder; the system prompt can also require an opening sentence, progress briefs, and an ending recap. In official tests, opening and recap text made every run say something before the first tool call, with output tokens increasing by about 20%.

Subagents need to be considered in terms of cost. The official guide says the degree of delegation depends on the harness and the task. Under xhigh and max, Fable 5.2 uses subagents in the agentic coding product to review its own work; 5.1 did not do this on the same tasks. Subagents can account for a large share of session cost, so first check which model subagents use by default. If delegation is excessive, change the subagent tool description to spell out cost, when it’s worth it, and how to brief subagents on tasks. In official tests under high, longer descriptions that focused more on cost roughly halved the number of subagents.

There’s another easy-to-miss pitfall: caution accumulates. Old rules in memory, notes, and instruction files—such as never retry—can make the model over-ask for permission. The official guide recommends deleting notes you no longer need, listing routine steps that don’t require approval, checking validation conditions like “stop at the first error,” and rewriting absolute rules to make their scope and exceptions clear. More cautious prompts aren’t necessarily safer; they may just be slower.

When migrating old prompts, clean them up too. Showing the model a token budget changes spending; in official tests, removing a large budget lowered cost with comparable performance. Telling the model “don’t think” doesn’t work at medium and above; if you want less thinking, lower effort. Fable 5.2 uses preserved thinking, so history should be append-only as much as possible. Changing the system, tools, or earlier messages mid-conversation will invalidate later thinking blocks and may trigger a 400 by default. To change instructions, put them in the latest turn or use mid-conversation system messages. To shorten history, use context editing or compaction.

The official documentation is here: Prompting Claude Fable 5.2

The original post is here: min heo’s summary

The order of what to do first isn’t complicated: explicitly set high, and run medium and xhigh for comparison; clean up old prompts and notes; run your longest agent tasks and record where early stopping, over-approval, silence, excessive subagents, and code-structure appending occur; add one prompt at a time and measure both effect and token cost. When a long task stops at “Should I continue?”, changing the stopping conditions and approval rules first is more cost-effective than continuing to pile on prompts.