Stacking multiple Claude models in a single workflow: when to use Haiku vs Sonnet vs Opus

Most developers using the Claude API default to a single model for everything — usually Sonnet because it feels like the “safe” middle ground. That’s leaving significant money on the table, and in some cases, it’s the wrong quality tradeoff in both directions. When you properly stack Claude models in a workflow, routing requests intelligently across Haiku, Sonnet, and Opus, you can cut costs by 60-80% on high-volume pipelines while actually improving quality on the tasks that matter most.

This isn’t theoretical. I’ve benchmarked this pattern across document processing pipelines, lead qualification systems, and multi-step research agents. The routing logic isn’t complicated — but you need to understand where each model genuinely differentiates before you can design it well.

The Actual Differences Between Haiku, Sonnet, and Opus

Let’s start with the numbers that actually matter for workflow design (prices as of mid-2025, verify current rates at anthropic.com):

• Claude Haiku 3.5: ~$0.80 input / $4.00 output per million tokens. Fastest in the family, typically 60-100 tokens/sec. Best for classification, extraction, simple transformations.
• Claude Sonnet 3.7: ~$3.00 input / $15.00 output per million tokens. The general-purpose workhorse. Good reasoning, strong coding, reliable instruction-following.
• Claude Opus 4: ~$15.00 input / $75.00 output per million tokens. 5× the cost of Sonnet. Reserved for tasks where deep reasoning or nuanced judgment genuinely changes the output quality.

A common misconception is that Opus is “always better.” For many tasks — extracting structured fields from a form, classifying a support ticket, summarizing a short document — Haiku performs identically to Opus at one-twentieth the price. I’ve run the comparison on extraction tasks and seen <2% quality delta between Haiku and Opus when the task is well-defined. For a cost-per-task breakdown across models, the pattern holds: simpler tasks don’t benefit from bigger models.

The second misconception: Sonnet is always the right default. It’s not. For high-throughput pipelines where you’re processing thousands of requests, defaulting to Sonnet when Haiku would suffice is just burning money. And for genuinely complex reasoning tasks — strategic analysis, contract risk assessment, multi-step code architecture — Sonnet sometimes produces outputs that look plausible but miss critical nuance that Opus catches.

Designing the Routing Layer

The core idea is simple: classify the request before you process it, then route to the appropriate model. The classifier itself can be Haiku — it’s fast, cheap, and more than capable of making a binary or ternary routing decision.

The Three-Tier Routing Model

I use a task complexity score from 1-3 to route across the model family:

• Tier 1 (Haiku): Extraction, classification, formatting, simple Q&A with bounded answers, sentiment analysis, short translations
• Tier 2 (Sonnet): Drafting, moderate reasoning, code generation up to ~200 lines, summarization of long documents, multi-step data processing
• Tier 3 (Opus): Deep strategic reasoning, ambiguous high-stakes decisions, complex code architecture, anything where a wrong answer has significant downstream cost

Here’s a working router implementation:

import anthropic
from enum import Enum

client = anthropic.Anthropic()

class ModelTier(Enum):
    FAST = "claude-haiku-3-5"
    BALANCED = "claude-sonnet-3-7"
    POWERFUL = "claude-opus-4-0"

ROUTING_PROMPT = """You are a task complexity classifier. Given a user request, 
output exactly one of: FAST, BALANCED, or POWERFUL.

FAST: extraction, classification, formatting, simple lookup answers
BALANCED: drafting, moderate analysis, code generation, summarization  
POWERFUL: complex reasoning, strategic decisions, ambiguous high-stakes tasks

Request: {request}

Output only the tier label, nothing else."""

def route_request(user_request: str) -> ModelTier:
    """Use Haiku to classify task complexity, then route accordingly."""
    response = client.messages.create(
        model="claude-haiku-3-5",  # Always use Haiku for routing — cheap and fast
        max_tokens=10,
        messages=[{
            "role": "user",
            "content": ROUTING_PROMPT.format(request=user_request)
        }]
    )
    
    tier_label = response.content[0].text.strip()
    return ModelTier[tier_label]

def process_with_routing(user_request: str, system_prompt: str) -> dict:
    """Route and process a request, returning model used and response."""
    tier = route_request(user_request)
    
    response = client.messages.create(
        model=tier.value,
        max_tokens=2048,
        system=system_prompt,
        messages=[{"role": "user", "content": user_request}]
    )
    
    return {
        "model_used": tier.value,
        "tier": tier.name,
        "response": response.content[0].text,
        # Approximate cost tracking
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens
    }

The routing call itself costs roughly $0.000002 per classification — essentially free. If your average request is 500 tokens, you’re paying ~$0.0004 for a Haiku response vs ~$0.0015 for Sonnet. Across 100,000 requests per month, that’s $40 vs $150 just for the processing, before you factor in the tier-3 calls.

A Real Pipeline: Document Processing at Scale

Here’s where the numbers get interesting. I built a contract analysis pipeline that processes 500+ documents per month. Before routing, everything went to Sonnet. After implementing the three-tier model:

• ~65% of requests (field extraction, date parsing, party identification) route to Haiku
• ~30% of requests (clause summarization, obligation lists) route to Sonnet
• ~5% of requests (risk assessment, ambiguous liability analysis) route to Opus

Monthly cost dropped from ~$180 to ~$52 — a 71% reduction. Quality on the Haiku tasks was indistinguishable from Sonnet. Quality on Opus tasks was noticeably better than Sonnet for the edge cases that actually mattered.

