Prompting Claude Fable 5.2: What Anthropic's Tests Found, Section by Section (and the "This Codebase Is Yours" Line)

Anthropic's prompting guide for Claude Fable 5.2 is organized around ten symptoms you might see, and for most of them it reports a result from Anthropic's own testing. The best-known tip is one sentence, "This codebase is yours", which in Anthropic's testing on small coding tasks made the model merge repeated code in about half of the tries instead of under a tenth. It also cost about 1.5 times the output tokens.

That tip spread after Simon Willison posted it on X on 10 November 2026, calling it "an entertaining tip to make Fable 5.2 less likely to be cautious in how it improves existing code". The rest of the guide gets less attention, and it matters more for anyone who runs agents in production: text that stops early endings, approval rules the model applies word for word, notes that pile up caution, and instructions you should delete before you migrate.

This post walks through each section of the guide with its number, its trade-off, and what we would do with it in a real system prompt. Every test figure below comes from Anthropic's Prompting Claude Fable 5.2 page, re-read on 11 November 2026. The numbers are Anthropic's, measured on its own tasks, and the guide tells you to test each change on yours.

What does the Fable 5.2 prompting guide cover?

The guide is organized by symptom. You find the thing you see in your agent, then read the matching section. Here is the whole page in one table.

The guide also carries one warning that sits above every section, and it is the one most likely to break a production system. We cover it next.

The warning to read first: change prompts only in new conversations

Several sections tell you to add text to your system prompt, delete lines, or change a tool description. The guide says to make these changes in new conversations only. On Fable 5.2 the API enforces the prefix check for every account, and in the guide's words, "A request that sends thinking blocks back after system, tools, or an earlier message changed can return a 400 error, so a stored conversation resumed with the new text can fail."

In practice: if your product stores long-running agent conversations and you ship a new system prompt, the old conversations can start failing when they resume. To change instructions partway through a conversation, the guide says to put them in the newest turn, or to append a mid-conversation system message where that feature is available.

Watch out: Roll out prompt changes from this guide to new sessions only, and keep the old prompt pinned for conversations already in flight. Our Opus 5.5 to Fable 5.2 migration guide covers the prefix check and rollback plan in more detail.

Calibrate effort

The guide says to start at high, the default on the Claude API, and to rerun your effort sweep instead of carrying over a setting you tuned on Fable 5.1 or Opus 5.5. Its summary of the levels:

• low: quick back-and-forth, well-specified tasks, high-volume work such as fast subagents. In Anthropic's testing, scores at low "sat close to Claude Fable 5.1's scores at higher effort levels."
• medium: interactive coding, chat, everyday knowledge work.
• high: hard coding, research, agentic work, long unattended runs.
• xhigh: your hardest long-running work, where you have measured a gain. On Anthropic's internal coding evaluations it "raised scores slightly and used many more tokens."
• max: measuring the model's ceiling, or the rare task where time and tokens don't matter.

Three behaviors are worth writing down. The model stops early more often at lower effort. At high and above it thinks before almost every reply, including a greeting. And effort barely changes reply length, so length and tone belong in the prompt.

The practical point for cost: an instruction like "answer directly without deliberating" did not stop Fable 5.2 from thinking at medium and above in Anthropic's testing. If easy turns cost too much, lower the effort level for those turns rather than writing a "think less" line. At $8 per million input tokens and $40 per million output tokens on Anthropic's pricing page, that choice shows up on the bill. Our Claude Fable 5.2 pricing page has the full rate card.

Finish the whole task: the "Finishing work" block

On long tasks, Fable 5.2 sometimes ends a turn before the work is done. The guide describes three kinds of early ending: a list of what remains, an offer to continue, or a stop at an ordinary obstacle such as a timeout. It happens more at low and medium effort.

The guide gives a system prompt block for this. It opens:

# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.

The rest of the block separates ordinary obstacles (errors, timeouts, locked files, empty results, failing tools), which the model should diagnose and work through, from deliberate blockers ("a file marked not to be touched, access that was intentionally withheld, or a safety guardrail"), which it should leave alone and report. It ends with "This does not override the need for confirmation on risky or destructive actions." Copy the full block from the guide rather than from a summary, because the wording of that split is the point.

What Anthropic measured: it replayed recorded sessions from an agentic coding product at medium effort. With a version of this text, about half as many sessions ended with doable work left. The text removed most endings that ask permission or offer to continue, but not endings that list what remains and then stop. Output tokens rose by about 30%.

So the block fixes one kind of early stop and not the other, and it costs tokens. Because the model asks less often with it, the guide says to keep your own confirmation step for risky or irreversible actions.

Approvals: name the exact actions

Two small rules sit under this section. First, when you tell the agent to keep going, say what you want ("Yes, run the migration on the staging database") instead of a bare "continue" or a thumbs-up.

