Claude Fable 5.1's prompting guide changes what devs need to write

The official Claude Fable 5.1 prompting documentation opens with a reassuring line: "your existing Claude Fable 5 prompts should work well on Claude Fable 5.1 without changes." In practice, for those building agents and code pipelines, this line hides an important detail: several of the instructions the team pasted into the system prompt over the past months are now pushing the model in the wrong direction. The default behavior changed, and defensive rules written against the older models became silent sabotage.

This piece covers what changes in the code of those who operate these agents day to day, not the doc's entire list. The focus is: what you remove from the prompt, what you add, and where the money (tokens) leaks if you do nothing.

The effort level isn't the same as before

The main cost/latency/intelligence control is the effort parameter, with the levels low, medium, high (default), xhigh, and max. The point the doc hammers hard: the level names don't represent the same amount of reasoning across models. If you calibrated effort on Fable 5, you need to redo the sweep on 5.1, because the mapping changed.

Two practical numbers straight from the doc are worth rereading:

• At medium, Fable 5.1 delivers output "roughly" equivalent to Fable 5, only cheaper. In other words: where quality holds up in your evaluations, you can drop from high to medium and cut cost without losing output.
• At low, the doc states that 5.1 "tends to be competitive with the Claude Opus and Claude Sonnet models in cost per task while scoring higher." This is a cost-architecture recommendation: instead of running a smaller model at higher effort, it's worth comparing against 5.1 at low.

Since this is a claim from the vendor, the honest reading is to treat it as a hypothesis to validate with your own evaluations, not as a closed benchmark. But the playbook is clear: run the same evaluation suite at low, medium, and high and let the number decide.

The old rules that now get in the way

Here's the part that generates the most rework, and the pattern repeats across three fronts: the old model was "too excited" about something, teams wrote rules to contain it, and 5.1 already corrects in the opposite direction, so the old rule overshoots.

| What you probably have in the prompt | Why it was there | What it does in 5.1 | |---|---|---| | "Save all findings for the final response" | Older models narrated too much between tool calls | 5.1 already narrates little; the rule leaves the user with no progress updates at all | | Anti-formatting rules (banning bullets, bold, headers) | Older models overused lists and bold | 5.1 already under-formats; the rule leaves responses without the structure the content calls for | | Nothing about prose density | Wasn't a problem before | 5.1 writes more densely, with long sentences and few paragraphs |

The doc's guidance is to audit the prompt and remove these lines before adding anything new. Only afterward, if behavior is still missing, do you add a conditional rule ("use lists when the content is multifaceted enough for clarity to help") instead of an absolute ban.

To contain dense prose, the doc suggests describing the antipattern instead of just asking to "write simply." The long version explains the concept of "mannered prose" (trading a direct statement for a metaphor), but there's a short version that tends to work: Please remove all mannered prose. The material sent by whoever suggested this piece sums up that philosophy as "be literal and simple: use clear words and avoid metaphors," which is exactly the thrust of the official recommendation.

Where tokens leak: batching and thinking blocks

Two plumbing changes deserve attention from anyone running an agent loop.

The first: in coding loops and computer use, when the next independent calls are implicit in the task (and not explicitly requested), 5.1 may issue one tool call per turn instead of parallelizing. Every extra turn is a round trip, tokens and wall-clock time thrown away. The fix is a one-sentence reminder at the end of the request:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

The fine detail is where to place this reminder on each turn. The doc recommends sending it as a turn-scoped system message (role: "system" with clear_at: "next_user_message", beta under the mid-conversation-system-clear-at-2026-08-21 header). As soon as a new user message exists, the API clears the older copies, and the model reads only the most recent one, at no cost from the previous ones.

The second, and more dangerous to ignore: the conversation history must be append-only. For accounts created on or after August 31, 2026, Fable 5.1's thinking blocks are valid only in the exact conversation that produced them. If the prefix (system prompt, tool list, or any prior message) changes between requests, resending a thinking block returns HTTP 400, or drops the blocks if you set thinking.block_binding.prefix_mismatch_behavior: "drop_block".

Future models are expected to enforce this check for all accounts, so adopt the pattern now even if yours isn't checked today.

>

-- Claude Fable 5.1 Documentation

In practice: injecting and removing per-turn reminders, summarizing old turns in place, or changing the system prompt mid-session are exactly the edits that break this, and they're the same ones that reset the prompt cache. The recommendation is to append each assistant turn byte for byte as the API returned it, including the thinking blocks, and never rewrite earlier turns. If you need to compact on the client side, the cleanest path is to replace the entire history with a summary plus the new user turn and resend no thinking block at all, that way nothing fails because no thinking is loaded.

A cost side effect: since cache reads got cheaper in 5.1, compacting early to save money may no longer be worth it. The doc suggests experimenting with later compaction points.

Autonomy: telling it to finish the whole task

In long asynchronous workloads, 5.1 sometimes describes what it would do ("Next, I'll...") or stops to ask permission for something the original request already covered ("Should I apply this?"). This forces the user to reply "continue," which makes sense in pair programming but wastes the model's long-horizon capability in autonomous work. The doc provides a ready-made line for the system prompt that instructs the model to operate autonomously, proceed with reversible actions derived from the original request, and stop only for destructive actions or genuine scope changes.

An important caveat so as not to overdo it: this is for autonomous work, not supervised work. In pair programming and human-in-the-loop flows, the behavior of asking for confirmation is desirable, and the "finish the entire task" instructions point in the opposite direction from the progress-update ones. The choice depends on your product's mode.

What to do today, and where it's not worth touching

The practical summary for the Brazilian dev who already has agents live with Fable 5: open the system prompt, delete the anti-formatting rules and the "save everything for the end" ones, redo the effort sweep with your evaluations, enable progress thinking blocks (display: "updates") if you want the user to see what the agent is doing, and make sure the harness only appends to the history.

Where it's not worth it: if your use case is simple, synchronous chat, with short prompts and no tool loop, most of these changes change nothing. And migrating everything at once without running evaluations first is the classic mistake, several of these recommendations (effort, density, formatting) are only justified by a number measured in your own case, not by the doc's generic promise.