Why Claude Fable 5 switches models mid-conversation, and what it costs

We were working with Fable 5 as usual, purely on software and business analysis, when the model answering switched to Opus mid-conversation. Not long after, the AI assistant went and built a whole thing nobody asked for. All of this happened in a conversation with nothing risky in it. Understanding how the system works explains where the glitch came from.

Part 1Normally Fable 5 switches when it hits something risky

Fable 5 is a newer, more capable model. More capability means more room for misuse, so Anthropic built in safeguards on purpose. When a request falls into a risky area, the system blocks it and switches to Opus 4.8 automatically, a safer model. The official docs name four risky areas: offensive cybersecurity, lab-level biology and chemistry, attempts to extract the model's summarized reasoning, and frontier language-model development. By design, the switch is a safety mechanism, not a malfunction.

What users often miss is that the system does not look only at your latest message. The docs are explicit: it examines everything the model reads, including saved memory, attached files, web search results, and external connectors. Once it switches, the model picker stays on Opus for the rest of the conversation. You can switch back to Fable 5, but if the content that triggered the block is still there, it can switch again.

Part 2But our conversation had nothing risky in it

Here is where it gets interesting. What we discussed with Fable 5 was software work and business analysis, plain and simple, nothing that touched any of the four risky areas. The model switched anyway.

When the content of the conversation is not the cause, the remaining explanation is the system itself. Because the check reads everything the model sees, not just the question in front of it, heavy real-world use with accumulated memory, files, and long conversations gives the check more unrelated material to weigh, and it can misread something and switch without the user doing anything risky. This is a false alarm, not the user's fault.

As for the work the AI did on its own that nobody asked for, that is a straight model error. It picked up text floating in the context and counted it as an instruction. Saying the model switch directly caused the unasked-for work would go beyond the evidence, since we cannot see the internal mechanism. What we can say is that both the false alarm and the stray work are model-side, not the fault of someone having an ordinary work conversation.

Part 3What this design costs

The switching design is genuinely safer, but it trades away two things worth seeing.

First, the conversation loses continuity. You start with one model, but another takes over mid-task. The two can read the context and carry the work forward differently, so when half-finished work is handed to a new model, the result is not guaranteed to stay consistent.

Second, the trigger is hard to predict. Because it reads everything, you might get switched over an old file or a memory you forgot was there, not the question in front of you. The heavier your usage, the more likely you hit it by accident.

What users should know

The switch is labeled, so you can see which model answered. Watch that label. If you do not want automatic switching, you can turn it off in settings, and the system pauses instead of switching. Billing follows where the block happens: blocked at the input, you pay Opus rates; blocked midstream, you pay Fable 5 rates for the early part and Opus for the rest.

And if you hit a false alarm on work with nothing risky in it, know that it is not because you did something wrong. It is a design that reads so broadly it trips over its own shadow. For big, hard-to-undo tasks, do not let them run across the point where the model might switch, because that is where the output is least reliable.