How to Prompt Claude Fable 5.2: The Model That Listens a Little Too Well

If you read the prompting guide carefully, one main message comes out of it: the new model follows instructions very literally, including the ones you wrote into your prompt half a year ago for a completely different model. That’s why these release notes deserve your attention.

On top of that come a higher default thinking level, stricter checking of conversation history, and a lower price per token. I went through the guide together with the pages What’s new in Fable 5.2 and the migration guide and wrote down what follows from them for anyone who builds agents on top of Claude or just switches the model in Claude Code.

The main changes at a glance:

• The price dropped from $10/$50 to $8/$40 per million input/output tokens. Opus 5.5 still costs half as much.
• The default effort is high, while Opus 5.5 defaults to medium. A request without an explicit setting therefore thinks longer on Fable 5.2.
• “Don’t think” instructions no longer work. Thinking is controlled only by the effort parameter.
• The model listens more to approval rules, prohibitions stored in memory, and conditions coming from other agents. The result is an agent that asks needlessly and then waits. But this is a general change that we’ve also been seeing on Opus in Claude Code lately.
• Code ownership is a powerful switch: one sentence in the prompt decides whether the model refactors the code or just bolts more onto it. Simply say the code is yours.
• Prefix check for all accounts: the API verifies that the earlier part of the conversation (system prompt, tools, earlier messages) hasn’t changed between requests, and if your application modifies it retroactively, it rejects the request with a 400 error.
• New refusal categories and the option of automatically switching to a fallback model.

What changed compared to Fable 5.1 and Opus 5.5

Let’s start with the numbers, so we can quickly get through the costs. According to Anthropic, Fable 5.2 is a model for “demanding reasoning and long agentic tasks”. Interestingly, Anthropic itself recommends starting with Opus and moving to Fable only when Opus isn’t enough even at higher effort. That’s honest advice, because Fable is still twice as expensive.

A dash in the table means the figure isn’t listed on the Fable 5.2 pages. For cache reads on Opus 5.5, the pricing page lists $0.20, same as for Fable 5.2. But for Opus that’s 5% of the input price, for Fable only 2.5%, so long sessions with a large cached context get less expensive on Fable than the doubled input price would suggest.

TLDR

• Set effort explicitly. The default is high; for simple queries medium or low is enough.
• Throw out “don’t think” instructions, they don’t work. Lower the effort instead.
• Clean out old prompts, memories, and agent notes. The model takes them literally.
• Write approval rules concretely and put the exception directly into the rule.
• Want refactoring? Say the code is the model’s. Want minimal changes? Don’t say it.
• Only append to conversation history, otherwise you’ll get a 400 error.
• Each recommended tweak raises token consumption by 20 to 50%. Measure on your own tasks.

Other changes that may catch you off guard during the switch:

• Thinking is always on. The model uses adaptive thinking (it decides for itself how much to think), and thinking: {"type": "enabled"} with budget_tokens returns a 400 error, just like {"type": "disabled"}.
• No prefill, no temperature, top_p, top_k. This was already true for Fable 5.1.
• Forced tool choice doesn’t work. Only tool_choice auto and none pass; the any and tool variants return 400.
• Fable 5.2 thinking blocks can only be read by Fable 5.2 and Mythos 5.2. If you switch to Opus mid-conversation, the reasoning from previous turns is lost. But we don’t like switching to a different model mid-conversation anyway, because of the cache, right? Change the effort instead…
• The old computer_20251124 tool for computer use returns 400 everywhere except Amazon Bedrock. The replacement is computer_toolset_20260801. If you don’t know what this is about, you don’t need it.
• Mandatory 30-day data retention. Zero data retention (ZDR) mode is available only with special permission from Anthropic.
• Custom rate limits with lower token limits than for Opus 5.5.

Now to the prompting itself. Anthropic structured the guide by symptoms: you see a certain behavior, you find the matching chapter. I’m following the same approach, because that’s how it works best in practice.

Effort is the main control

The effort parameter determines how much the model thinks, how long one turn takes, and how many tokens it consumes. Put simply, it’s a knob between “fast and cheap” and “slow and thorough”. Fable 5.2 offers five levels:

