Smart Model Routing

Smart Model Routing

Dynamic model selection based on task complexity. Never use a sledgehammer where a scalpel will do — and never use a scalpel where you need a sledgehammer.

Core Philosophy

Static model assignments ("always use Sonnet for code") waste money on trivial tasks and produce poor results on complex ones. This skill scores every task across three signal categories and routes it to the appropriate model tier automatically.

Default rule: inherit parent model. Only override when the score clearly warrants a different tier. Never specify a model without a scoring reason.

Signal Categories

Three weighted categories are evaluated. Their scores combine into a single complexity score (0-20 typical range, can exceed).

Category 1: Lexical Signals (weight: 0.3)

Analyze the raw text of the request.

Architecture Keywords (+3 each)

Trigger words that indicate high-stakes design work:

• "redesign", "overhaul", "new system", "migrate", "refactor entire", "rewrite"
• "architecture", "from scratch", "greenfield", "new service", "platform"

Example: "Redesign the authentication system" → +3

Risk Keywords (+2 each)

Domains where mistakes are expensive or irreversible:

• "production", "security", "auth", "authentication", "authorization"
• "payment", "billing", "database migration", "data loss", "rollback"
• "GDPR", "compliance", "PII", "encryption", "secrets", "credentials"

Example: "Update the payment processing logic" → +2

Simple Keywords (-2 each)

Signals the task is mechanical and bounded:

• "fix typo", "update text", "rename", "add comment", "change color"
• "update label", "fix spacing", "update copy", "minor tweak"

Example: "Fix the typo in the header" → -2

Question Depth (+1 per layer of constraint)

Count nested conditions, multiple constraints, OR clauses:

• Single direct question → 0
• "...but also consider X" → +1
• "...and it must handle Y, while also supporting Z" → +2

Word Count Thresholds

• Under 20 words → -1 (terse request, likely simple)
• Over 200 words → +1 (detailed spec, likely complex)
• Over 500 words → +2 (full brief, high complexity expected)

Category 2: Structural Signals (weight: 0.4)

Analyze the task structure, not just the words.

Subtask Count

How many discrete steps or deliverables?

• 1 subtask → 0
• 2-3 subtasks → +1
• 4-6 subtasks → +2
• 7 or more → +3

Example: "Build an endpoint, write tests, add validation, update docs, add migration, hook up auth, notify the frontend team" → +3

Cross-File Dependencies

How many files will be touched?

• 1 file → 0
• 2-3 files → +1
• 4 or more files → +2

Use tldr impact <function> or tldr calls . to estimate before scoring.

Impact Scope

Where in the system does this change land?

• Function-level change → 0
• Module or feature boundary → +1
• System-wide, cross-cutting concern → +3

Examples:

• "Update the formatDate helper" → 0
• "Refactor the notification module" → +1
• "Change how auth tokens are validated across all routes" → +3

Reversibility

Can this be easily undone?

• Easily reversible (toggle a flag, revert a file) → 0
• Hard to undo (DB migration, data transform, breaking API change) → +2

Test Requirement

What level of test coverage is needed?

• No new tests required → 0
• Extend existing tests → +1
• Write a new test suite from scratch → +2

Category 3: Context Signals (weight: 0.3)

The situation around the request, not just the request itself.

Previous Errors in Session

Has this task or related area already failed once?

• 0 errors so far → 0
• 1-2 prior failures on this task → +1
• 3 or more failures → +2

Rationale: repeated failures indicate the problem is genuinely hard. Escalate.

Agent Chain Depth

Is this a top-level user request or the 3rd handoff in a chain?

• Direct request → 0
• 2 agents deep → +1
• 3 or more agents deep → +2

Deep chains accumulate complexity. Each layer adds ambiguity risk.

Codebase Familiarity

Is this a well-trodden path or new territory?

• Known patterns, familiar framework → 0
• New-to-session framework, unfamiliar library → +2
• Undocumented legacy code, no tests exist → +3

Tier Thresholds

After computing the weighted sum:

raw_score = (lexical_raw * 0.3) + (structural_raw * 0.4) + (context_raw * 0.3)

Confidence Calculation

Score proximity to a threshold boundary determines confidence.

Escalation on Low Confidence

When confidence is LOW, always round up to the higher tier. A false negative (using a weak model on a hard task) is far more costly than a false positive (using a strong model on an easy task).

Example:

• Score = 7.2, threshold for HIGH = 8 → Distance = 0.8 → LOW confidence → use Opus anyway
• Score = 5.8, threshold for MEDIUM = 4 → Distance = 1.8 → LOW confidence → use Sonnet (already in medium, no escalation needed)
• Score = 3.1, threshold for LOW = 4 → Distance = 0.9 → LOW confidence → use Sonnet (escalate from Haiku)

