[FEATURE] User-Configurable Model Routing for Skills and Tools

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 opusplan mode (which switches between Opus for planning and Sonnet for execution), the model switching only detects Claude Code's built-in EnterPlanMode tool. It does not detect planning activities from marketplace skills.

Example scenario:

1. User starts session with claude -m opusplan
2. User invokes /brainstorm (a planning-oriented skill from superpowers plugin)
3. Expected: Opus is used (deep reasoning for design work)
4. Actual: Sonnet is used (because EnterPlanMode wasn't called)

The skill author reasonably wants to remain model-agnostic - they shouldn't force users into a specific model. But this means users who want Opus for planning skills must manually start separate sessions with claude -m opus.

Proposed Solution

Add a modelRouting configuration option in settings that allows users to specify model preferences:

{
  "modelRouting": {
    "skills": {
      "superpowers:brainstorm": "opus",
      "superpowers:write-plan": "opus",
      "superpowers:systematic-debugging": "opus"
    },
    "tools": {
      "EnterPlanMode": "opus"
    }
  }
}

Behavior

• When a skill listed in modelRouting.skills is invoked, Claude Code temporarily switches to the specified model for that skill's execution
• When a tool listed in modelRouting.tools is called, the same model switching applies
• After the skill/tool completes, the model reverts to the session default
• This configuration is user-level (in .claude/settings.json or settings.local.json)

Scope Options

The feature could support different scopes:

{
  "modelRouting": {
    "skills": {
      "superpowers:brainstorm": "opus",           // Specific skill
      "superpowers:*": "opus",                    // All skills from a plugin
      "*:brainstorm": "opus"                      // Any skill named "brainstorm"
    }
  }
}

Use Cases

1. Planning with marketplace skills: Users want Opus-level reasoning when using brainstorming/planning skills, but Sonnet for implementation
2. Cost optimization: Users can configure expensive models only for specific high-value activities
3. Model experimentation: Users can test different models for different workflows without modifying skills
4. Team standardization: Teams can share model routing configurations for consistent behavior

Current Workarounds (and their limitations)

| Workaround | Limitation |
|--------------------------------------------------------------|------------|
| Use claude -m opus or /model opus for planning sessions | Requires manual session switching, loses conversation context |
| Ask skill authors to add model hints | Authors reasonably want to remain model-agnostic |
| Create local wrapper skills | Duplicates skill logic, maintenance burden |
| Modify marketplace skills locally | Breaks on updates, not portable |

Alternative Solutions

1. Skill-level preferred_model hint

Skills could declare a preferred model in frontmatter:

---
preferred_model: opus
---

Rejected because: This forces skill authors to make model decisions, which many prefer to leave to users.

2. Hook-based model switching

Allow hooks to modify the model for subsequent API calls.
Rejected because: Hooks modify content, not infrastructure. Model selection happens at session/API level.
(Or I miss how to mutate the model selection at the hook level)

3. Extend opusplan to detect semantic planning

Make opusplan smarter about detecting planning activities.
Rejected because: Heuristics would be fragile. Explicit user configuration is more reliable.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

I begin to work on a new feature.
The brainstorming skill is triggered (at this point I want to use the model indicated in my config opus)
After the brainstorming a plan is written (this using the opus model)
After plan is written the implementation begin I want to switch back to sonnet (so this model could be the default one used in my session or something else)

Additional Context

Implementation Notes

• Model routing should be evaluated at skill/tool invocation time
• The model switch should be scoped to the skill execution (including any subagents it spawns)
• Consider whether this applies to the main conversation or only to Task subagents
• Settings should be mergeable (project-level + user-level)

Related

• opusplan mode documentation
• Task tool's model parameter (already supports per-agent model selection)
• Skill frontmatter preferred_model hint (mentioned in some docs but may not be implemented)