Feature Request: Programmatic Model Switching

Resolved 💬 2 comments Opened Jan 31, 2026 by MyAiHelp Closed Mar 1, 2026

Feature Request: Programmatic Model Switching

Summary

Add the ability for Claude to programmatically switch models during a session based on task complexity assessment.

Problem

Currently, model selection requires manual intervention via /model command. This leads to:

  1. Inefficient resource usage - Simple tasks (file reads, typos) often run on Opus when Haiku would suffice
  2. Unnecessary costs - Users pay premium rates for tasks that don't require premium models
  3. Workflow friction - Users must remember to switch models manually before each task type
  4. Cognitive overhead - Users need to assess complexity themselves instead of letting AI optimize

Proposed Solution

Add one of the following mechanisms:

Option A: Tool-based switching

// AI can call this tool
{
  "name": "set_model",
  "description": "Switch to a different Claude model",
  "input_schema": {
    "type": "object",
    "properties": {
      "model": {
        "type": "string",
        "enum": ["haiku", "sonnet", "opus"],
        "description": "Model to switch to"
      },
      "reason": {
        "type": "string",
        "description": "Explanation for model switch"
      }
    }
  }
}

Option B: MCP Server action

Add claude-code:setModel action to an MCP server that can control Claude Code settings.

Option C: Auto-assessment mode

Add a setting that enables automatic model selection:

{
  "autoModelSelection": {
    "enabled": true,
    "confirmBeforeSwitch": true  // Optional user confirmation
  }
}

Use Cases

Cost Optimization

User: "What's in README.md?"
AI: [Assesses: Simple file read]
AI: [Switches to Haiku automatically]
AI: [Returns content]
Result: ~10x cost savings vs running on Opus

Quality Optimization

User: "Write the next chapter with V9 voice"
AI: [Assesses: Heavy creative work requiring nuance]
AI: [Switches to Opus if currently on Haiku]
AI: [Produces quality output]
Result: Better quality without user needing to remember to switch

Workflow Efficiency

User: "Fix this typo, then review the chapter for voice"
AI: [Switches to Haiku for typo fix]
AI: [Switches to Opus for voice review]
Result: Optimal model for each sub-task

User Control

Recommended safeguards:

  1. Confirmation mode - Ask before switching (initially)
  2. Notification - Always notify user when switch occurs
  3. Override flag - --no-auto-switch to disable per-command
  4. Settings control - User can disable feature entirely

Benefits

| Benefit | Impact |
|---------|--------|
| Cost savings | 50-90% reduction for users with mixed workloads |
| Better quality | Right model for each task |
| User experience | Less manual switching, more flow |
| Accessibility | New users don't need to understand model differences |

Example Workflow

User: "Read config.json then write a new feature based on it"

Current workflow:
1. User types "/model haiku" (manual)
2. "Read config.json"
3. User types "/model opus" (manual)
4. "Write feature"

Proposed workflow:
1. "Read config.json then write a new feature based on it"
2. AI: "Reading config with Haiku, then switching to Sonnet for feature implementation"
3. [Both tasks complete with optimal models]

Implementation Complexity

Low to Medium:

  • Model switching already exists (/model command)
  • This just exposes it programmatically
  • Assessment logic can live in system prompt

Alternative Workarounds

Currently users can:

  • Add manual assessment protocol to system prompts (AI warns but can't switch)
  • Use keybindings (still manual)
  • Remember to switch themselves

None of these achieve true automation.

Related

This aligns with Claude's mission of being helpful and reducing user friction. Similar to how Claude can decide when to use tools, it should be able to decide which version of itself is most appropriate.

---

Would you use this feature? Please react with 👍 if this would improve your workflow.

View original on GitHub ↗

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