Model Routing Cheat Sheet

The Core Principle

The best model for a task is the cheapest model that produces acceptable quality. Not the newest, not the most powerful, not the most expensive. The cheapest one that works.

This sounds obvious, but most teams default to the strongest model for everything and wonder why their AI costs are unsustainable. Model routing is the practice of matching each task to the right model based on complexity, latency requirements, and budget.

---

Model Comparison Table (April 2026)

Prices are per 1 million tokens. Actual costs vary by provider tier and volume discounts.

Model	Provider	Input Cost	Output Cost	Context Window	Latency Tier	Best For
Claude Haiku 4.5	Anthropic	$0.80	$4.00	200K	Fast (1-3s)	Classification, extraction, simple Q&A, worker agents
Claude Sonnet 4.6	Anthropic	$3.00	$15.00	200K	Medium (3-8s)	Coding, analysis, most production tasks
Claude Opus 4.6	Anthropic	$15.00	$75.00	1M	Slow (8-20s)	Architecture, complex reasoning, agent orchestration
GPT-4o	OpenAI	$2.50	$10.00	128K	Medium (3-8s)	General purpose, multimodal, broad knowledge
GPT-o3	OpenAI	$10.00	$40.00	200K	Slow (10-30s)	Math, logic, STEM reasoning, chain-of-thought
Gemini 2.5 Pro	Google	$1.25	$10.00	1M	Medium (3-10s)	Long context, code generation, multimodal
DeepSeek V3	DeepSeek	$0.27	$1.10	128K	Fast (1-3s)	Budget coding, translation, bulk processing

Note: Prices as of April 2026. Check provider websites for current rates. Extended thinking / reasoning modes incur additional costs on most models.

---

Decision Matrix: Task Type to Model

Use this table to route tasks to the right model. Start from the top — if the cheapest option works, stop there.

Tier 1: Fast and Cheap (Haiku 4.5 / DeepSeek V3)

Task	Why This Tier
Classify intent (support ticket, email category)	Pattern matching, no reasoning needed
Extract structured data from text	Well-defined output schema
Summarize short documents (<2K words)	Compression, not reasoning
Generate boilerplate code	Templates with minor variation
Validate input format	Rule-based checks
Translate between languages	Well-trained capability across all models
Worker agents in multi-agent pipelines	Speed and cost matter more than depth

Tier 2: Balanced (Sonnet 4.6 / GPT-4o / Gemini 2.5 Pro)

Task	Why This Tier
Write production code (features, bug fixes)	Needs understanding of codebase context
Analyze and explain complex code	Requires reasoning about control flow
Draft long-form content (articles, docs)	Coherence over 1,000+ words
Code review with actionable feedback	Needs to understand intent, not just syntax
API design and schema modeling	Moderate architectural reasoning
Multi-step data analysis	Needs to chain reasoning across steps
Conversational AI with memory	Context management and coherence

Tier 3: Maximum Reasoning (Opus 4.6 / GPT-o3)

Task	Why This Tier
System architecture decisions	Trade-off analysis across many dimensions
Complex debugging (race conditions, memory leaks)	Deep reasoning about program state
Multi-agent orchestration (manager role)	Must plan, delegate, and review intelligently
Legal or compliance analysis	High stakes, nuanced interpretation
Research synthesis across many sources	Must identify patterns across large context
Novel algorithm design	Creative reasoning, not pattern matching
Judge role in debate/review patterns	Must evaluate competing arguments fairly

---

Cost Optimization Patterns

1. Cascade Routing

Start with the cheapest model. If it fails or confidence is low, escalate to the next tier.

async def cascade_route(prompt: str) -> str:
    # Try Haiku first — fast and cheap
    result = await call_model("haiku-4.5", prompt)
    
    if confidence_score(result) > 0.85:
        return result  # Good enough
    
    # Escalate to Sonnet
    result = await call_model("sonnet-4.6", prompt)
    
    if confidence_score(result) > 0.75:
        return result
    
    # Final escalation to Opus
    return await call_model("opus-4.6", prompt)

Cost savings: 60-80% compared to always using Opus. Most requests resolve at the Haiku tier.

2. Complexity Detection

Analyze the input before choosing a model. Simple inputs go to cheap models; complex inputs go to expensive ones.

def estimate_complexity(prompt: str) -> str:
    """Quick heuristic to estimate task complexity."""
    word_count = len(prompt.split())
    has_code = "```" in prompt or "function" in prompt
    has_multi_step = any(w in prompt.lower() for w in ["then", "after that", "finally", "steps"])
    
    if word_count < 50 and not has_code and not has_multi_step:
        return "haiku"
    elif word_count < 500 or (has_code and not has_multi_step):
        return "sonnet"
    else:
        return "opus"

