claude code internals · 9 min read · 2026-07-10

Every way Claude Code switches models without asking

You picked Opus. Twenty minutes later the diffs look different, the plan drifted, and a tiny notice you missed says the session has been running on Sonnet for a while. You didn't touch /model. Claude Code has five separate mechanisms that change your model automatically, and each one has different triggers, different controls, and the same hidden side effect: a destroyed prompt cache. Here's the complete list.

1. The usage-cap downgrade (the one everyone hits)

On Pro and Max subscriptions, Opus usage is capped at a fraction of your rate-limit window. When you cross it mid-session, Claude Code doesn't stop. It prints a small notice along the lines of "Opus limit reached, now using Sonnet" and keeps going on Sonnet, even if you explicitly selected Opus. This is the most complained-about switch in the product: issue #3434, "Claude silently falls back to Sonnet after Opus cap, breaks workflows, please allow opt-out", collects reports of sessions that lost the thread mid-refactor after the swap: ignored instructions, touched files that shouldn't have been touched, a different model quietly finishing a job the stronger model planned.

Control: there is no opt-out setting today. Your levers are upstream: watch usage before starting long Opus runs, put Opus-worthy work early in your window, and route everything mechanical to a cheaper model so you don't burn the Opus budget on chores. (More on the routing setup below.)

2. opusplan: a scheduled downgrade you opted into

The opusplan model alias is a deliberate hybrid documented in the model configuration docs: Opus while you're in plan mode, then an automatic switch to Sonnet the moment execution starts. Great deal per token, but it's still a mid-session model change, with two things worth knowing:

• The switch point is the plan/execute boundary, so your accumulated planning context gets re-read by Sonnet at the swap.
• Edge cases have bitten people: a reported regression had plan mode itself downgrade to Sonnet once the session grew past 200K tokens, exactly when you'd want the stronger model to stay.

Control: it's your setting; use plain opus if you don't want the split, or accept the swap and start execution with a compacted context so the re-read is small.

3. Fallback model chains: the reliability switch

When the primary model is overloaded, unavailable, or returns a non-retryable server error, Claude Code can retry the request on a fallback model instead of failing. You configure it explicitly:

claude --fallback-model claude-sonnet-5

// or persist a chain in settings.json (max 3 models)
{
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

Per the docs, the switch lasts for the current turn only: your next message tries the primary model again. Auth, billing, rate-limit, and transport errors never trigger it. This is the most benign of the five (it's scoped and announced), but each flip is still a model change with cache consequences on both hops.

Control: fully yours. Don't set a chain if you'd rather see the error. If you do, pick fallbacks whose behavior you trust with your codebase.

4. Fable 5 safety rerouting: the surprise on request one

Fable 5 runs safety classifiers for cybersecurity and biology content. When a request is flagged, Claude Code re-runs it on Opus and shows a transcript notice. The detail that catches people: the first request of a session carries workspace context (CLAUDE.md, git status), so per the docs, a repository that contains security or biology material can trip the classifier on that context alone, before you've typed anything unusual. Pentesting tools, CTF repos, and biology-adjacent codebases reroute constantly.

Control: run /config and turn off "switch models when a message is flagged". Flagged requests then pause and ask: switch to Opus, or edit the prompt and retry on Fable 5. In non-interactive mode, flagged requests end as refusals instead.

5. Silent substitutions: org policies and effort clamps

In managed environments there's a quieter class of switch: organization model restrictions replace a disallowed --model value at startup (with a notice naming both models), the availableModels allowlist redirects the Default option, and org effort limits clamp your /effort level per model, silently in JSON output and background agents. If your sessions behave differently at work than at home, check whether your org has these set before blaming the model.

What every one of these switches costs

All five mechanisms share a physics problem: prompt caches are model-scoped. Whoever initiates a switch, you or the tool, the new model re-processes your entire accumulated context at full input cost. For an automatic switch this stings twice:

• The usage-cap downgrade fires because you're low on quota, then immediately burns a full-context re-read of exactly the quota you're low on.
• A fallback-chain flip pays a rebuild on the fallback model, then another on the primary when the next turn switches back.

Taking control: pin sessions, route work

The docs themselves point at the robust pattern. From Anthropic's model configuration page:

"To run different models in different terminals at the same time, launch each one with its own --model flag rather than switching with /model."

That's the whole strategy in one sentence: dedicated sessions per model, each pinned at launch, each keeping its own context and warm cache. Chores live in a Haiku session so they never eat your Opus cap; hard problems live in an Opus session that isn't polluted with chores; and when a switch does happen (yours or automatic), the blast radius is one session, not your whole working state.

Model Shift is that sentence as hardware: every model pinned to its own gear, every gear a persistent tmux-backed tab launched with the right model from the start. The lever routes you between live sessions instead of mutating one session's model, so none of the five mechanisms above can silently rewrite the session you're working in.

Further reading: Why model switches break the prompt cache · The /model command, completely explained