Hard Rules (Override Score)

These override the scoring system completely. No exceptions.

Never Use Haiku For:

• Security reviews of any kind
• Authentication or authorization logic
• Architectural or design decisions
• Any task touching payment, billing, or financial data
• Multi-file refactoring (4+ files)
• Database migrations
• Unfamiliar codebases without existing tests

Always Use Opus For:

• System design from scratch
• Complex multi-step debugging with no clear root cause
• Migration planning (major version upgrades, framework migrations)
• Security audit of critical paths
• When 2+ prior attempts have failed on the same task
• Agent chains 3+ deep on a non-trivial task

Application Rules

For Agent Spawns

When spawning sub-agents, include model selection in the spawn parameters only when the score warrants it. Omit model entirely when the task should inherit.

// CORRECT: score = 9 (HIGH) → specify Opus
Task({
  prompt: "Design the new event sourcing architecture...",
  model: "claude-opus-4-5"
})

// CORRECT: score = 5 (MEDIUM) → inherit, omit model
Task({
  prompt: "Add input validation to the create endpoint..."
  // no model param
})

// WRONG: always specifying model
Task({
  prompt: "Fix the typo in the README",
  model: "claude-opus-4-5"  // wasteful
})

For Inline Decisions

When deciding which model to use for your own reasoning:

• If score >= 8 and you are not already on Opus: note the gap and do your best
• If score < 4: do not overthink, execute directly

Scoring Examples

Example 1: Trivial Fix

Request: "Change the button text from 'Submit' to 'Save'"

Tier: LOW. Model: Haiku-class. Confidence: HIGH.

Example 2: New Feature Endpoint

Request: "Add a POST /api/orders endpoint with Zod validation, rate limiting, auth middleware, and write integration tests"

Wait — re-check: "auth middleware" is a risk keyword (+2 lexical). Update:

Tier: MEDIUM. Model: Sonnet. Hard rule override applied.

Example 3: Security Audit

Request: "Audit the authentication flow. We've had two incidents this week where tokens weren't being validated correctly in production. Find root cause and fix."

But: hard rule "security review of any kind" AND "2+ prior failures" → override to HIGH.

Tier: HIGH. Model: Opus. Hard rule override applied (security + repeated failures).

Example 4: Database Migration

Request: "Migrate the users table to add a composite index on (email, tenant_id), backfill existing rows, and update all queries that touch this table"

But: hard rule "database migration" → override to HIGH.

Tier: HIGH. Model: Opus. Score near boundary + hard rule.

Decision Log Format

Every routing decision must be logged:

ROUTING DECISION
  TASK: [brief description]
  SCORE: [weighted total] (lexical=[X], structural=[Y], context=[Z])
  TIER: [LOW|MEDIUM|HIGH]
  CONFIDENCE: [HIGH|LOW]
  HARD_RULE: [rule name if override applied, else "none"]
  MODEL: [selected model]
  REASON: [1-sentence justification]

Example:

ROUTING DECISION
  TASK: Security audit of auth token validation
  SCORE: 6.3 (lexical=8, structural=9, context=1)
  TIER: HIGH (override from MEDIUM)
  CONFIDENCE: HIGH
  HARD_RULE: security-review + repeated-failures
  MODEL: claude-opus-4-5
  REASON: Active production security incident with two prior failures; hard rule override applied

Integration with vibecosystem

Agent Assignment Matrix

This skill overrides the default model assignments in agent-assignment-matrix.md when a scoring reason exists. The matrix defines WHICH agent handles a task; this skill defines WHICH MODEL that agent uses.

Priority order:

1. Hard rules (override everything)
2. Confidence-based escalation
3. Computed tier
4. Agent matrix default
5. Parent model inheritance (fallback)

QA Loop Integration

When a task enters its second or third retry in the qa-loop.md Dev-QA cycle:

• Add +1 to context signals for each prior failure
• Re-score the task
• If tier escalates, upgrade model for the retry

This prevents the failure loop of using the same weak model repeatedly on a hard task.

Memory Recall

Before scoring, check if a similar task has been attempted before:

cd ~/.claude && PYTHONPATH=scripts python3 scripts/core/recall_learnings.py \
  --query "model routing [task description]" --text-only

If a prior attempt used a different tier and succeeded or failed, factor that into the context signal score.

Anti-patterns

Checklist

Before routing any agent spawn or model selection decision:

• Evaluated all three signal categories
• Applied weights (0.3 / 0.4 / 0.3)
• Checked distance from threshold boundary
• Checked all hard rules
• Logged the decision (TASK, SCORE, TIER, CONFIDENCE, HARD_RULE, MODEL, REASON)
• Omitted model param if inheriting from parent

Remember: The goal is the right model for the job. Not the most expensive one. Not the default one. The right one.