9.3 When to switch models mid-project
Overview and links for this section of the guide.
On this page
Why switching models is normal
Projects change phases. The model you want for “generate a scaffold” is not the model you want for “analyze a subtle regression” or “process 10,000 documents cheaply.”
Switching models mid-project is healthy when it’s deliberate.
If you switch because you need different tradeoffs, that’s engineering. If you switch randomly hoping it “just works,” that’s superstition.
Signals it’s time to switch
Switch to a smarter model when:
- you need a plan with real tradeoffs,
- you’re debugging something ambiguous and keep looping,
- the change spans many files/modules and coherence matters.
Switch to a faster/cheaper model when:
- you’re doing mechanical edits (rename, boilerplate, repetitive code),
- you’re running many iterations and cost matters,
- you already have a clear plan and just need implementation steps.
How to switch without losing coherence
When you switch, you need to re-anchor context. A simple “handoff packet” prevents drift:
- Goal: what you are doing now (one sentence).
- Constraints: runtime, deps, file scope, style, safety rules.
- Current state: file tree + key files (only what matters).
- Acceptance criteria: tests or examples that define “done.”
- What failed so far: errors, failed attempts, rejected approaches.
Think of this as “context reboot.” It keeps the new model from inheriting vague conversation history.
Start the new model with: “Summarize the agreed constraints and acceptance criteria; list assumptions; propose a plan; stop.” That forces alignment before code.
The “lanes” workflow (design vs typing vs scale)
A clean operational approach:
- Design lane (smart): architecture, plans, risk analysis, test strategy.
- Typing lane (fast): implement small diffs, write boilerplate, do mechanical refactors.
- Scale lane (cheap): batch tasks with strict schemas and validation.
Your job is to keep lane boundaries crisp so you don’t accidentally ask a “typing lane” model to do “design lane” work and get low-quality plans.
Common mistakes (and fixes)
Mistake: switching randomly after a bad output
Fix: first improve evidence and constraints. Many “model problems” are actually “prompt problems.”
Mistake: switching without a handoff packet
Fix: re-anchor with goal + constraints + acceptance criteria + minimal code slice.
Mistake: using the smart model for every diff
Fix: use smart for planning, then fast for implementation. Keep your loop fast and cost predictable.