Switch Off Claude Fable 5.1 Mid-Task and It Forgets Why

Claude Fable 5.1 shipped on September 1, 2026 with a rule that most release coverage reduced to a bullet point: its thinking blocks can be read by Fable 5.1 and Mythos 5.1, and by nothing else. Anthropic states it plainly in the migration guide. Fable 5.1 reads the reasoning of Opus 5, Fable 5, Mythos 5 and every earlier Claude model, so a conversation moving up onto 5.1 keeps its history. The condition is one-way. If a conversation that has been running on Fable 5.1 lands on any older model, the API removes the blocks that model cannot read before it sees them.

That sentence matters far more than it sounds, because production agent systems move conversations between models all the time and almost never on purpose. A cost router downgrades a routine step. A retry wrapper falls back after a timeout. A safety classifier declines a request and the fallback setting re-runs it on Opus 5. In every one of those cases the cheaper model receives the transcript, the tool calls and the tool results, and none of the reasoning that produced them. Anthropic’s own description of the consequence is that “the target model re-plans without that reasoning, which can raise cost and latency on the first turn after the switch.” This post is about what that means for a loop you already run, and the one routing rule that avoids it.

A thinking block is the reasoning a Claude model produces before it answers or calls a tool. In a multi-turn conversation you pass those blocks back with the history, and the model uses them to continue where it left off rather than re-deriving its plan. On Fable 5.1, each block carries a signature that identifies the model that produced it and the conversation it was produced in. The table below is the compatibility rule as Anthropic documents it, read from the point of view of a conversation that has already been running on Fable 5.1.

Two details in that table decide the rest of the post. First, the two models Anthropic permits as automatic fallback targets for Fable 5.1, Opus 4.8 and Opus 5, are both on the losing side of the line. A refusal fallback is therefore a downgrade by construction. Second, the direction is asymmetric in a way that is genuinely useful: starting a task on a cheaper model and handing it up to Fable 5.1 when it gets hard preserves everything. The expensive mistake is the other order.

Anthropic’s guide names three routes by which “a conversation that ran on Claude Fable 5.1 can land on an older model”: a router switch, a client-side retry, and a classifier refusal fallback, including the server-side fallback Anthropic itself offers. There is a fourth that the guide does not need to name because it is deliberate: the cost-saving handoff, where a team runs the hard planning turn on Fable 5.1 and the routine execution turns on something cheaper. All four produce the same result. They differ in how often they fire and how easy they are to notice.

The refusal route deserves one more sentence because it is the only one Anthropic actively encourages. The fine print of the launch, which we covered in what Claude Fable 5.1 costs and what it breaks, is that Fable 5.1 still redirects penetration testing, exploit generation, binary vulnerability scanning and life-sciences research to the Opus models. A fallback path is therefore still required for any agent that might wander into those areas. It is just that the fallback now arrives with amnesia, and a security agent that has spent twenty turns building context on a codebase is exactly the kind of task where that hurts.

It is worth being exact about what is and is not billed, because the shape of the cost is unusual. Anthropic states that when blocks are removed for a model that cannot read them, “the request succeeds, and you aren’t billed for the dropped input tokens.” So the direct cost of the switch is zero, and on a per-request dashboard the downgraded turn can look cheaper than the turns around it. The cost lands one step later. The cheaper model has to reconstruct, from transcript alone, a plan that the expensive model already held in its reasoning, and Anthropic’s stated consequence is higher cost and latency “on the first turn after the switch.”

Three things follow for anyone measuring this. The first is that the cost is paid in the cheaper model’s output tokens and thinking, which is why it does not show up as a spike on the Fable line of the bill. The second is that on a long task the first turn after the switch is not the only one affected: a re-planned task can take a different route to the same goal, calling tools the original plan had ruled out. We have no measurement of how large that effect is on real workloads, Anthropic does not publish one, and the honest statement is that it depends on how much of the plan lived in the reasoning rather than the text. The third is that a conversation which is bounced down and then back up pays twice: once for the re-plan on the cheap model, and once more when Fable 5.1 resumes with a history that now contains the cheap model’s reasoning in place of its own. That upward hop keeps the Opus blocks, which is better than nothing, but they are Opus blocks.

