How Claude Fable 5.2 wants to be prompted.

Here's what I'd take from it, in the order I'd act on it. Every number below is Anthropic's, from their own testing, and every line I lean on is quoted in the sources at the bottom so you can check it.

Effort first

Effort is the setting that decides how much the model thinks, how many tool calls it makes and how many tokens it burns. High is the default on the API, and at high the model thinks before almost every reply, even a reply to a greeting.

Anthropic says medium suits interactive coding, chat and everyday knowledge work. High is for the hard stuff: hard coding, research, agentic work and long runs nobody is watching. If basic requests are slow or costing you more, use a lower effort for those turns.

Worth knowing: telling it to "answer directly without deliberating" doesn't stop it thinking at medium and above. So don't try to prompt your way out of it. Turn the effort down instead.

It sometimes stops before the job's done

On long, multistep tasks, Fable 5.2 sometimes ends a turn before the work is finished. It lists what's left, offers to keep going, or stops at an ordinary obstacle like a timeout. That happens more at low and medium effort.

Anthropic tested a block of system prompt text that tells it to keep going and work through ordinary obstacles. With a version of that text, about half as many sessions ended with unfinished work. The catch is output tokens rose about 30 percent.

And because it asks you less often with that text in, keep your own confirmation step for anything risky or that can't be undone.

The ownership sentence

Fable 5.2 pays close attention to who owns the code. Tell it nothing, or tell it the codebase is someone else's, and it tends to add to what's there, even if that means duplicating code that already exists. Tell it the code is its own and it often merges the duplicates and sometimes fixes related things without being asked. The sentence Anthropic gives you:

You are the owner and long-term maintainer of this codebase, and its design is up to you.

On small coding tasks, that one line took merging duplicated code from under 10 percent of runs to about 75 percent.

But output tokens rose about 70 to 80 percent, and it made changes nobody asked for, a lot of them new tests and docs. So only use it on code you're happy for it to restructure. If you want your code changed as little as possible, leave it out. A "no drive-by refactors" rule in the same prompt doesn't cancel it. It can also change how an existing feature behaves, and its summary of what it did often leaves the small changes out, so read the diff.

The free one: clear out your old "never" rules

This is the one to do today, and it costs nothing. The model treats an instruction with "never" in it as absolute. So old rules sitting in your memory and notes files, like "never retry", keep getting followed long after the reason for them is gone.

Open your memory, notes and instruction files and search for "never". Delete the ones that don't apply anymore. For the ones you keep, say what you actually want: "ask for approval before deleting files" instead of "never delete files", so it knows the rule has a scope.

Make those edits and then start a new conversation. Anthropic warns that changing the instructions partway through a stored API conversation can make the request fail.

Want a hand with it? The Fable 5.2 Prompt Tune skill reads your prompt, memory and skill files and tells you which "never" rules are stale, which need a scope, and which ones fight each other. It suggests only; you decide what changes.

If you only do one thing

Do the never-rules clean-up. Then set your effort on purpose instead of leaving it on the default, and only reach for the ownership sentence on code you'd let it rearrange.

Docs change, so read the guide itself before you build on any of this. The link's below.