Claude Fable 5.2 and old cautions in agent memory: what Anthropic measured

Anthropic shipped Claude Fable 5.2 on November 9 with a prompting guide, and Claude Code 2.1.321 made it the default Fable model. Much of the guide covers effort levels and readable reports. One section covers something every long-running agent setup accumulates: the cautions left in memory files, notes, instruction files and messages between agents.

The guide’s claim is short. Fable 5.2 follows those instructions closely, so it may ask for approvals it doesn’t need or hold back routine work; a few early testers saw it, mostly where several agents work together. Every figure below is Anthropic’s, from its own testing. My read is that the tests show a problem the guide’s remedy passes over. It says to delete the cautions whose reason no longer holds, and most notes never wrote their reason down.

How much do old notes with a “never retry” cost Claude Fable 5.2?

In Anthropic’s simulated tasks, a dozen notes from earlier sessions, one of which said never to retry, cut retries after a busy tool from nearly every try to about four in ten. Nothing in the prompt allowed retries. A busy tool is about the most ordinary obstacle an agent meets, and the note didn’t say whether its “never” was about this tool, a bad week or a bug fixed since. Nothing in it lets the model tell those apart.

Why doesn’t “act more freely” unblock Claude Fable 5.2?

Because the general nudge changed nothing in Anthropic’s test, while naming the step did. This setup was heavier than the first one: “never” rules, notes and a reviewer’s conditions all in context, with retries at almost none. One line at the end of the rules, listing retries among the steps that need no approval, raised them to about half.

A broad “be less cautious” is up against specific sentences already in context, and in this test it lost. The guide limits the fix to calls that are safe to repeat. A retry on a payment or a message send is not routine.

Does a reviewer agent’s stop condition leak into Claude Fable 5.2’s own work?

In about a third of tries. In one setup the prompt already listed retries as needing no approval, and a reviewer’s “stop at the first error” sat in context. Fable 5.2 skipped the retry in about a third of tries. Fable 5.1 and Opus 5.5 retried.

The guide’s advice is to check what reviewer agents attach. I’d go further. A reviewer writes its conditions for its own review, and once one lands in the worker’s context nothing says so, so in a third of tries Fable 5.2 applied it to its own work. That argues for putting something between reviewer output and the worker, whether a filter or a scope stated on every condition, rather than only tuning the reviewer’s prompt.

Where should an approval exception go for Claude Fable 5.2?

Inside the rule. In Anthropic’s test the person in charge had approved a step. Under a “never” rule the model took it in about one try in ten. A separate line saying an approved step has its go-ahead barely moved that. When the rule itself said to get a go-ahead first, the model took the step in about nine tries in ten.

Separate line:  Never do X.  (...)  An approved step has its go-ahead.
In the rule:    Do X only after a go-ahead from the person in charge.

The guide describes the setups in prose; the two lines above are my shorthand for them, not its wording. Put the exception in another paragraph and the model has two sentences that disagree. In this test the “never” won nine times in ten.

How literally does Claude Fable 5.2 read an approval list?

Word for word. In simulated tasks with nobody there to approve, one rule listed “sending messages to people outside this conversation” among the steps that need approval. The model held back roughly half of its routine requests to colleagues and other teams. The guide’s fix is to name the exact actions a rule covers.

The test was about messages to people. My read is that in a multi-agent setup the same phrase can catch a handoff to another agent or a status ping too, if the harness delivers those as messages, because nothing in the phrase says otherwise.

What do Anthropic’s fixes cost Claude Fable 5.2 in tokens and side effects?

They are instructions too, and Fable 5.2 follows them just as closely. With the ownership sentence (“This codebase is yours: what it’s for and how it’s built are your call, and you’ll keep building on it.”), the model merged repeated code in about half of its tries on small coding tasks, against under a tenth without it. It also used about 1.5 times the output tokens, added tests and documentation nobody asked for, and, apart from bug fixes, changed how an existing feature behaves in between one try in ten and one in six. The guide’s finish-the-whole-task text halved the replayed sessions that ended with doable work left at medium effort, at about 30 percent more output tokens. Anthropic tested a version of that text, and it explicitly keeps confirmation for risky or destructive actions.

The ownership case runs the other way from the cautions. 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, so an explicit prohibition lost to a later grant. The pattern is not that prohibitions win. A specific sentence tends to beat a general one, and the guide’s numbers don’t say what decides it when both are specific.

Which Claude Fable 5.2 numbers can you check?

None of them directly. The guide gives no task counts, no task lists and no variance, and the comparison with Fable 5.1 and Opus 5.5 among the caution cases comes from one setup only. Treat the percentages as the shape of the effect on Anthropic’s tasks. Yours will differ, and the guide gives you nothing to estimate by how much. It says as much itself: apply one change at a time and measure its effect and token cost on your own work.

Who decides when a Claude Fable 5.2 memory caution is stale?

The guide’s answer, before you migrate, is to delete the cautions whose reason no longer holds, rewrite absolute rules so they state their scope and reason, and keep a copy of the originals. It also notes the model might have written some of those cautions itself. The instruction assumes the reason can be recovered. For a caution with no reason beside it, it can’t, by the owner or by the model.

The agent in session could try the retry and see whether it fails. That tells it whether the tool works today, not what the note was guarding against, and a note that guarded something real gets dropped on the same evidence as a stale one.

For CLAUDE.md I’ve argued the fix is to keep the reason in the file and the incident in git, where blame can find it. Memory often has no git under it, and whether a page keeps its past depends on where it happens to live. So the reason, the scope and the date have to go into the note itself when it is written, and the writer is usually the model. The instruction that tells your agent to save a caution is the place to require all three.

Pruning has its own trap on Fable 5.2. In hand-built Messages API code, a request that replays thinking after system, tools or an earlier message changed returns a 400 by default, so a memory file your code injects into a live conversation should change only in a new one. Requests built by Claude Code or the Agent SDK are not affected.

If you run agents with memory, read the notes the way Fable 5.2 meets them: every line is in context, and none of them carries a date. A “never” that says what it guards against and who can lift it can be retired. One that doesn’t stays until someone deletes it on a hunch.