Two claims in the guide caught my attention. According to the first, low on Fable 5.2 achieves results close to Fable 5.1 at higher levels. According to the second, most of the benefit is already available at high, and above that the gains are “uneven and task-dependent”. In internal tests, xhigh raised coding scores “modestly” and consumed “many more tokens”. Translated into plain language: turn on xhigh and max only when you have your own measurements that justify it.

And now three behaviors that can unpleasantly surprise you:

• At lower effort the model more often finishes prematurely. More on that in the next chapter.
• At high and above, the model thinks before almost every answer, even before answering a greeting. On “Hi” it can easily burn hundreds of reasoning tokens. And according to Anthropic, the instruction “answer directly without deliberating” doesn’t help at medium and above. The only solution for simple queries is to lower the effort.
• Effort barely changes response length. For the length and tone of text you have the prompt; effort controls only thinking and the number of tool calls.

If you tuned effort on Fable 5.1 or Opus 5.5, don’t carry the settings over. The order of levels is the same across models, but the amount of thinking behind each level differs. Anthropic recommends repeating the whole tuning.

A useful novelty is changing effort mid-conversation (beta, header mid-conversation-output-config-2026-07-01). You can plan and refine the assignment at medium and then switch to high for long autonomous work without losing the prompt cache. Where this feature isn’t available, a new effort value resets the cache!

The agent that stops halfway

On long multi-step tasks, Fable 5.2 occasionally ends a turn before the work is done. It typically looks like this: it lists what remains, offers “shall I continue?”, or stops at a completely ordinary obstacle, such as a timeout. This happens more often at low and medium.

Anthropic offers a block of text for the system prompt:

# 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 matters is that the text distinguishes two kinds of obstacles. Ordinary ones (an error, a timeout, a locked file, an empty result) the model should diagnose and work around. Deliberate ones (a file marked as untouchable, intentionally denied access, a security barrier) it should leave alone and report. If you adapt the text for your application, keep this distinction.

How much does it help? Anthropic tested recorded sessions from its own agentic coding tool on medium. With this text, roughly half as many sessions ended with unfinished work. Most endings of the “shall I continue?” type disappeared, but endings of the “here’s a list of what remains” type stayed. The price: roughly 30% more output tokens.

And one warning that Anthropic itself stresses: with this text the model asks fewer questions, so for risky or irreversible actions keep your own confirmation step outside the model.

Approvals: write exactly what you’re approving

Two small but practically important pieces of advice. When you tell an agent to proceed, say specifically what. Instead of “yes” or a thumbs-up, write “Yes, run the migration on the production database”. So you don’t get any surprises…

The second tip concerns approval rules in the system prompt. The model applies them exactly as written. In Anthropic’s test, “sending messages to people outside this conversation” was listed among the steps requiring approval. On simulated tasks where nobody was available to approve the run, the model then withheld roughly half of routine questions to colleagues and other teams. A rule written for customer e-mails thus also blocked internal communication. So name precisely the actions the rule is aimed at.

Whose code is it?

In my opinion this is the most interesting part of the whole guide. Fable 5.2 reacts strongly to what the prompt says about code ownership. When the prompt is silent or presents the code as someone else’s, the model adds to the existing structure even if that duplicates existing code, and merely reports problems in the surroundings. When the prompt says the code is the model’s own, it often merges repeated code and fixes related things without being asked.

Why is that? Anthropic doesn’t explain the purpose directly, but the connection is visible in the guide for Fable 5.1. It had a chapter called “Keep changes and tests to what the task asks for”, because Fable 5.1 on its own made unrequested fixes and extensions and added more tests than the task needed. The recommended block told it to stick to the assignment and only suggest everything else at the end. Fable 5.2 evidently has this restraint built in as default behavior. With code it doesn’t know the ownership of, it behaves like a tradesman in someone else’s apartment: he installs what he’s asked to, and merely points out the crack in the wall. The sentence about ownership gives it a mandate to behave like the owner who will keep living in that apartment.

I think it’s a safety choice by the vendor. An unperformed refactoring costs less than an unrequested behavior change in someone else’s code that nobody catches. Anthropic doesn’t say so explicitly anywhere, though, so take it as my interpretation.

The sentence Anthropic tested:

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

(Loosely: this code is yours, you decide its purpose and structure, and you will keep building on it.)

Numbers from tests on small coding tasks:

That last row is a reason for caution. With this sentence the model makes changes nobody asked for, often new tests and documentation, but in one case out of six to ten also a behavior change of an existing feature. At higher effort more often. And the final summary will mention the bigger changes but often omit the smaller ones. So check the diff; the summary alone isn’t enough.