Cost savings: 40-60%. Accuracy depends on the quality of your complexity heuristic. Start simple, refine with data.

3. Budget Caps

Set hard limits per user, per session, or per task. When the budget is exhausted, downgrade to cheaper models or queue requests.

class BudgetManager:
    def __init__(self, daily_budget_usd: float = 50.0):
        self.daily_budget = daily_budget_usd
        self.spent_today = 0.0
    
    def select_model(self, preferred: str) -> str:
        remaining = self.daily_budget - self.spent_today
        
        if remaining < 1.0:
            return "haiku"  # Emergency mode — cheapest only
        elif remaining < 10.0:
            return min(preferred, "sonnet", key=model_cost)
        else:
            return preferred

Cost savings: Guarantees you never exceed budget. The trade-off is quality degradation when the budget runs low.

4. Caching

Cache responses for identical or near-identical prompts. Use semantic similarity for fuzzy matching.

def get_or_generate(prompt: str, model: str) -> str:
    cache_key = hash_prompt(prompt)
    
    cached = cache.get(cache_key)
    if cached and cached["model"] == model:
        return cached["response"]  # Free
    
    response = call_model(model, prompt)
    cache.set(cache_key, {"model": model, "response": response}, ttl=3600)
    return response

Cost savings: Depends on repetition rate. For customer support agents, caching can reduce costs by 30-50%. For unique coding tasks, minimal savings.

---

When to Use Local Models

Local models (running on your hardware via Ollama, llama.cpp, or vLLM) make sense in specific scenarios.

Use Local Models When:

Scenario	Recommended Local Model	Why
Data cannot leave your network	Llama 3.3 70B, Qwen 2.5 72B	Compliance, security, data sovereignty
High-volume, low-complexity tasks	Qwen 2.5 7B, Llama 3.2 3B	Zero marginal cost after hardware
Offline or air-gapped environments	Any quantized model that fits in RAM	No internet dependency
Rapid prototyping and testing	Qwen 2.5 Coder 32B	Instant responses, no API costs
Embedding generation	Nomic Embed, BGE-M3	Embedding is a commodity; local is 10x cheaper

Do NOT Use Local Models When:

• You need state-of-the-art reasoning (Opus/o3 class)
• You need 200K+ context windows with high quality
• Your hardware cannot handle the model size (rule of thumb: model parameter count in billions * 0.5 = minimum GB of RAM for quantized inference)
• Latency requirements are under 1 second for complex tasks

The Hybrid Approach

The most cost-effective setup in 2026 is hybrid: local models for embeddings, classification, and simple tasks; cloud models for reasoning, coding, and complex analysis. Route by task type, not by habit.

---

The 80/20 Rule of Model Selection

Here is the uncomfortable truth: 80% of tasks that teams send to Opus or GPT-4o would produce equivalent results with Sonnet or Haiku.

Teams over-index on model capability because:

1. They do not measure quality at each tier
2. They fear the consequences of a cheaper model failing
3. It is easier to always use the best than to build routing logic

The fix is simple: run your actual workload against each model tier, measure quality, and route accordingly. Most teams that do this discover they can cut their AI costs by 60-70% with no perceptible quality drop.

Practical Action Plan

1. Week 1: Log all LLM calls with model, input, output, and a quality score (manual or automated).
2. Week 2: Re-run the same inputs against Haiku. Score the outputs. Identify tasks where Haiku matches Opus.
3. Week 3: Implement cascade routing for the tasks where Haiku works. Keep Opus for the rest.
4. Week 4: Measure cost savings. Iterate.

---

Quick Reference Card

Save this for daily use:

HAIKU 4.5    → Classification, extraction, simple Q&A, worker agents
SONNET 4.6   → Coding, analysis, content, code review, most tasks
OPUS 4.6     → Architecture, complex debug, orchestration, judging
GPT-4o       → Multimodal, general purpose, alternative to Sonnet
GPT-o3       → Math/logic puzzles, STEM, chain-of-thought reasoning
GEMINI 2.5   → Long documents (1M context), code gen, multimodal
DEEPSEEK V3  → Budget bulk processing, translation, simple coding
LOCAL (7-70B) → Offline, data sovereignty, embeddings, high-volume

The model you choose matters less than having a system for choosing. Build the routing logic once, and every task gets the right model automatically.