The Do's and Don'ts of Switching Models Mid-Task

The whole series has pushed one idea: route each task to the right model. But “routing” quietly assumes something the pricing pages never mention — that you’ll switch models, often in the middle of a job. Hit a wall on a workhorse, jump to a flagship. Finish the hard part, drop back down. Simple, in theory.

In practice, people try it and get surprised. They switch to a stronger model mid-conversation and the answer is somehow worse, or the bill jumps, or the new model picks up a subtly different style and the code stops matching. The switch didn’t behave like flipping a light. Because a mid-task switch is not free — it has costs most builders never see until they’ve paid them.

This is the practical companion to everything before it: routing is the goal, but switching is the mechanic, and doing it badly undoes the savings you were chasing.

The evergreen idea: a switch is a handoff, and handoffs have a cost

When you change models mid-task, three things happen that nobody warns you about:

• The cache resets. Prompt caches are per-model. The moment you switch, the discount you’d built up on your context evaporates — the new model has to read all of it fresh, at full price. Switch back and forth carelessly and you pay the “cache write” cost over and over, wiping out the saving that made routing worthwhile.
• The reasoning state is lost. A model’s chain of thought doesn’t transfer. If you switch in the middle of the model working something out, the new model doesn’t inherit that thinking — it re-derives from the visible text, often from a worse starting point than the one you interrupted.
• Behaviour drifts. A different model reads the same context differently: different defaults, different style, different tool-call quirks. Switch mid-flow and your code can subtly change character, or the new model can misread conventions the previous one had settled into.

None of this means don’t switch — switching is the whole point. It means a switch is a handoff, and the skill is doing the handoff cleanly: at a natural boundary, with a tidy package, so the new model starts fresh instead of confused and expensive.

What’s known and reported (as of 19 July 2026)

Switching is easier than ever to trigger and no cheaper to do carelessly. The mechanics below are well-reported; confirm the specifics against current docs before you rely on them.

As of 2026-07-19:

• The tooling makes switching frictionless. Claude Code’s /model command, Cursor and Continue’s model pickers, OpenRouter’s per-request model field, and Codex’s model settings all let you swap models in a click or a keystroke — mid-conversation. Easy to trigger is not the same as free to do.
• Caches are per-model. Anthropic and OpenAI both cache against a specific model; a switch means the new model starts from a cold cache, and (on OpenAI) the first call also pays the ~1.25× cache-write. Frequent flip-flopping is a quiet way to increase a bill.
• Tool-call and format behaviour differ. Models vary in how they structure tool calls, follow output formats, and interpret terse instructions. A prompt tuned for one can behave differently on another — usually fine, occasionally not, so watch the first output after a switch.
• Reasoning traces don’t transfer. Extended-thinking / reasoning state is internal to a model and a session; switching discards it. Switch between reasoning steps, never inside one.

Treat all of this as directional and re-check it — the harnesses and cache rules change fast.

The practical middle: switch cleanly, not constantly

The two failure modes are opposite. Some builders never switch — one model for everything, the most expensive habit. Others switch constantly, chasing the cheapest model for every turn, and drown the savings in cache resets and drift. The practical path runs between them: switch at boundaries, hand off with an artifact.

A boundary is a natural seam in the work — plan done, now build; build done, now review; stuck, now escalate. These are exactly the points where the previous model’s job is finished, so there’s no reasoning state to lose and the context can be repackaged cleanly.

An artifact is what you carry across the seam: the plan, a short summary of what’s done and what’s next, the diff to review. You hand the new model that tidy package — not the entire bloated conversation. This is the same “pay once, reuse” logic from caching and planning: a clean handoff artifact is cheaper to read, easier to act on, and doesn’t drag the previous model’s confusion into the next one.

And because different models drift, you re-anchor on the switch: point the new model at your repo’s instruction files so it inherits the same conventions the last one used. A stable, checked-in instruction layer is what makes a switch behave like a shift-change rather than a personality transplant.

Where the challengers make this sharper

Switching to or from a challenger mid-task is where the quirks bite hardest — tool-call formats and instruction-following differ more across vendors than within one. The practical rule is to keep challengers in clean-boundary lanes: hand a GLM or DeepSeek model a self-contained, artifact-driven task (a batch job, a well-specified build step) rather than swapping it into the middle of a live, stateful conversation. Used at boundaries with a clear handoff, they’re cheap muscle; dropped mid-flow into a context tuned for a different model, they’re a source of surprises.

The do’s and don’ts

Do: - Switch at phase boundaries — plan → build → review — where there’s no reasoning state to lose. - Hand off via an artifact — a plan, a summary, a diff — not the whole conversation. - Re-anchor with your repo’s instruction files so conventions survive the switch. - Escalate at a wall, drop when it goes mechanical — the two moments a switch actually pays. - Batch the new model’s work so its cold cache warms up and starts saving.

Don’t: - Don’t switch mid-thought. Interrupting a reasoning chain throws away the thinking you were paying for. - Don’t drag the whole bloated context across. The new model re-reads it all, expensively, and inherits the mess. - Don’t switch so often the cache never warms. Thrashing between models is a cost, not a saving. - Don’t assume tool/format quirks transfer. Check the first output after any switch. - Don’t switch for pennies when the cache reset and handoff cost more than you’ll save.

Where this is heading

Switching cleanly, by hand — spotting the boundary, writing the handoff, re-anchoring the new model — is judgement you apply dozens of times a build. It’s exactly what the Token Economy harness is designed to do for you: switch models only at natural seams, carry a compact handoff artifact across, and re-anchor on your repo’s policy every time, so the switch is cheap and the behaviour is steady. The Build-Estimator, in turn, prices a build assuming disciplined switching — because the “flip-flop and reset the cache” path is one of the sneakiest ways a budget leaks.

Until then, the rule is simple and free: switch at boundaries, hand off with an artifact, re-anchor on your repo. Confirm the current cache and tooling behaviour against the docs before you build around it — in this market, even the mechanics of switching get repriced.

Sources (July 2026): - Per-model prompt caching (resets on switch) — platform.claude.com/docs, OpenAI Help Center - Mid-conversation model switching in tools — Claude Code /model, OpenRouter model routing - Challenger tool-call/format variation — docs.z.ai, api-docs.deepseek.com

Caching behaviour, tool switching, and model quirks change frequently. Confirm against the vendor and tool docs before relying on any specific behaviour here.