One more thing struck me: a rule limiting the scope of work doesn’t cancel this sentence. With the instruction “No drive-by refactors, renames or cleanups” earlier in the same prompt, the model still merged repeated code in roughly a third of attempts. So if you’re working on someone else’s code and want minimal changes, simply don’t put the ownership sentence in the prompt. Combining the two instructions doesn’t work reliably.

The agent that stays silent

During long series of tool calls, Fable 5.2 writes little text to the user and occasionally calls the first tool without saying what it’s doing. Part of the problem is technical, though, and worth solving first.

The progress messages the model writes between tool calls arrive on Fable 5.2 as thinking blocks of the progress update type. With the default setting thinking.display: "omitted" their text is empty. A client that renders only text blocks then looks as if the agent were doing nothing. The fix:

• display: "updates" (beta, header thinking-display-updates-2026-08-18) returns a short summary of each progress message.
• display: "summarized" returns progress messages as well as summarized reasoning.
• Render the non-empty thinking blocks between tool calls to the user.

If messages do arrive and there are still too few, Anthropic offers three routes depending on how much you can change.

Harness modification. The most effective variant. The harness (that is, the control code around the model) counts consecutive steps with tool calls in which the user got nothing to read. After several such steps it adds, after the tool results, a system message valid only for that turn (clear_at: "next_user_message", beta, header mid-conversation-system-clear-at-2026-08-21):

The user hasn't heard from you in a while: say in a few words what you're doing, then continue.

According to tests on multi-turn coding tasks, this shortened the longest silent stretch by about half, without a noticeable increase in tokens or time. An important detail: leave these reminders in the history. If you delete or reword them, you modify the earlier part of the conversation and run into the prefix check (see below).

Text in the system prompt for an opening sentence, progress messages, and a closing summary:

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 the first tool call every time in the tests. But output tokens increased by roughly 20%.

The minimal variant, if you can’t change the harness:

Every few tool calls, give the user a one-line update on where things stand.

Anthropic itself admits that even with all the measures, you have to expect several tool calls between messages. The model is tuned for long asynchronous tasks where a person returns only for the result. So if you don’t watch the agent in real time, you can safely skip this entire chapter.

Subagents

How much work Fable 5.2 delegates to subagents depends mainly on your harness. In tests with a minimal tool for spawning subagents, it rarely launched them. In an agentic tool whose prompts support delegation, it delegates willingly. Which is the case with Claude Code.

The procedure for your own harness (if you have one) is thus actually simple. First go through the system prompt, skills, and agent files and find sentences that encourage delegation. Change the description of the subagent-spawning tool only if the model still launches more subagents than necessary afterward. The new description should contain three things, in this order:

1. How much a subagent adds to the cost of the session.
2. When delegation pays off and when it doesn’t.
3. How the model should brief the subagent.

With such a description, the model in tests delegated about a third less, at the same success rate. But Anthropic doesn’t publish a sample description in the guide, so you’ll have to write it yourself.

At xhigh and max, Fable 5.2 launches subagents that check its own work. Fable 5.1 didn’t do this on the same tasks. And early testers had good results with Fable 5.2 as a planner that directs other (cheaper) models. So check which model your harness launches subagents on by default. A subagent on Fable at $40 per million output tokens is not cheap entertainment.

Caution that accumulates

This is a new type of problem and in my opinion not yet very well handled. Cautious instructions settle everywhere context is carried over: in memory, notes, instruction files, messages between agents. Fable 5.2 follows them very carefully, so it may ask for approval it doesn’t need or withhold routine work. Anthropic admits that in one of the tested setups only Fable 5.2 got stuck, while older models “walked past” the same instructions.

The concrete results from simulated tasks are quite telling:

• One old note is enough. Among a dozen notes from earlier sessions was one saying “never try again”. When the tool was busy, the model tried again in roughly 4 of 10 attempts. Without those notes, almost always.
• A general nudge doesn’t help, a specific exception does. A line at the end of the rules that listed retrying among the steps not requiring approval raised the number of retries from almost zero to roughly half. The general instruction “act more freely” changed nothing.
• Watch what review agents add. With a reviewer’s instruction “stop at the first error” in Fable 5.2’s context, the model did not retry in roughly a third of cases, even though the prompt explicitly allowed it. Fable 5.1 and Opus 5.5 did retry.
• Write the exception directly into the rule. Under a “never” rule, the model carried out a step approved by the responsible person in only about 1 of 10 cases. A separate line “an approved step has a green light” barely helped. When the rule itself said “first obtain approval”, the model carried out the step in roughly 9 of 10 cases.

