workflow · 7 min read · 2026-07-10

A cache-safe multi-model workflow for Claude Code & Codex

The right model for renaming a variable is not the right model for debugging a race condition. Everyone knows this; that's why /model exists. But switching models mid-session rebuilds your entire prompt cache, a cost that grows with your context and repeats every time you flip back. Here's how to actually run a multi-model workflow without paying that tax.

First, decide what each model is for

A division of labor that holds up in practice:

The trap is treating the model picker like a settings toggle inside one conversation. Prompt caches are model-scoped, so every flip re-processes your accumulated context at full price on the new model: roughly context size × input price × 1.25, per switch. The fix is to make the session the unit of switching. Three patterns, from lightest to most powerful:

Pattern 1: switch only at boundaries

If you're going to use /model, use it when the rebuild is cheapest:

• Right after /clear: new task, empty context, nothing to rebuild.
• Right after /compact: history is summarized down to a fraction of its size, so the one-time rebuild is small.
• Never "just for one question" deep in a session. That's the worst case: full rebuild now, another full rebuild when you switch back.

This works, but it couples "which model" to "when I'm willing to reset context". You lose the ability to upshift because the current task got hard, which is exactly when you want it.

Pattern 2: keep the session, delegate the task

Anthropic's guidance for agent builders: keep the main loop pinned to one model and spawn subagents on other models for sub-tasks. The subagent starts with a small fresh context (cheap to process on any model), does the work, and returns a summary into your main thread, whose cache never moves. In Claude Code, point the Task tool at a different model for the child agent; on the API, it's just a second request with its own small prompt.

Great for: bulk mechanical edits (fan out to Haiku), parallel research, code review passes. Weaker for: interactive back-and-forth where you want to talk to the other model directly, with full project context, for a while.

Pattern 3: one live session per model

The pattern that scales: run a persistent session per model, side by side. Opus in one, Sonnet in another, Haiku in a third, Codex in a fourth. Each session accumulates its own history and keeps its own cache warm (every turn refreshes the 5-minute TTL). Switching models becomes switching terminals: instantaneous, and nothing is invalidated because nothing changed inside any session.

Compare the failure modes:

The per-model context is a feature, not a bug: your Opus thread stays a deep architecture conversation while the Haiku thread churns through chores. Neither pollutes the other's context window, and both stay cheap. And because sessions run in parallel, you can have Opus reasoning about a design while Haiku fixes lint in the same repo.

The DIY version is tmux: one window per model, each running claude (with /model set once at launch) or codex. It works. The annoyance is bookkeeping. Which window was Sonnet? Did the Haiku one die? That's the part worth automating.

What Model Shift automates

Model Shift is a macOS stick-shift for exactly this pattern. You map models to gears: 1st: Haiku, 3rd: Opus, 5th: GPT, your layout. Throwing the lever doesn't run /model inside your session; it drops you into that gear's own persistent tmux-backed tab, with its model already running, its context intact, and its cache warm. Every gear is a cache-safe tab:

• Shift down to Haiku for a chore, shift back up. Opus's session never noticed you left.
• No rebuild cost, no slow first turn, no "wait, which tab was which model".
• Works with Claude Code and Codex side by side, so cross-model second opinions are one gear-throw away.

Further reading: Why switching models mid-session breaks your prompt cache · Anthropic prompt caching, explained