If you’re building something similar, the Claude contract review agent pattern covers the extraction architecture in more detail. For structured output validation across tiers — which you absolutely need when mixing models — see the guide on getting consistent JSON from any LLM. One thing I learned the hard way: Haiku occasionally produces slightly looser JSON than Sonnet under the same prompt. Add a Pydantic validation layer between your router and your downstream logic.

When Routing Gets Complicated

Hybrid Tasks: Split Processing

Some tasks have mixed complexity within a single request. A good example: “Extract all contract dates AND tell me whether the liability clause creates unusual risk for a SaaS company.” The extraction is Haiku-level; the risk assessment is Opus-level.

The solution is to decompose the task in your application layer before it hits the router:

def process_compound_task(document: str) -> dict:
    """
    Handle mixed-complexity tasks by splitting into sub-tasks
    and routing each independently.
    """
    # Sub-task 1: Field extraction → Haiku
    extraction_result = process_with_routing(
        user_request=f"Extract all dates, party names, and contract value from:\n{document}",
        system_prompt="Extract structured data. Output valid JSON only."
    )
    
    # Sub-task 2: Risk analysis → likely routes to Opus
    risk_result = process_with_routing(
        user_request=f"Analyze whether this liability clause creates unusual risk for a SaaS vendor:\n{document}",
        system_prompt="You are a contract risk analyst. Be specific about the risk and its magnitude."
    )
    
    return {
        "extraction": extraction_result,
        "risk_analysis": risk_result
    }

Override Logic for High-Stakes Contexts

The router isn’t infallible — it’s a probabilistic classifier. For certain request types, you want hard overrides regardless of what the classifier says. Medical or legal advice, anything involving financial decisions, multi-step agent actions that are hard to reverse. I maintain a keyword blocklist that forces Opus regardless of tier classification:

FORCE_OPUS_PATTERNS = [
    "legal advice", "medical", "financial recommendation",
    "irreversible", "production deployment", "security audit"
]

def get_minimum_tier(request: str) -> ModelTier:
    """Check if request requires a minimum model tier regardless of classifier."""
    request_lower = request.lower()
    if any(pattern in request_lower for pattern in FORCE_OPUS_PATTERNS):
        return ModelTier.POWERFUL
    return ModelTier.FAST  # No minimum — let classifier decide

Latency Tradeoffs You Need to Know

Model routing adds one extra API call (the Haiku classifier). In practice this adds 150-400ms to the total request time. For async batch pipelines, irrelevant. For real-time UX where users are waiting, you need to decide whether that overhead is acceptable.

If latency matters and you know the task type upfront (e.g., from a UI form field or task type enum in your system), skip the LLM classifier entirely and use deterministic routing rules. The LLM classifier is for when you can’t predict task complexity from context alone.

For multi-agent setups where you have a supervisor distributing work across specialized agents, this routing pattern integrates cleanly — the supervisor can include model tier as part of its task delegation. The Claude subagent orchestration patterns article covers how to structure that delegation layer if you’re building something more complex.

Cost Monitoring in Production

Don’t fly blind. Add token tracking per tier from day one:

from collections import defaultdict
from dataclasses import dataclass, field

# Rough cost per million tokens (input/output) — update from Anthropic pricing page
COST_PER_MILLION = {
    "claude-haiku-3-5":   {"input": 0.80,  "output": 4.00},
    "claude-sonnet-3-7":  {"input": 3.00,  "output": 15.00},
    "claude-opus-4-0":    {"input": 15.00, "output": 75.00},
}

@dataclass
class UsageTracker:
    totals: dict = field(default_factory=lambda: defaultdict(lambda: {"input": 0, "output": 0}))
    
    def record(self, model: str, input_tokens: int, output_tokens: int):
        self.totals[model]["input"] += input_tokens
        self.totals[model]["output"] += output_tokens
    
    def estimated_cost(self) -> float:
        total = 0.0
        for model, usage in self.totals.items():
            rates = COST_PER_MILLION.get(model, {"input": 0, "output": 0})
            total += (usage["input"] / 1_000_000) * rates["input"]
            total += (usage["output"] / 1_000_000) * rates["output"]
        return total

Run this for a week before and after implementing routing. The delta will tell you whether your tier boundaries are calibrated correctly. If too much is hitting Opus, your classifier thresholds are too aggressive. If quality drops, you’re over-routing to Haiku.

This pairs well with prompt caching for repeated system prompts — especially on Haiku where you’re processing high volumes. The LLM caching strategies guide covers prompt caching specifically for Anthropic’s API, which can cut another 30-40% off Haiku costs on workflows with static system prompts.

Who Should Use This Pattern

Solo founders and budget-conscious builders: Implement the three-tier router from day one. Even if you start with low volume, the habit of routing correctly will save you when you scale. Use Haiku for everything you can get away with, Sonnet for drafting and moderate reasoning, and reserve Opus for the handful of decisions where quality truly matters.

Teams with established pipelines: Audit your current model usage first. Add token tracking, run a week of data, then identify which request categories are overpaying. Incremental migration — starting with your highest-volume, simplest tasks — is lower risk than a full rewrite.

Enterprise / latency-sensitive: Consider static routing rules over LLM-based classification. You likely know your task types ahead of time from your product’s UX. A deterministic routing table eliminates the classifier overhead entirely and is easier to debug and audit.

The bottom line: if you’re running more than ~10,000 API calls per month, the time investment to properly stack Claude models in a workflow pays back within the first billing cycle. The routing logic takes a day to build and test. The cost savings are permanent.