[FEATURE] Flexible plan/execute model pairing — `/model sonnetplan [haiku]` syntax

Resolved 💬 4 comments Opened Feb 28, 2026 by meesp123 Closed Mar 4, 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

When using /model opusplan, the execution model (after plan approval) is hardcoded to sonnet. I cannot choose a faster/cheaper model for execution even when the task doesn't require it.
Current workflow forces me to use the same execution model regardless of task complexity, simple file edits use the same model as complex reasoning tasks, wasting latency and rate limit headroom.

Proposed Solution

Extend the /model command to accept an optional execution model:
/model opusplan [claude-opus-4-5] # opus 4.6 plans, opus 4.5 executes
/model opusplan [claude-haiku-4-5] # opus plans, haiku executes
/model sonnetplan [claude-haiku-4-5] # sonnet plans, haiku executes
/model opusplan [claude-sonnet-4-6] # current default, now explicit

General syntax: /model {X}plan [{execution-model-id}]
The planning phase (EnterPlanMode → ExitPlanMode) uses the primary model. After plan approval, execution switches to the specified model.

Alternative Solutions

Currently using /model opusplan (sonnet execution, hardcoded).
Workaround: manually switch model mid-session after plan approval but this is clunky and loses the opusplan pairing context.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

  1. I run /model sonnetplan [claude-haiku-4-5].
  2. Claude Code uses sonnet to analyze codebase, write plan, call ExitPlanMode.
  3. I approve the plan.
  4. Execution phase (file edits, boilerplate, grep) runs on haiku 3x faster.
  5. Result: deep planning quality + fast execution, no wasted compute on simple edits.

Additional Context

<img width="486" height="88" alt="Image" src="https://github.com/user-attachments/assets/b588a294-c5c8-42e8-833b-e2b1c3639a0f" />

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