The practical conclusion: go through the memories and notes your agents use and delete what no longer applies. Rewrite absolute rules so that they state their scope and reason. Allow retrying only for calls that are safe to repeat. Incidentally, some of those cautious notes were written by the model itself in earlier sessions. An agent that gradually preserves itself in amber is a pretty good illustration of why agent memory needs maintenance. And that is waiting for some tool that automates it.

What to throw out of old prompts

This chapter is probably the most practical for anyone migrating an existing system. Anthropic names seven types of instructions written for older models that on Fable 5.2 raise costs, have side effects, or don’t work:

The item with Opus 5.5 amused me most. Anthropic itself recommended these two sentences for chat prompts a few months ago. Now it admits that on Fable 5.2 they do save thinking on follow-up questions, but the model is then “much less likely” to point out mistakes in its own earlier answers. In other words, exactly what you want from a smarter model. A good example of how quickly prompt engineering goes stale.

Prefix check: the harshest change for developers

Fable 5.2 uses preserved thinking: thinking blocks from previous turns stay in the conversation and the model builds on them. But each such block is bound to what preceded it in the conversation. If you change the system prompt, the set of tools, or any earlier message between requests, the blocks after the changed point are invalid. The Messages API then rejects the request with a 400 error saying the block “belongs to a different conversation”. Retrying the same request doesn’t help.

For Fable 5.1 and Opus 5.5, this check applied only to accounts created from August 31, 2026. For Fable 5.2 it applies to everyone. So anyone who built their own harness that “tidies up” the history, rewrites the system prompt according to the state of the task, or changes tools dynamically will get errors after switching the model.

What to do about it:

• Only append to history. Keep the system prompt and tools the same, only attach messages at the end, and return assistant turns exactly as they arrived. According to Anthropic, Claude Code, claude.ai, Managed Agents, and the Agent SDK are not affected.
• Put new instructions into the latest turn or as a mid-conversation system message where available.
• To shorten history, use context editing or compaction.
• The emergency brake is thinking.block_binding.prefix_mismatch_behavior: "drop_block" (beta, header thinking-binding-controls-2026-08-01). Invalid blocks are dropped and the request goes through. But the model then thinks again and consumes more output tokens, in the worst case on every turn.
• Watch out for MCP. If you use an MCP connector without a pinned tool list, a change to the list counts as a modification of the history.

Incidentally, the same applies to the prompt changes recommended in this article. Make them in new conversations. A saved conversation resumed with a new system prompt will fail.

Clear final reports

After long agentic work, the final report is read by a person who hasn’t seen the tool calls or the opened files. For these cases Anthropic offers a block of 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.

The mentioned ASD-STE100 is a simplified technical English originally developed for aviation manuals: limited vocabulary, short sentences, one idea per sentence. For Czech output I would adjust this part, since the STE rules are defined for English. But the principle “write for a smart reader without context, put the important things first, don’t use abbreviations you made up during the work” works in any language. According to Anthropic, the text lowered the density of messages (fewer semicolons) and shortened sentences on automation tasks.

STE, by the way, says much more than “write briefly”. It’s a controlled language with a dictionary of approved words, where each word has only one meaning and one part of speech. The rules also dictate sentence structure: at most 20 words in procedures, at most 25 in descriptive text, one instruction per sentence, active voice, imperative for instructions, simple tenses, no clusters of more than three nouns in a row, and paragraphs of at most six sentences. One small thing amused me: the same guide a few chapters above warns that a hard rule like “one instruction per sentence, at most 20 words” turns Fable 5.2’s text into stilted prose. That’s why the block says “mostly in the style of” and doesn’t adopt the STE rules literally.

For Czech output I would replace the second paragraph of the block with something like this:

