| name | model-route |
| description | Advisor for selecting an optimal model tier (Opus/Sonnet/Haiku) for a specific task. Use before launching an agent team, before a multi-file refactor, or when deciding whether to drop from Opus to Haiku for transactional work (commits, formatting). Analyzes reasoning depth, blast radius, domain expertise, output length, correctness cost. NOT for switching models mid-task once work is underway - it advises the allocation before you start. |
Model Route Advisor
Recommend the optimal model for a given task based on a multi-model routing principle.
Analyzes task complexity, token budget, and parallelization opportunities to suggest the
best model allocation across the Opus / Sonnet / Haiku tiers (use tier aliases, not pinned
model ids - the alias resolves to whatever the current lineup maps that tier to).
Trigger: When user types /model-route or /model-route "<task description>"
Arguments
$ARGUMENTS - optional task description in quotes. If omitted, prompt the user
to describe what they want to do.
Policy Context
Check your project's CLAUDE.md for any model-selection policy. The routing
recommendation is advisory - it shows what the optimal allocation WOULD be under a
cost-optimized policy. The user decides whether to follow it or stick with their
preferred model.
Routing Matrix
Tier 1: Opus (highest capability, highest cost)
Route to Opus when the task involves:
- Architecture decisions or system design
- Complex debugging across multiple files
- Security review or adversarial analysis
- Planning and plan-reviewer verification
- Technical writing that must argue a position precisely
- Interpreting results or research claims
- Self-critic and validation passes
- Any task where a wrong answer is expensive to fix
Token estimate: 10K-50K per task (high reasoning depth)
Tier 2: Sonnet (strong capability, moderate cost)
Route to Sonnet when the task involves:
- Implementing a well-defined plan (code already designed)
- Writing boilerplate or mechanical code changes
- Routine refactoring with clear patterns
- Data migration or format conversion scripts
- Adding tests for existing code (test patterns clear)
- Subagent work with structured output requirements
Token estimate: 5K-20K per task (less reasoning, more generation)
Tier 3: Haiku (fast, lowest cost)
Route to Haiku when the task involves:
- Commit message generation
- File formatting and linting
- Simple lookups (find a function, check a value)
- Mechanical git operations (push, tag, branch)
- Generating structured data from templates
- Simple text transformations
Token estimate: 1K-5K per task (minimal reasoning needed)
Workflow
Step 1: Analyze the Task
Parse the task description and classify it along these dimensions:
| Dimension | Low | High |
|---|
| Reasoning depth | Mechanical, pattern-following | Novel, requires inference |
| Blast radius | Single file, reversible | Multi-file, hard to undo |
| Domain expertise | Generic programming | Specialized or domain-specific |
| Output length | Short (< 500 tokens) | Long (> 2K tokens) |
| Correctness cost | Easy to verify, cheap to retry | Hard to verify, expensive if wrong |
Route to the strongest tier a task's hardest dimension demands: when reasoning depth,
blast radius, or correctness cost is High, prefer Opus even if the other dimensions are Low.
Step 2: Generate Recommendation
Present the recommendation in this format:
=== MODEL ROUTE: <task summary> ===
Recommended: <TIER>
Reasoning:
- <dimension 1>: <assessment> -> <tier implication>
- <dimension 2>: <assessment> -> <tier implication>
- <dimension 3>: <assessment> -> <tier implication>
Token estimate: ~<N>K tokens
Cost estimate: ~$<X.XX> (only if current rates are known; this skill does no lookups - omit otherwise)
Project policy: see CLAUDE.md (this recommendation is advisory)
Step 3: Suggest Parallelization (if applicable)
If the task can be decomposed, suggest splitting:
Parallelization opportunity:
Instead of 1 Opus call (~40K tokens, ~$X.XX):
- 3 Sonnet subagents (~15K each, ~$X.XX total)
- Each handles: <subtask description>
- Savings: ~<N>% cost, ~<N>x faster (parallel execution)
Only suggest parallelization when subtasks are genuinely independent and don't
need shared state or sequential reasoning.
Step 4: Note Alternatives
If the task sits at a boundary between tiers:
Alternative approaches:
a) <Tier A>: <tradeoff> (e.g., "Opus for safety, +$0.50")
b) <Tier B>: <tradeoff> (e.g., "Haiku for speed, risk of shallow analysis")
c) <Split>: <tradeoff> (e.g., "Opus for planning + Sonnet for implementation")
Project-Specific Routing Rules
Override the general matrix based on your project's needs. Examples:
| Task | Suggested Tier | Reason |
|---|
| Architecture decisions | Opus | Wrong decisions are expensive to fix |
| Technical / scientific writing | Opus | Deep reasoning required |
| Commit + push | Haiku | Mechanical git operations |
| Validation / self-critic passes | Opus | Adversarial reasoning required |
| Session-bootstrap briefing | Haiku | Mechanical: run git commands, format output |
| Boilerplate generation | Sonnet | Pattern-following, no deep reasoning |
Context Management
This skill is pure analysis - no file reads, no subagents, no bash commands.
It analyzes the task description and produces a recommendation. Total output: ~20 lines.