Let users choose the implementation model when accepting a plan

Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 8, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

I use a high-effort frontier model in plan mode, where auditing and judgment calls benefit from the strongest reasoning available. Once the plan is settled, implementation is often mechanical (all design decisions resolved), and a smaller, cheaper, faster model would be sufficient.

Today, accepting a plan continues with the model that produced it. There's no way to choose a different model at that point, so I either pay frontier-model cost and latency for mechanical work, or have to remember to switch models separately.

Proposed Solution

Add a model selector to the accept-plan step, so the user can choose which model carries out the implementation (defaulting to the current model, so existing behavior is unchanged).

Alternative Solutions

  • Manually switching models (e.g. via /model) before accepting the plan. This relies on remembering to do it at the right moment, and the plan-accept step gives no prompt to do so.
  • A fixed plan/execute model pairing (e.g. the opusplan alias) covers one specific combination but doesn't let me choose per plan, or pair a different planning model with a different implementation model.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

  1. I start plan mode with a frontier model at extra-high effort and ask it to plan a refactor, e.g. moving a function from one microservice to another.
  2. The planner reads the code, makes the judgment calls (which call sites need behavior changes vs. a mechanical swap), and produces a plan.
  3. At that point, remaining work is mostly mechanical edits following the plan.
  4. At "Accept plan," I'd like to select a smaller model for implementation, ideally in one step.
  5. I get the frontier model's judgment where it mattered, and cheaper, faster execution where it didn't.

Additional Context

Possible follow-on (happy to split into a separate issue): let the plan itself include a recommended implementation model with a one-line rationale, e.g. "Recommendation: Sonnet, since all design decisions are resolved and the remaining work is mechanical." The selector could pre-select it, always overridable.

Open questions: whether the switch would happen in the same session (and what that does to prompt caching and context) or in a fresh session seeded with the plan.

View original on GitHub ↗