Piš jednoduchou češtinou pro technickou dokumentaci. Větu začni podmětem a slovesem. Věty drž většinou do 20 slov, jedna myšlenka na větu. Piš v činném rodu, děj vyjadřuj slovesem, ne podstatným jménem. Pro tutéž věc používej vždy stejné slovo a nestřídej synonyma. Odborný termín vysvětli při prvním použití. Pokyny piš rozkazovacím způsobem, jeden pokyn na větu. Odstavec má nejvýš šest vět a začíná nejdůležitější informací. Tato pravidla ber jako směr: kde související myšlenky potřebují souvětí, použij ho.

The last sentence is there deliberately. Without it, Fable 5.2 would follow the rules so precisely that the text would sound like a washing machine manual.

Refusals and Mythos 5.2

Fable 5.2 runs with safety classifiers that can refuse a request. The response then arrives with HTTP 200, but with a stop_reason: "refusal" and a category in stop_details.category:

I’d perk up at the frontier_llm category. The line between “developing a competing model” and ordinary work with training smaller models, distillation, or evaluating LLMs isn’t specified anywhere in the documentation. Anyone doing machine learning research should test it before building a production process on Fable.

The reasoning_extraction category is practically important. If your prompts, skills, or tool descriptions want the model to write its reasoning into the response (“first explain your procedure step by step”), remove them. To get a look into the reasoning, set display: "summarized" and read the thinking blocks.

You can react to a refusal with an automatic switch to a fallback model (fallbacks: "default", beta, header server-side-fallback-2026-07-01). The fallback models are claude-opus-4-8 and claude-opus-5, which, however, don’t receive Fable 5.2’s thinking blocks. A refusal in the reasoning_extraction category isn’t retried. A refusal always counts toward the rate limits and, depending on the category, can also be billed.

And Mythos 5.2? It’s the same model with the same capabilities and price, available only to organizations verified in Anthropic’s programs, for example the Cyber Verification Program or the Life Sciences Verification Program. It was released on November 9, 2026. If the cyber or bio classifiers block legitimate work in security or life sciences for you, the path leads through verification, but the documentation doesn’t describe the criteria.

Where to start when migrating

Anthropic recommends this order:

1. Set effort explicitly to high and run your own tests also at medium and xhigh.
2. Read all system prompts, skills, agent files, memories, notes, and harness texts that you’re carrying over. Remove or test the instructions from the table above.
3. Run your longest agentic tasks and watch where the model finishes prematurely, asks for unnecessary approval, stays silent, delegates more than necessary, or bolts on code where you wanted restructuring.
4. For each observed behavior, apply the corresponding advice, one at a time, and measure both the effect and the cost in tokens.

Step four is, in my opinion, the most important and the one most often skipped.

What to take away from this

I read the guide with mixed feelings. It’s unusually honest: Anthropic openly writes where its earlier recommendations do harm, how many tokens individual tweaks cost, and that some problems are not fully solved. That’s not a given in vendor documentation.

At the same time, I have to point out a few things.

All the numbers come from Anthropic’s internal testing. These are “small coding tasks”, “simulated tasks”, and “replayed sessions from an agentic product”. We don’t know the sample sizes, the variance, or the specific tasks. “Roughly half” can just as well mean 12 of 25 attempts as 500 of 1000. Take it as a rough direction that you must verify on your own tasks.

Every recommended tweak costs something. Continuing work: +30% output tokens, progress messages: +20%, code ownership: 1.5×. If you deploy everything at once, you can easily spend the lower per-token price on more tokens. Add the default high effort and thinking before a greeting. The price cut from $10 to $8 may in practice mean the same or a higher bill.

A model that listens literally is a double-edged sword. Most of the guide is about mitigating the consequences of Fable 5.2 following instructions more precisely than its predecessors. From a safety and predictability standpoint, that’s a good property. Practically, though, it means every forgotten sentence in a prompt, every old note in memory, and every condition from a review agent carries more weight. Prompts and agent memories thus become code that needs maintenance, review, and tests. Anyone who hasn’t been doing this so far has to start now.

The prefix check is a real burden for custom solutions. For Claude Code users nothing changes. For anyone who has built their own agentic loop with “clever” context management, it means rewriting it to a model where history is only appended.

In summary: Fable 5.2 looks like a capable model for long autonomous work, but moving to it requires more than changing the model identifier. Anyone who doesn’t set aside an afternoon to clean up prompts and memories and measure consumption on their own tasks will be in for a surprise. Either an agent waiting for an approval nobody will give, or the bill.