[FEATURE] Automatic Model Switching for Plan Mode

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I like this!

Just in case someone else stumbles here, I think this has been added: https://code.claude.com/docs/en/model-config#opusplan-model-setting

opusplan is currently totally broken. It selects Opus 4.1 for planning while Opus 4.6 is available and Sonnet 4.5 for execution, while Sonnet 4.5 is available

this would be very useful!

Multi tier routing has been part of attune-ai for Claude-code for quite
some time.

On Thu, Mar 5, 2026 at 9:32 PM Douglas Silverio @.***>
wrote:

dsilverio-gcmlp left a comment (anthropics/claude-code#15721) <https://github.com/anthropics/claude-code/issues/15721#issuecomment-4009143775> this would be very useful! — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/15721#issuecomment-4009143775>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVMXZYM7AWWPMLSZURVOANL4PI2EHAVCNFSM6AAAAACQIIEKD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMBZGE2DGNZXGU> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

@sholub89

I use the following setup (atlhough I use it for AWS Bedrock, never tried it with Antrophic's cloud)

ANTHROPIC_DEFAULT_OPUS_MODEL='global.anthropic.claude-opus-4-6-v1'
ANTHROPIC_DEFAULT_SONNET_MODEL='global.anthropic.claude-sonnet-4-5-20250929-v1:0' 
ANTHROPIC_DEFAULT_HAIKU_MODEL='global.anthropic.claude-haiku-4-5-20251001-v1:0' 
ANTHROPIC_MODEL='opusplan' 

This uses the correct models. Maybe something similar could work for you as well.

@adam-kiss-sg , thank you. I noticed that the subscription version works perfectly fine, and it selects the right models, while the API version is bugged

Adding weight here — this remains one of the highest-friction points in a cost-conscious Claude Code workflow.

Current state (March 2026): The opusplan shorthand exists (documented at code.claude.com/docs/en/model-config#opusplan-model-setting) but as @sholub89 noted, it resolves to hardcoded model versions rather than latest Opus/Sonnet. On the API path this means you may get Opus 4.1 + Sonnet 4.5 when Opus 4.6 and Sonnet 4.6 are available. The workaround (@adam-kiss-sg's env var approach) works for Bedrock but is clunky for direct API users.

What's still missing:

1. A planModel / executeModel config pair that resolves model aliases dynamically (not hardcoded versions)
2. Visual indicator in the TUI showing which model is currently active (plan vs. execute phase)
3. Auto-switch on plan mode entry/exit without any user action

The core ask is simple: make the model follow the mode, not the user's memory. Planning benefits from maximum reasoning capacity; execution of already-decided steps is a throughput problem where Sonnet/Haiku excel.

This pattern is now widely documented as best practice in the community — native support would validate and normalize it.

I agree this would be super helpful, and probably something that would save anthropic cost on there subscription plans, as most people would probably leave it to auto switch. Sonnet with a really well defined plan can smash it out no problem, so this is for sure something we need.

Is there any third party plugins for CC that can do this?

Would be very helpful indeed!

Any update on this? I am on an enterprise subscription and opusplan mode is not switching the models correctly. I go to plan mode and it still says sonnet is being used.

I don't think so but they do take pull requests but looking at the things they shoul are fixing seems to be focusing on Enterprise users right now

Could this solve your issue? https://github.com/oussama-kh/mcp-llama-swap
Currently works for local llm models only, but maybe you can fork and adapt it to your case.

The (in my opinion) cleanest and most obvious implementation of this would be to offer the sonnet switch when the user is asked if the Edits should be implemented, so like this:

Claude has written up a plan and is ready to execute. Would you like to
 proceed?

 ❯ 1. Yes, switch to Sonnet and auto-accept edits
   2. Yes, stay with Opus and auto-accept edits
   3. Yes, manually approve edits
   4. No, refine with Ultraplan on Claude Code on the web
   5. Tell Claude what to change
      shift+tab to approve with this feedback

The plan/execute split is leakier than it looks. Real "execution" isn't a flat pipe of mechanical edits — it's punctuated by mini-planning moments: a test fails and the model needs to reason about why, an interface decision forces a tradeoff the plan didn't anticipate, a refactor surfaces a question that wasn't visible upfront. If the switch flips to Sonnet on ExitPlanMode and stays there, those moments silently get the cheaper brain — and the user sees worse output without knowing the model changed under them.
Worth defining re-escalation signals beyond plan-mode boundaries: repeated tool-call failures, the model itself flagging uncertainty, cross-file reasoning, or N+ edits converging on the same region.

+1 on this. One thing worth keeping in mind for the implementation: the existing opusplan preset is effectively hardcoded to a specific Opus↔Sonnet pair. As new models are released, that approach doesn't scale — every new model would need its own bespoke "X-plan" alias.

It would be great if the eventual implementation generalized opusplan into a configurable pair (e.g. plan_model / exec_model as proposed in Option A), so users could set any model for either role:

{
  "models": {
    "plan_mode": "<any-model-id>",
    "execution_mode": "<any-model-id>"
  },
  "auto_switch_models": true
}

This way, as future models are added to Claude Code, users get an "X-plan" style preset for free without waiting for a new hardcoded alias. Today there's no hook event for EnterPlanMode/ExitPlanMode and no way to switch models automatically based on plan-mode state, so this currently has to be done manually via /model.

I agree, especially with the new Fable models released, it people might want to use that for planning instead of opus.

+1, and I'd add a data center angle to this: I'm a daily subscriber using chat, Code, and Cowork. I manually switch between Haiku/Sonnet/Opus depending on the task, but I forget, and end up running simple stuff on a bigger model than it needs. Multiply that by however many subscribers do the same thing — auto-routing wouldn't just save users' usage allowance, it'd cut unnecessary load on Anthropic's compute too. Seems like a win on both sides of the table.

I'm not sure why this issue is still open because this already works on my local machine, just type /model opusplan

❯ /model                                                                                                                                                                                                                                                                                                            

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Select model
  Switch between Claude models. Your pick becomes the default for new sessions. For other/previous model names, specify with --model.
                                             
    1. Default (recommended)  Sonnet 4.6 · Efficient for routine tasks
    2. Sonnet                 Sonnet 4.6 · Efficient for routine tasks
    3. Sonnet (1M context)    Sonnet 4.6 with 1M context · Draws from usage credits · $3/$15 per Mtok
    4. Opus                   Opus 4.8 · Best for everyday, complex tasks · ~2× usage vs Sonnet
    5. Haiku                  Haiku 4.5 · Fastest for quick answers
  ❯ 6. Opus Plan Mode ✔       Use Opus in plan mode, Sonnet otherwise

+1 — this is even more important now that Fable is out, since Fable is quite expensive to run for an entire session. Being able to use it just for planning (falling back to a cheaper model for execution) is exactly the use case this issue is asking for.

Worth noting: Codex CLI already supports this pattern natively (distinct planning vs. execution model config), so there's precedent for it working well in practice.

Related: #8358, #26556

@dannytrue this issue should stay open — opusplan and this request solve different problems. opusplan is a hardcoded Opus↔Sonnet pair; it doesn't let you choose which models are used for planning vs. execution. This request is about a generic plan_model/exec_model setting that works with any model pair — e.g. I want Fable 5 for planning and Sonnet 5 for implementation, which opusplan can't do no matter how it's configured.

This must also support the ability to specify an effort level per model for planning versus execution. :-)

Yes please I would like to see

• Plan mode Model and Effort e.g. Opus Max
• Execution mode Model and Effort e.g. Sonnet High

Just in case someone else stumbles here, I think this has been added: https://code.claude.com/docs/en/model-config#opusplan-model-setting

this is not really it, it's similar but new model came out Fable 5 and this doesn't work any more during regular sessions, only if Fable 5 reaches limit.

+1 for this to become a real feature

Actually we could go all the way and specify

• Planning Model and Effort
• Coding Model and Effort
• Prose-only non-coding Model and Effort
• Subagent Model and Effort
• Test-runner Model and Effort (no need to use Fable to run & evaluate unit-test results)

+1, we definitely need this!