Pick Model

Classify user's task → recommend optimal model with reasoning.

Instructions

1. Parse task description from $ARGUMENTS
2. Classify against decision matrix below
3. Output recommendation using format template

Decision Matrix

Technical Tasks

Business & Strategy Tasks

Creative & Analysis Tasks

Commands, Skills, Agents

Complexity Escalators

Upgrade one tier if task has ANY of these signals:

Technical Escalators

• Ambiguity: Underspecified requirements, multiple valid interpretations → +1 tier
• Scope: Affects 3+ files/systems/components → +1 tier
• Stakes: Production system, security, data-loss risk, regulatory compliance → +1 tier
• Novelty: No established pattern, novel algorithm, cutting-edge tech → +1 tier

Business Escalators

• Multiple stakeholders: Competing interests, need to balance trade-offs → +1 tier
• Strategic impact: Long-term consequences, irreversible decisions, organizational change → +1 tier
• Political sensitivity: Layoffs, restructuring, executive communications, crisis → +1 tier
• Cross-functional: Requires synthesis across domains (tech + business + legal) → +1 tier

Cognitive Escalators

• Pattern detection: Requires analyzing trends across multiple data points/sessions → +1 tier
• Bias identification: Needs to spot blindspots, cognitive biases, assumptions → +1 tier
• Ethical reasoning: Moral ambiguity, fairness considerations, unintended consequences → +1 tier
• Multi-framework: Applying 2+ analytical frameworks simultaneously → +1 tier

Cap at Opus. If multiple escalators apply, still cap at Opus (don't "double upgrade").

Decision Guidance

When uncertain between two models:

• Haiku vs Sonnet: Does it require any reasoning/judgment? → Sonnet
• Sonnet vs Opus: Are there trade-offs to balance or multiple valid approaches? → Opus
• Default rule: When in doubt, go one tier up (better quality > cost savings)

Quality vs Cost trade-offs:

• Cost-sensitive: Batch processing, exploratory work, drafts → prefer lower tier
• Quality-critical: Customer-facing, executive, production, irreversible → prefer higher tier
• Iteration-friendly: Can easily retry with higher tier if insufficient → start lower

Speed considerations:

• Haiku is ~3-5x faster than Sonnet, ~10x faster than Opus
• For latency-sensitive workflows (UI feedback, real-time), prefer Haiku/Sonnet
• For batch/async work, speed matters less than quality

Output Format

[emoji] **[Model]** — [1-line reason]

💰 Cost: [lowest/medium/highest] | ⚡ Speed: [fastest/medium/slowest]

💡 [Optional: "Consider [other model] if [condition]"]

Example output:

🔴 **Opus** — Multi-stakeholder strategic decision with trade-offs

💰 Cost: highest | ⚡ Speed: slowest

💡 Consider Sonnet if this is exploratory (draft) rather than final recommendation

Examples

Technical Tasks

Business & Strategy

Creative & Analysis

Commands, Skills, Agents

Philosophy

• Right-size, don't default up — the cheapest model that meets quality requirements is the correct choice; upgrading is easy, right-sizing takes discipline.
• Task type over task size — model selection depends on reasoning complexity, not the volume of text or files involved.
• Tier aliases over model names — use fast/balanced/reasoning tiers; specific model names change; tier semantics persist.
• Escalate explicitly — if a lower tier fails, escalate with a documented reason rather than defaulting to the top tier always.

When to Use

• When a user asks "which model should I use for this task?" before starting work
• When selecting between multiple LLM tiers for an automated agent workflow or pipeline
• When cost vs capability tradeoff needs to be explicit (e.g. batch jobs, production routing)
• When an agent must self-assign a model for a sub-task without human input
• When an existing workflow is over-spending on frontier models for simple tasks

When Not to Use

• When the model is already fixed by infrastructure constraints (e.g. a provider only offers one model)
• When the task has already been completed and model selection is moot
• When the user is asking about non-Claude providers and needs a cross-vendor comparison tool
• When fine-tuned or domain-specific models are the deciding factor, not tier
• When the decision depends on real-time pricing data not available in this skill

Anti-Patterns

• NEVER default to the most powerful model for every task — Oversized models inflate costs without quality gain on simple tasks. Why: A haiku/flash-class model handles classification and routing at 10x lower cost.

• NEVER pick a model based on benchmark leaderboards alone — Benchmark tasks often differ from production workloads. Why: Real task performance depends on prompt structure, context length, and domain specificity.

• NEVER hardcode model names in agent workflows — Providers rename and deprecate models frequently. Why: Hardcoded names break silently on deprecation; use model tier aliases (fast/balanced/reasoning).

  # BAD - pinned to a specific model id; breaks silently when the vendor retires it
  routing:
    summarizer: claude-3-haiku-20240307
    reviewer: claude-3-opus-20240229
  
  # GOOD - tier alias resolved to a current model id at runtime
  routing:
    summarizer: fast    # resolves to whichever model is the current fast tier
    reviewer: reasoning  # resolves to whichever model is the current reasoning tier

• NEVER skip escalator checks for ambiguous tasks — Underestimating complexity leads to poor output requiring costly reruns. Why: A single missed escalator (e.g. multi-stakeholder, security risk) can push a task from Sonnet to Opus quality requirements.

  # BAD - classifies on task label alone, ignores escalator signals
  Task: "refactor the auth module"
  -> Sonnet (looks like "single-file coding")
  
  # GOOD - checks escalators before committing to a tier
  Task: "refactor the auth module"
  Escalators checked: touches 3+ files (Scope) + handles credentials (Stakes)
  -> Opus (two escalators fired; Sonnet would under-resource this)

• NEVER conflate speed preference with model tier — Choosing Haiku solely for latency on a reasoning-heavy task produces wrong answers. Why: Speed and capability are separate dimensions; use the decision matrix first, then consider latency constraints.

Usage Examples

Selecting a model for a code review task:

# Task: review 200-line TypeScript file for bugs
# Tier: balanced (Sonnet-class) — reasoning needed but not frontier
# Escalators: none (single file, no production risk flagged)
# Output: model alias + rationale
# -> Recommendation: Sonnet — single-file code review, moderate reasoning required

Routing a summarization request:

# Task: summarize 5 meeting notes into bullet points
# Tier: fast (Haiku-class) — no complex reasoning needed
# Escalators: none (<2K words, no stakeholder trade-offs)
# -> Recommendation: Haiku — simple text transformation, no judgment required

Classifying a strategic planning task:

# Task: design a market entry strategy for a new region
# Tier: reasoning (Opus-class)
# Escalators: strategic impact + cross-functional synthesis + ambiguity
# -> Recommendation: Opus — multiple escalators detected (strategic impact, ambiguity, cross-functional)

References

• Reference — extended decision matrix by file type and domain, cost/latency tradeoffs, edge cases, hybrid task patterns, and common mistakes