Second, approval rules get applied as written. In Anthropic's testing on simulated tasks with nobody there to approve, one rule listed "sending messages to people outside this conversation" among the steps that need approval. With that rule, the model held back roughly half of its routine requests to colleagues and other teams. If your rule is broader than you meant, Fable 5.2 will hold to the broad version.

Say who owns the code: "This codebase is yours"

This is the section Simon Willison shared. The guide says Fable 5.2 "responds closely to what the prompt says about who owns the code it works on." When a prompt says nothing about ownership, or presents the code as someone else's, the model tends to add to the existing structure even when that repeats code, and to report nearby problems instead of fixing them.

The sentence the guide suggests:

This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

The numbers, all from Anthropic's testing on small coding tasks:

What the viral version leaves out:

• The feature worked either way. The guide says "The requested feature worked in nearly every try either way." What the sentence changes is how much restructuring the model does.
• The model also "made several changes that nobody had asked for, many of them new tests and documentation." Behavior changes to existing features happened more often at higher effort.
• The closing summary "named the larger changes but often left out small ones, so review the diff and not only the summary."
• A scope rule doesn't cancel it. With "No drive-by refactors, renames or cleanups" earlier in the same prompt, the model still merged repeated code in about a third of tries.
• The result held when the sentence sat inside a long system prompt.

The guide's own advice: leave the sentence out "where the user owns the code and wants it changed as little as possible." For a client repo with a strict change process, that is most of the time. For an internal tool your agent maintains end to end, it is a reasonable line to test.

What we'd do: Put the ownership sentence only in the prompt for agents that own a codebase outright, and pair it with a diff review step. Never add it to an agent that works on a customer's code, and don't rely on a scope rule elsewhere in the prompt to cancel it.

Keep users informed during long turns

Fable 5.2 sometimes writes little user-facing text during long runs of tool calls. The guide's first check is plumbing, not prompting: the updates the model writes between tool calls come back as progress-update thinking blocks, and their text is empty at the default thinking.display of "omitted". A client that renders only text blocks looks silent. Set display: "updates" (beta) or "summarized" and render the non-empty thinking blocks.

Then the guide offers three prompt-side options, each with its own measurement:

One detail matters for the harness option: leave each reminder in messages on later requests. Removing or rewording one edits an earlier turn and invalidates the thinking blocks after it. And if your users come back for the result rather than watching each step, the guide says gaps between updates matter less.

Set expectations for subagents

How much Fable 5.2 delegates depends on your harness. In Anthropic's testing on short tasks with a minimal subagent tool, it rarely started one. In an agentic coding product whose prompts invite delegation, it delegates readily.

The order the guide recommends: review the lines in your system prompt, skills and agent files that tell the model to delegate first. Change the subagent tool description only if Fable 5.2 still starts more subagents than your tasks need. A better description states what a subagent adds to the cost of a session, when delegation is worth it, and how to brief a subagent, with cost first.

In Anthropic's testing on short tasks, the model delegated about a third less often with the tested description than with one that mostly listed reasons to delegate, and task success was the same. The guide also notes that Anthropic saw Fable 5.2 use subagents to review its own work at xhigh and max in an agentic coding product, which Fable 5.1 didn't do on the same tasks, and that subagents "can account for a large part of what a session costs." Check which model your harness runs subagents on by default.

Keep caution from piling up

This is the section we expect to matter most for multi-agent systems. Cautious instructions build up in memory, notes, instruction files and messages between agents, and Fable 5.2 follows them closely. The guide says a few early testers saw it ask for approvals it didn't need or hold back routine work, mostly where several agents work together.

Its four fixes, each with a test from Anthropic's simulated tasks:

1. Remove notes you no longer need. One of a dozen notes from earlier sessions said never to retry. With those notes in context, the model retried after a busy tool in about four in ten tries, down from nearly all without them.
2. Name the steps that need no approval. A line listing retries among the steps that need no approval raised retries from almost none to about half of tries. A general instruction to act more freely changed nothing. Name retries only for calls that are safe to repeat.
3. Check what reviewer agents attach. With retries allowed in the prompt but a reviewer's "stop at the first error" in context, Fable 5.2 didn't retry in about a third of tries. Fable 5.1 and Opus 5.5 retried.
4. Write the exception into the rule. Under a "never" rule, the model took a step the person in charge had approved in about one try in ten. A separate line saying an approved step has its go-ahead didn't change that much. When the rule itself said to get a go-ahead first, the model took the step in about nine tries in ten.

The pattern across all four is specificity. In Anthropic's setup, a general instruction to act more freely changed nothing, while a named exception inside the rule worked. If you run agents that share a memory file or pass notes to each other, this is the audit worth doing before you switch models.

Review instructions written for earlier models

