Claude Fable 5.1 does more than earlier models — and sometimes more than you asked. The two most common shapes: rewriting a whole file where a small edit would do, and expanding the scope with fixes to nearby code, extra tests, and scratch checks committed as permanent test files. Both respond well to being told explicitly what to leave alone.

Whole-file rewrites

Same result, more tokens, more time, and a diff that's hard to review because everything moved. One line in your system prompt or first message restores targeted edits:

targeted-edits.txt
The number of tokens used to edit files is best minimised, all else
being equal. When it won't affect the end result, surgically edit a
file rather than rewriting the entire thing.

If you're using Claude Code, this belongs in your project's CLAUDE.md so it applies every session.

Unrequested extras

Asked to implement a feature, it may also fix a bug it noticed, tidy adjacent code, and write tests for things the task didn't mention. Well-intentioned, and it makes the diff harder to review and the change harder to revert. Anthropic's testing found this prompt cut unrequested additions substantially with no loss in task success:

scope-and-tests.txt
If, while working or testing, you find a pre-existing bug, a
performance concern, or behaviour the task doesn't mention, don't fix,
optimise or extend it in this change unless the requested behaviour
cannot work without it — report it as a follow-up in your summary.

Where the task is ambiguous, implement the reading its wording and the
surrounding code most directly support, state that assumption, and
don't build for the other readings as well.

Verify your work however you like; scratch scripts need not be kept.
Commit tests only where the task asks for them or this repository
already keeps tests for this kind of change, sized like the neighbouring
test files — roughly one focused test per stated behaviour. Don't turn
scratch checks into additional permanent test files.

This is about extras only: implement every behaviour the task asks for,
completely.

The last line matters. Without it, "don't do extras" can bleed into "do less".

Unrequested tidying at high effort

At higher effort on routine work, the model may refactor, add abstractions, or introduce error handling for cases that can't happen. This keeps it simple:

no-gold-plating.txt
Don't add features, refactor, or introduce abstractions beyond what the
task requires. A bug fix doesn't need surrounding cleanup; a one-shot
operation doesn't need a helper. Don't design for hypothetical future
requirements. Only validate at system boundaries — user input, external
APIs — and trust internal code. Don't add feature flags or compatibility
shims when you can just change the code.

Boundaries on adjacent actions

Occasionally it takes an unrequested-but-adjacent action: creating a backup branch, composing something straight to a draft, applying a fix when you were only asking a question. Say what you don't want:

boundaries.txt
When I'm describing a problem, asking a question, or thinking out loud
rather than requesting a change, the deliverable is your assessment.
Report your findings and stop. Don't apply a fix until I ask for one.

What not to do

Don't fight it by adding more rules every time it oversteps. Pick the two or three blocks above that match your actual problem, put them where they apply every session, and stop. Fable 5.1 follows explicit instructions well; a small number of clear boundaries beats a long list of prohibitions.

Scope creep from a model is still scope creep. The fact that the extra work is good doesn't make it what you asked for, and a diff you didn't expect is a diff you can't review properly.