Prompting Claude Fable 5.2: Anthropic's rules, with CLAUDE.md before and after
Published · Last updated
Short answer
Anthropic's prompting page for Claude Fable 5.2 has 11 sections. Four give text to paste into a system prompt or CLAUDE.md. The rest say to remove old lines, name exact actions, or lower effort, because Fable 5.2 follows instructions closely.
This guide walks through every section of Anthropic's "Prompting Claude Fable 5.2" page in the page's order, fetched and checked on 2026-11-11. Each section has a one-line summary, a short quote linked to Anthropic's section, and a before and after. The "before" is a plain, common version we wrote. The "after" is Anthropic's own text, or, where the page only says to delete a line, our example with that line gone. Every claim about the model comes from that one page.
One rule applies to all of it. The page says to change prompts in new conversations only, because on Fable 5.2 the API checks that earlier context did not change:
"Several sections on this page suggest text to add to your system prompt, lines to remove from it or from the notes and rules your agents carry, or changes to a tool description. Make these changes in new conversations only."
1. Calibrate effort
In one line. Start at high, rerun your effort tests instead of reusing old settings, and lower effort for easy turns, because asking the model not to think does not work at medium and above.
"At high and above, the model thinks before almost every reply, including a reply to a greeting. If easy requests take too long or cost too much, use a lower effort level for those turns. In Anthropic's testing, an instruction to answer directly without deliberating didn't stop the model from thinking at medium and above."
The page's guidance for each effort level, quoted in full:
| Level | What Anthropic's page says |
|---|---|
| low | "low suits quick back-and-forth, well-specified tasks, and high-volume workloads, such as fast, intelligent subagents. In Anthropic's testing, the model's scores at low sat close to Claude Fable 5.1's scores at higher effort levels." |
| medium | "medium suits interactive coding, chat, and everyday knowledge work." |
| high | "high suits hard coding, research, agentic work, and long unattended runs. Turns take noticeably longer to finish than at medium." |
| xhigh | "xhigh is for your hardest long-running coding and agentic work, where you've measured a gain. On Anthropic's internal coding evaluations, it raised scores slightly and used many more tokens." |
| max | "max is for measuring the model's ceiling, or for the rare task where time and tokens don't matter. It best suits open-ended problems, such as scientific discovery and mathematics. Turns are slow and use many more tokens than at xhigh." |
Source: Calibrate effort. The page adds: "Most of the gain in capability is already present at high", "Effort barely changes how long the model's replies are", and "rerun your effort sweep instead of carrying over a setting you tuned on Claude Fable 5.1 or Claude Opus 5.5." High is the default on the Claude API.
Before (our example, not Anthropic's)
# Answers
Reply in the language the user writes in.
For quick questions, answer directly without deliberating.Run at high effort for every turn, including greetings and one-line questions.
After (our example with the line Anthropic says to remove taken out)
# Answers
Reply in the language the user writes in.Then send easy turns at a lower effort level, as the page says. The page gives no replacement line for the prompt. To change levels mid-conversation and keep the prompt cache, it points to a per-message effort change (beta). For setting effort in Claude Code, see our Claude Code with Claude Fable 5.2 guide.
2. Finish the whole task
In one line. Fable 5.2 sometimes ends a long turn early, more often at low and medium effort, and Anthropic gives a block of text that tells it to work through ordinary obstacles but leave deliberate blockers alone.
"Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed."
Before (our example, not Anthropic's)
# Working style
If something fails, stop and tell me what's left.After (Anthropic's recommended text)
# Finishing work
Please avoid stopping while you still owe work the user asked for. Be persistent and do not stop unless needed.
While status notes are welcome, as is clarifying with the user on open decisions, carry on with work that does not depend on the user's answer without unnecessary stops.
If you notice yourself inviting the user to redirect you or offering to wait, instead proceed on the next part of the task. You may meet ordinary obstacles like errors, timeouts, locked files, empty results or failing tools. Diagnose them first, and when they are not real blockers, work through them with the access you have (wait and retry, fix the request, use another tool or source) rather than stopping unnecessarily.
If someone clearly decided something is a hard blocker, such as a file marked not to be touched, access that was intentionally withheld, or a safety guardrail, leave it alone, say plainly what you found, and look for another safe way to finish the task. Stopping before the task is complete is very rarely merited, as in when the task can't move forward without user input, or where the blocker is deliberate and should not be worked past. This does not override the need for confirmation on risky or destructive actions.What Anthropic measured: on replayed sessions at medium effort, "about half as many sessions ended with doable work left", and "Output tokens rose by about 30 percent." The page also says: "keep your own confirmation step for risky or irreversible actions."
3. Approvals
In one line. When you approve a step, say what you approve instead of "go", and make approval rules in the system prompt name the exact actions they cover.
"If your system prompt has approval rules, name the exact actions they cover, because the model applies them as written."
The page's example of a rule that cast too wide a net: one rule listed "sending messages to people outside this conversation" among the steps that need approval, and "the model held back roughly half of its routine requests to colleagues and other teams."
Before (our example, not Anthropic's)
goA bare go-ahead typed after the agent asks to run a migration.
After (Anthropic's recommended text)
Yes, run the migration on the staging databaseThis is the page's own example reply. For rules that should allow an approved step, see section 7: the page found that writing the exception into the rule itself worked, and a separate line did not.
4. Say who owns the code
In one line. If the prompt says the code is the model's own, Fable 5.2 merges repeated code and fixes nearby problems; if it says nothing, it tends to add on top and only report problems.
"If you want the model to improve the structure as it works, say that the code is its own"
Before (our example, not Anthropic's)
# Repo
You are helping me with my codebase.After (Anthropic's recommended text)
This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.Anthropic's numbers on small coding tasks: the model merged repeated code "in about half of the tries with this sentence, and in under a tenth of the tries without it", and "used about 1.5 times the output tokens". Its summary "often left out small ones, so review the diff and not only the summary." Leave the sentence out "where the user owns the code and wants it changed as little as possible." A scope rule elsewhere does not cancel it: with "No drive-by refactors, renames or cleanups" in the same prompt, the model "still merged repeated code in about a third of the tries."
5. Keep users informed during long turns
In one line. Fable 5.2 can go quiet across long tool runs, so first make your client show its progress updates, then add Anthropic's update text, a harness reminder, or both.
"First, check that your client receives the model's updates."
The page explains that the updates come back as thinking blocks whose text is empty at the default thinking.display of "omitted". Set display: "updates" (beta) to get a short summary of each update, or "summarized", and render the non-empty thinking blocks between tool calls.
Before (our example, not Anthropic's)
# Working style
Work quietly. Report only when you are done.After (Anthropic's recommended text)
Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own (what you found, what you did, and what's next), so a reader who only sees the last message has the full picture.With this text, "the model spoke before its first tool call every time", and output tokens per task rose "by roughly 20 percent." Anthropic says to use it "where a human is directly in the loop."
Two more texts from the same section. If your harness can append mid-conversation system messages, the page suggests appending this reminder after several silent tool-calling steps in a row. In Anthropic's testing it "roughly halved the longest silent stretch":
The user hasn't heard from you in a while: say in a few words what you're doing, then continue.If you can't change the harness, the page gives this one sentence for the system prompt instead:
Every few tool calls, give the user a one-line update on where things stand.6. Set expectations for subagents
In one line. Before you rewrite your subagent tool, remove standing "delegate" lines from prompts, skills and agent files; change the tool description only if Fable 5.2 still starts too many subagents.
"If your system prompt, skills, or agent files tell the model to delegate, review those lines first."
Before (our example, not Anthropic's)
# Working style
Run the tests before you say a task is done.
Delegate every search and every file read to a subagent.After (our example with the line Anthropic says to remove taken out)
# Working style
Run the tests before you say a task is done.The page does not print the tool description Anthropic tested, so we don't invent one. It says what a new description should do: "state what a subagent adds to the cost of a session, say when delegation is worth it and when it isn't, and tell the model how to brief a subagent that it starts." With that kind of description, the model "delegated about a third less often" on short tasks, with the same task success. The page also says to "check which model your harness runs subagents on by default."
7. Keep caution from piling up
In one line. Old "never" notes in memory, notes and agent messages make Fable 5.2 hold back routine work, so delete stale notes and write exceptions into the rule itself.
"Cautious instructions build up wherever context carries over: memory, notes, instruction files, and messages between agents."
The page's four fixes, each backed by a test on simulated tasks:
- Remove notes you no longer need. In one test, a single note among a dozen said never to retry. After a busy tool, the model then retried in "about four in ten tries, down from nearly all".
- Name the steps that need no approval. Listing retries there raised retries "from almost none to about half of the tries", while "a general instruction to act more freely changed nothing." The page adds: "Name retries only for calls that are safe to repeat."
- Check what reviewer agents attach. Even with retries listed as needing no approval, a reviewer's "stop at the first error" in context meant Fable 5.2 "didn't retry in about a third of the tries." Fable 5.1 and Opus 5.5 retried.
- Write the exception into the rule. "When the rule itself said to get a go-ahead first, the model took the step in about nine tries in ten."
Before (our example, not Anthropic's)
# Notes from earlier sessions
- Never retry a failed tool call.
- The staging database resets every night.The retry note was written months ago after one bad run. Nobody remembers why.
After (our example with the line Anthropic says to remove taken out)
# Notes from earlier sessions
- The staging database resets every night.The page also says: "keep your own confirmation step for risky or irreversible actions."
8. Review instructions written for earlier models
In one line. Lines written for Fable 5.1 or Opus 5.5 can raise cost, cause side effects or do nothing on Fable 5.2, so test or remove them before you migrate.
"In Anthropic's testing, some instructions written for earlier models raised cost, caused side effects, or no longer had an effect."
| Instruction type (the page's name) | What the page says to do |
|---|---|
| Standing instructions to delegate | "If, in your tests, the model starts more subagents than your tasks need, remove the lines you no longer need." |
| A token budget that your harness writes into the prompt | "removing a large budget lowered cost, with equivalent performance. Test your tasks without the budget." |
| Harness code that edits earlier turns | "Apart from compaction and context editing, keep the history append-only." |
| The "treat that answer as done" lines | "Leave these lines out where you want the model to keep re-examining its earlier answers." |
| Instructions to think less | "Remove these lines and lower the effort level" |
| Style rules for writing | "Remove the rules you no longer need before you add the text in Make reports easy to follow." |
| Rules, notes, and memories that have built up | "delete the cautions whose reason no longer holds, and rewrite absolute rules so that they state their scope and reason." |
Before (our example, not Anthropic's)
# Carried over from our Fable 5.1 setup
Delegate research to subagents whenever you can.
You have 400,000 tokens for this task. Tokens left: {remaining}.
Answer directly without deliberating.
Write one instruction per sentence, in 20 words or fewer.
Run the tests before you say a task is done.After (our example with the line Anthropic says to remove taken out)
# Carried over from our Fable 5.1 setup
Run the tests before you say a task is done.The page says to test some of these rather than drop them blind: test the delegate line and the token budget on your own tasks first. The 20-word style rule is the page's own example of a rule that "can make its prose choppy."
9. Make reports easy to follow
In one line. Readers of a final report haven't seen the tool calls behind it, so Anthropic gives text that asks for self-contained, plain reports.
"Write for an intelligent but low-context reader."
Before (our example, not Anthropic's)
# Final summary
Bullets only. Max 20 words per bullet.After (Anthropic's recommended text)
# Communicating clearly
Write for an intelligent but low-context reader. The person reading has not seen your tool calls, your reasoning or the files you opened, and may be switching in from other work. Messages should generally be self-contained: the reader should understand what you mean without having to dig for other context. Put the key points in the first few sentences. Practice progressive disclosure in your sentence order, and do not use undefined references and ideas in line 1 that won't make sense until the reader reaches line 12.
Use plain words, and write in clear, understandable full sentences. Do not use a term or abbreviation that you made up during the work. Say what the thing is in a way any reader would understand. Write mostly in the style of ASD-STE100 Simplified Technical English: short sentences, one idea per sentence, active voice, and consistently using the same word for the same thing. Use a paragraph of flowing prose where ideas connect, and keep bullets for lists of separate items. Leave out unnecessary details unless the reader asks and practice concision, but do ensure that your messages have the key context. Aim to make your user-facing text as human-readable and clear as possible.In Anthropic's testing, this text "made final reports less dense, with fewer semicolons." The page says to remove old style rules before you add it, and to "adjust it to your readers and your product."
10. Safeguard refusals
In one line. Fable 5.2's safety classifiers can return a refusal with a category, and prompts that ask the model to write its reasoning in the reply should go.
"If your prompts, skills, or tool descriptions ask the model to write its reasoning in the response, remove those instructions."
A declined request returns stop_reason: "refusal", and stop_details.category names one of five categories:
cyber: "the request could enable cyber harm, such as malware or exploit development."bio: "the request could enable biological harm, such as dangerous lab methods."frontier_llm: "the request could help with the development of competing AI models."reasoning_extraction: "the request asks the model to reproduce its internal reasoning in the response text."general_harms: "the request falls under another usage-policy area."
The page names the Cyber Verification Program and the Life Sciences Verification Program for legitimate work the classifiers block. Our Claude Mythos 5.2 vs Fable 5.2 guide covers Mythos access.
Before (our example, not Anthropic's)
# Answers
Show your reasoning step by step in your reply, then give the answer.
Name the file and line for every claim about the code.After (our example with the line Anthropic says to remove taken out)
# Answers
Name the file and line for every claim about the code.To see how the model reasoned, the page says to set display: "summarized" and read the thinking blocks.
11. Where to start
In one line. When you migrate, set effort to high on purpose, clean out old instructions, run your longest tasks, then fix one observed behavior at a time.
"Apply the guidance for each behavior you observed, one at a time, and measure its effect and its token cost on your own tasks."
Before (our example, not Anthropic's)
# Migration plan
Swap the model ID to claude-fable-5-2. Keep the prompt and effort setting as they are.After (Anthropic's recommended text)
1. Set effort to high explicitly, then run your evals at medium and xhigh as well.
2. Read the system prompts, skills, agent files, memory files, notes, and harness text you carry over. Remove or test the instructions listed in Review instructions written for earlier models.
3. Run your longest agentic tasks. Note where the model stops early, asks for approvals it doesn't need, goes quiet, delegates more than the task needs, or adds to existing code where you wanted it restructured.
4. Apply the guidance for each behavior you observed, one at a time, and measure its effect and its token cost on your own tasks.The page's four steps, word for word, without its links and code formatting.
Source
Anthropic, "Prompting Claude Fable 5.2", Claude Platform docs: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-2. Fetched and checked 2026-11-11. Quotes use straight apostrophes; the wording is unchanged. The "before" examples are ours.