The guide lists instructions that, in Anthropic's testing, raised cost, caused side effects, or stopped working on Fable 5.2. This is the "delete before you migrate" list:

The style-rules item is easy to miss. If your system prompt carries strict writing rules that compensated for an older model, Fable 5.2 may follow them so closely that the output reads worse. We saw a related effect on Opus 5.5 in our own CLAUDE.md benchmark: a legacy CLAUDE.md and four skills written for older models cost 2.1 times as much as an empty repo and passed the same hidden tests.

Make reports easy to follow

For agents that write final reports or handoffs, the guide gives a "Communicating clearly" block. It opens "Write for an intelligent but low-context reader" and asks for the main points first, plain words, no made-up terms, and writing "mostly in the style of ASD-STE100 Simplified Technical English." In Anthropic's testing on agentic tasks, it made reports less dense, with fewer semicolons, and on workflow automation tasks it made sentences shorter.

Note the interaction with the previous section: the guide says to remove the style rules you no longer need before adding this block.

Safeguard refusals

Fable 5.2 runs safety classifiers that can decline a request with stop_reason: "refusal". stop_details.category names one of five categories: cyber, bio, frontier_llm, reasoning_extraction and general_harms. The guide says benign cybersecurity and life sciences work can also trigger the first two, and points to Anthropic's verification programs.

One prompt-level fix: the guide defines reasoning_extraction as a request that "asks the model to reproduce its internal reasoning in the response text", and it says to remove any instruction in your prompts, skills or tool descriptions that asks the model to write its reasoning in the response. To see the reasoning, set display: "summarized" and read the thinking blocks. We hit a version of this on Opus 5.5 in the CLAUDE.md benchmark above: one old line asking for full written reasoning got all 10 runs refused.

A migration checklist for your agent harness

The guide closes with an order of work. Here it is, with the sections above mapped to each step:

1. Set effort to high explicitly, then run your evals at medium and xhigh too.
2. Read every system prompt, skill, agent file, memory file, note and harness text you carry over. Delete or test the items in the "earlier models" table: delegation lines, in-prompt token budgets, "think less" lines, "treat that answer as done", hard style rules, stale cautions.
3. Run your longest agentic tasks. Note where the model stops early, asks for approvals it doesn't need, goes quiet, delegates too much, or adds to code you wanted restructured.
4. Apply one fix per observed behavior, and measure both its effect and its token cost on your own tasks.

Ship every prompt change to new conversations only. If you want a second pair of eyes on this, our Claude consulting engineers audit system prompts, skills and agent files against the Fable 5.2 guide, and our Claude Code team sets up the harness side: subagents, hooks and review loops.

FAQ

What does "This codebase is yours" do in Claude Fable 5.2?

It tells Fable 5.2 that it owns the code, which tends to make it restructure more as it works. In Anthropic's testing on small coding tasks, the model merged repeated code in about half of tries with the sentence and under a tenth without it, and used about 1.5 times the output tokens. The requested feature worked in nearly every try either way.

Should I add the ownership sentence to every coding agent?

No. Anthropic's guide says to leave it out where the user owns the code and wants it changed as little as possible. With the sentence, the model changed how an existing feature behaves in one try in six to ten, and a "no drive-by refactors" rule elsewhere in the prompt did not cancel it.

Why does Fable 5.2 stop before the task is done?

Fable 5.2 sometimes ends long turns early, especially at low and medium effort. Anthropic's "Finishing work" system prompt block cut sessions ending with doable work left by about half in replayed coding sessions at medium effort, at the cost of about 30% more output tokens. It removed most endings that ask permission or offer to continue, but not endings that list what remains.

Can I tell Fable 5.2 to think less to save tokens?

Not with a prompt line. In Anthropic's testing, an instruction to answer directly without deliberating did not stop Fable 5.2 from thinking at medium and above. Lower the effort level for easy turns instead.

Why do my Fable 5.2 conversations return a 400 error after a prompt change?

Fable 5.2 enforces the prefix check for every account. If you change the system prompt, tools or an earlier message and then send thinking blocks back, the request can return a 400 error. Make prompt changes in new conversations, or put new instructions in the newest turn.

How do I stop Fable 5.2 from starting too many subagents?

Start by removing delegation instructions from your system prompt, skills and agent files. If it still over-delegates, rewrite the subagent tool description to state the cost first, when delegation is worth it, and how to brief a subagent. In Anthropic's testing on short tasks, the model delegated about a third less often with that kind of description than with one that mostly listed reasons to delegate, with the same task success.

---

Sources: Anthropic, Prompting Claude Fable 5.2 (read 2026-11-11), Anthropic, What's new in Claude Fable 5.2, Anthropic, Pricing, Simon Willison on X, 10 November 2026, Simon Willison, "A quote from Prompting Claude Fable 5.2"