Eight Prompting Rules That Changed With Claude Fable 5.1
Claude Fable 5.1 shipped on September 1, 2026, and Anthropic paired the release with something more useful than a changelog: a model-specific prompting guide. If you maintain prompts written for Claude 3, 3.5, or early 4-era models, that guide is effectively a migration notice. Several defaults you have been engineering around for two years are gone, and a handful of habits that used to be harmless now actively hurt output quality.
This is the practitioner's read of it. Every section below ends with something you can paste into your own system prompt today.
Why Fable 5 prompts quietly degrade
The failure mode is not a crash. Prompts written for older Claude models still run on Fable 5.1 — they just cost more, take longer, and land a notch below what the model can actually do. You get plausible-looking output and never learn it was mediocre.
Three patterns cause almost all of it. First, prompts written to fight the old model's reluctance, so they over-constrain a system that no longer needs the leash. Second, prompts written when a single long context plus one giant instruction block was the only reliable pattern, so they ask for work the runtime can now stage itself. Third, prompts that encode old assumptions about when the model searches, edits, and delegates.
Anthropic's guide makes the direction of travel explicit: describe the outcome, not the machinery. Most of the eight shifts below are special cases of that one idea.
Shift 1: effort is the primary cost dial
The old mental model was tokens in, tokens out, and maybe a thinking budget you raised only for hard problems. Fable 5.1 exposes effort as a first-class setting, and the guide frames it as the main thing you tune. Low effort changes behavior, not just speed: the model is terser, reaches for fewer tools, and stops narrating.
Most teams are running too high by default. A classification pipeline does not need the effort level you would give a multi-file refactor. Set effort per call site, not per product.
Draft a customer-facing summary at low effort.
Escalate to high effort only for the final compliance check.If you find yourself stacking 'be concise' instructions on top of a high-effort call, that is the tell: you wanted lower effort, not more prompt text.
Shift 2: silence during long tool runs
Older prompts often demanded a running commentary, because a silent model looked like a stalled model. On Fable 5.1 the guide describes the opposite default: during long tool runs the model goes quiet and returns when it has something to report. Prompt-level requests for play-by-play narration now produce filler that your downstream parser has to strip.
The practical rule: put status reporting in your harness, not in your prompt. If you need liveness, wrap the tool call in your own progress event. Do not ask the model to narrate its own waiting.
Work through the tool calls silently and report once at the end.
If a step needs a decision from me, stop and ask instead of guessing.Treat narration as an interface concern. The model should report outcomes and blockers; your client should report progress.
Shift 3: one tool call per turn
Prompts written to batch — 'call all the lookups you need, then answer' — fight the newer loop. Fable 5.1 is built around one tool call per turn, then reading the result before choosing the next call. That is slower per step and much better on any task where call two depends on what call one returned.
If you have an explicit batching instruction, pull it. The model will usually pick the right next call by itself, and when it does not, the fix is a better tool description rather than a bigger instruction block.
Shift 4: the append-only history rule
The guide is unusually blunt here: conversation history is append-only. Prompts that tell the model to rewrite or compress earlier turns can produce contradictory state, because the earlier turns are still in context and still authoritative.
If you need to correct something, append the correction. If you need to reset, start a new conversation. Do not ask the model to retroactively edit its own record.
History is append-only. Never rewrite earlier turns.
To correct a mistake, append a short note stating the correction.Shift 5: targeted edits, not whole-file rewrites
Whole-file rewrite instructions were a reasonable hedge when edits were unreliable. On Fable 5.1 they waste effort and inflate risk: a rewrite touches every line, so every reviewer has to re-read everything, and unrelated formatting churn shows up in the diff.
Ask for the edit you want. Name the function or region, state the change, and let the model pick the smallest patch.
Shift 6: search is not automatic at low effort
A subtle one. Prompts that assume the model will search whenever freshness matters are now unreliable at low effort, where the guide has the model reach for fewer tools. If your workflow depends on current information, that dependency belongs in the prompt or in your harness — not in an assumption.
The corollary: do not hard-code a mandatory search step for questions that never needed it, or you pay tool latency on every trivial call.
Shift 7: scope creep and compaction summaries
Two related failure modes. First, prompts that enumerate every possible edge case in exhaustive detail invite the model to work on all of them, including ones you did not want touched. State the boundary instead. Second, when a long session gets compacted, the summary carries forward whatever you told the model was important. Vague priorities become vague summaries and then vague work.
Write your priorities so they survive summarization: short, ordered, and stated in outcome terms.
Shift 8: delegate without stalling
Older prompts often added permission-seeking gates — 'ask before proceeding' — because autonomous action was risky. On Fable 5.1 that pattern stalls long runs on questions you never wanted to answer. The guide's stance is delegation with explicit stop conditions: act freely inside the stated scope, stop only for decisions that genuinely need a human, such as money, credentials, or irreversible operations.
The eight shifts at a glance
- Effort is the cost dial: tune effort per call site instead of stacking conciseness instructions.
- Silence during tool runs: move progress reporting into your harness, not your prompt.
- One tool call per turn: drop batching instructions and improve tool descriptions instead.
- Append-only history: append corrections, never rewrite earlier turns.
- Targeted edits: name the region and the change; stop asking for full rewrites.
- Search is not automatic: state freshness dependencies explicitly at low effort.
- Scope and compaction: set boundaries, and keep priorities short enough to survive summarization.
- Delegate without stalling: act inside scope, stop only for money, credentials, or irreversible actions.
A migration pass you can run today
Do not rewrite every prompt at once. Start with the highest-volume call site and read it against the eight shifts above. In practice the wins come from deletion: remove the batching instruction, remove the narration request, remove the ask-before-acting gate, then set effort to the lowest level that still passes your evals.
Run the same eval set before and after. The interesting result is usually that the shorter prompt scores the same or better while costing noticeably less — which tells you the extra text was never doing the work you thought.
The Road Ahead
Model-specific prompting guides are becoming the real release notes. The API surface changes slowly; the behaviors that make a prompt good or bad change with every version, and a prompt is only as portable as the assumptions baked into it.
Two habits are worth keeping. First, keep prompts small and outcome-shaped, so a version change has less old machinery to invalidate. Second, keep an eval set you trust, because the only reliable way to know whether a behavior shift helped your workload is to run it. Migration guides tell you what changed; your evals tell you whether you care.
