‹ Guides

Guide · Switching models

Hand a session to a cheaper or different model without losing the thread

The model you want reasoning through a design is rarely the one you want writing four hundred lines of tests. Switching should cost you a short handoff, not an afternoon of re-explaining. Here is how to split the work and keep the thread.

Why switching models usually hurts

The new model knows only what you give it. People usually reach for one of two shortcuts, and both go wrong:

• Paste the whole transcript. It is long and expensive to send, and a smaller model drowns in it: the dead ends and the corrected mistakes look just as important as the decisions.
• Write a quick summary. It keeps what was done and drops why. The new model then "fixes" things that were deliberate, or retries an approach that already failed.

Split the work: reasoning on the strong model, volume on the cheaper one

The pattern that holds up is to let each model do what it is good at:

1. The strong model reasons. It works out the design, the rules, the edge cases and what "done" means, until nothing is left that needs judgement.
2. It writes the handoff. The finished reasoning, the plan and the definition of done, in a fixed shape.
3. The cheaper model does the volume. Bulk edits, many similar files, long repetitive writing, test scaffolding: work where the thinking is already done.
4. The strong model checks the result against the design before anything is merged. A failure goes back as a new handoff with the real error.

The rule that makes it work: never hand over work the cheaper model would have to figure out. If it still needs a decision, it isn't ready to hand off.

What the handoff has to carry

• The rules: the project's constraints and conventions, stated once.
• The decisions and the reasons for them, so deliberate choices survive.
• What is done, and how to check it.
• What failed, with the error, so it isn't retried.
• The next step and the definition of done, concrete enough to finish without asking.
• Where the detail lives: the branch, the files, the design note.

Leave out the transcript. If the handoff needs it, the reasoning wasn't finished.

Check that the handoff landed

Before the new model starts, ask it to restate three things in its own words: the next step, the constraints it must not break, and how it will know it's done. If any of the three is wrong, fix the handoff, not the model. It takes thirty seconds and it catches most bad handoffs before they cost you a review.

Doing it with ResumeState

• The strong model saves the handoff into the lane for that line of work, with tried, decided, done, failed, state and a pointer to the detail.
• You open the other model (any vendor, any size, including a free or local one), connected to the same account, and it resumes the lane. Nothing is pasted.
• The resume packet is short text with a few counts, so it fits a small model's context window.
• Each packet says whether it is current, so a model doesn't start from a stale picture.
• When the cheaper model finishes, it writes its own handoff, and the strong model reads it to check the work.

Questions

Related guides

• Why your AI forgets everything between sessions: Each new chat starts empty, and what to save so the next session starts where you stopped.
• An MCP server for session continuity: What an MCP memory or continuity server should do for coding agents, and how ResumeState connects.
• Claude Code session handoff: Carry Claude Code's work across /clear, compaction, new sessions, other machines and other models.