By default nothing in the response tells you that reasoning was removed. Anthropic provides a way to change that. Send the beta header thinking-binding-controls-2026-08-01 and responses carry an input_transformations array that names each dropped block with a reason. Two reasons exist and they mean different things:

• model_binding_mismatch: a block was produced by a model the current one cannot read. This is the downgrade described in this post. After a model switch it is expected; anywhere else it means a switch happened that you did not intend.
• prefix_binding_mismatch: a block was produced against a system prompt, tool list or history that has since changed. This is the other Fable 5.1 rule, the one that makes conversation history append-only, and it is a bug in your harness rather than a routing decision.

The practical use is a two-line audit. Run a representative session with the header set, log the array on every response, and count the model_binding_mismatch entries. Each one is a turn where a cheaper model re-planned from scratch. If the count is non-zero and you did not design a downgrade into the loop, one of the four routes above is firing without your knowledge, and the retry wrapper is the usual culprit. Anthropic adds a note for anyone who ships a tool that other people run with their own API keys: the history check is enforced by default only for accounts created on or after August 31, 2026, so your key may be older than your users’ and you should test with the controls set rather than waiting to hit the error yourself.

The asymmetry in the compatibility table gives you a routing rule that is simple to state and, conveniently, matches Anthropic’s own advice to start most workloads on Opus 5. Begin a task on the cheapest model that might finish it. If it stalls, hand the same conversation up to Fable 5.1, which reads everything the cheaper model thought. Once a conversation is on Fable 5.1, keep it there until the task boundary. When the bill needs to come down, change the effort level, not the model. Anthropic’s launch guidance is that Fable 5.1 at medium effort “roughly matches Claude Fable 5 at lower cost,” and on Fable 5.1 effort can be changed part-way through a conversation with a system message that carries only an output configuration, without invalidating the prompt cache or any thinking block. A model change can do neither. Our effort ladder reference lists what each level maps to across vendors.

The one pattern this rule changes most is the deliberate handoff, plan on Fable and execute on something cheaper in the same conversation. It is not forbidden and it may still be the right trade. It now needs the plan to be fully expressed in the text the planner returns, because the executor will see only that text. Teams that already write plans as explicit, self-contained artifacts will notice nothing. Teams that relied on the model carrying its intent forward in thinking will find the executor improvising. The general routing question, which model earns which turn, is covered in our model routing guide; what changed on September 1 is that on Claude the answer must now be decided per task, not per turn.

The model-binding rule has a sibling, and any team that fixes one should fix both in the same pass. A Fable 5.1 thinking block is also bound to the conversation that produced it, meaning the system prompt, the tool list and every earlier turn. Change any of those and the blocks after the change are invalid. Where the check is enforced, the API rejects the request with a 400 stating that “the block is bound to a different conversation.” The patterns that trip it are the everyday ones: summarising old turns in place on the client, deleting old tool results, injecting a per-turn reminder and removing it next time, rebuilding the system prompt to update the date.

Anthropic’s recommended shapes are worth quoting because they are more permissive than the rule sounds. Simple compaction, where you replace the whole history with one summary message and replay nothing else, is fine because no thinking blocks are carried over at all, and Anthropic says its models perform comparably under that scheme to more elaborate ones. Keep-tail compaction, where recent turns stay verbatim behind a summary, works if you strip the thinking blocks from those turns or set the prefix-mismatch behaviour to drop them. Server-side compaction and context editing do not count as edits at all. The one thing no client-side shape survives is snipping individual turns out of the middle. The through-line with the routing rule is the same: on Fable 5.1, reasoning is attached to a specific model in a specific conversation, and anything that changes either of those throws it away. The cache economics that make keeping context cheap were covered in our cache-first agent design piece; this rule is the reason to act on them.