[Feature]: Switch provider/model mid-conversation via transcript handoff

[Brechard]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

A thread is pinned to the provider/model it started on. Once a conversation begins on Codex you cannot continue it on Claude (or vice-versa) — the picker locks and the server rejects the switch.

Proposed solution

Allow switching provider/model mid-conversation without trying to resume the previous provider's session.

In #2365 the decision was to not enable cross-provider continuation because the old provider's session could not be resumed (API response mismatches when switching back to Anthropic). This approach avoids that entirely: on a switch it starts a fresh session on the target provider and replays a rendered transcript as the first turn's prelude — prior user/assistant messages plus a structured tool/command trail (commands, file edits, MCP/skill calls, exit codes, and output). So there is no cross-provider session continuation to break; the new provider just receives context as text. An inline "Switched from X to Y" notice marks the boundary in the timeline.

(Related to #1911, but transcript-replay into a fresh session instead of session compaction/continuation.)

Why this matters

Different models are better at different steps (e.g. plan on one, implement on another). Today that requires starting a new thread and losing the working context.

Smallest useful scope

Same-driver model changes already work; the missing piece is cross-driver handoff. The minimal version is: on a cross-provider switch, start a fresh target session and prepend the prior conversation (messages only) as text. The tool/command trail is an enhancement on top.

Alternatives considered

Resuming the old provider's session across providers — which is exactly what #2365 found doesn't work. Transcript replay sidesteps it.

Risks or tradeoffs

This is a large change (~1.1k lines) and overlaps the in-flight orchestrator-v2 work, so it may not be wanted as-is. Opening as an issue first per CONTRIBUTING to gauge interest before any review — happy to close or split. The new provider sees a rendered transcript, not native tool-call state, so cross-switch turn rollback/checkpointing doesn't span the boundary. Adds no DB migrations.

[DRSHBG]

+1 — biggest friction in the plan-big / implement-cheap flow: plan on a strong model (Opus / GPT-5.6 Sol), then hand the same thread to a cheaper one (Composer / Haiku) to implement. Right now it's locked to the starting provider, so I lose context to a new chat. The transcript-handoff proposed here would nail it — even a one-way "fork thread to " covers most of it.

[nathnael-desta]

+1 — I’d also like a summary-based handoff that works even when the original provider is unavailable or has reached its limit.

For example, OpenCode or Codex could use the Claude thread context stored locally by T3 Code to generate a concise handoff containing the objective, decisions, completed work, and next steps. The user could review it, then open a new session with any configured provider/model in the same worktree.

This would support provider outages, usage limits, context compaction, and switching to a model better suited to the next task—without requiring the original provider to be available.

[mmeister86]

+1 - this is the thing that keeps me from using t3code over e.g. opencode, when using models from multiple providers. the switch between providers in opencode is so seamless, i hope it'll get integrated here also.

[kyletjohnson]

Concrete real-world case from T3 Code 0.0.33: I reached my quota in a long-running Claude Fable project thread, and alternate providers/models were disabled in that conversation. “New thread on main” preserved the workspace but not the conversation, while “Copy branch” only copied the Git branch. Asking the original model to create a handoff was impossible because that provider could no longer run.

A key acceptance criterion should be that the handoff is generated from T3’s stored canonical transcript/checkpoints; not by calling the provider being left. The minimum useful flow would be: Continue/Fork with… → select any configured provider/model → create the target session using stored conversation and workspace context → visibly link it to the original thread while leaving the original untouched.

An editable handoff preview and “Copy transcript as Markdown” fallback would make failures recoverable. This appears aligned with #1404 and PR #2829’s portable-context direction. Please explicitly test the “source provider unavailable or out of quota” path.

[christhomas]

+1. Concrete case from 0.0.41-nightly.20260915.1752 (self-hosted t3 serve): I start threads on Codex and later want Claude on the same work. The picker locks to the thread's provider, so the only way out is a new thread, which loses the conversation.

A simple way to get most of the value: a "Summarise into new thread" button. Choose the target provider/model, and T3 writes a handoff summary of the thread (goal, decisions, work done, open questions, next steps) and starts a fresh thread on that provider with the summary as its opening context. Even if the full conversation state lives inside the original provider's session and can't move across, this carries the useful part over while changing model. It also works one-way, so none of the resume-compatibility problems described in #7367 apply.

It would help most when the original provider can't run anymore (quota exhausted, outage), so ideally the summary is built from T3's own stored transcript rather than by asking the provider you're leaving. #11096 looks close to this shape if it gets review.

[zachback64]

I have this working in a local build, so here is what it looks like (demo project and data only).

How it works: picking a model from another provider on a started thread stops the old session and starts a fresh one on the new provider, with no resume cursor. The first turn after the switch gets a transcript handoff built only from T3's stored thread: user and assistant messages, a short trail of completed tool calls, and the latest open plan, sized to the target model's context window. It never calls the provider you are leaving, so it also works when that provider is out of quota or down. A divider in the timeline marks the switch. Same-provider model changes keep native resume.

Claude Sonnet to Codex in one thread, with the second turn relying on context from the first:

Picker on a started thread	After the switch

Full-resolution video

This was #14197, which was closed for missing captures and was also too large. If you want it, I can split it into small PRs: (1) server handoff when a turn starts on a different provider, (2) unlock the picker, (3) the timeline divider. If Orchestration V2 (#2829) is going to cover this, I'm happy to wait instead.

Related: #3797, #7367.

[juliusmarminge]

Thanks for proposing transcript handoff as the way to support provider switching. The orchestrator V2 work has now merged in #2829.

V2 now lets you change provider or model in an existing thread. When native continuation is not possible, T3 starts the target provider with a budgeted selection of the conversation as portable context. This preserves useful context without trying to resume one provider with another provider's native session.

Closing this as delivered. If a specific part is still missing in a build containing V2, please open a focused follow-up with the provider/version and the behavior you are seeing.