Model Routing
PatternsDefinition
The practice of directing requests to different Claude model tiers based on assessed complexity and requirements. A common pattern uses a fast, cheap model (Haiku) to classify task complexity, then routes to Sonnet or Opus accordingly.
Example Usage
Route simple FAQ lookups to Haiku, code generation to Sonnet, and complex system design decisions to Opus.
In Depth
What Model Routing Is
Model routing is the architectural decision of which Claude model tier to invoke for a given request at runtime. Rather than sending every request to the most capable (and most expensive) model, a well-designed system classifies each task and dispatches it to the cheapest model that can handle it reliably.
The canonical three-tier stack maps to real model families:
| Tier | Model family | Typical tasks |
|---|---|---|
| Fast / cheap | Claude Haiku | Classification, simple Q&A, extraction |
| Balanced | Claude Sonnet | Code generation, summarisation, moderate reasoning |
| Most capable | Claude Opus | Complex reasoning, multi-step planning, safety-critical decisions |
The Classifier-First Pattern
The most common implementation adds a routing step before the main call. A Haiku call reads the incoming request, scores it on a complexity rubric (token length, presence of ambiguous intent, domain tags), and returns a tier label. The orchestrator then invokes the appropriate model.
Because the classifier is itself a Haiku call, its cost is tiny — a few hundred tokens — yet it can halve overall spend on mixed-traffic workloads where a large fraction of requests are simple.
Beyond Cost: Latency and Quality Floors
Routing is not only about money. Two additional reasons to route:
- Latency: Haiku is substantially faster than Opus; for real-time UI interactions (autocomplete, inline hints) routing to Haiku keeps response times under 500 ms even at scale.
- Quality floor: Routing the wrong direction — sending a complex, multi-constraint problem to Haiku — produces plausible-looking but incorrect output. A good router should err toward the higher tier when the classifier confidence is below threshold.
Routing Signals to Consider
- Task type tag: "creative writing", "code", "legal analysis", "FAQ lookup" — injected by the upstream application layer.
- Context length: requests already carrying large context windows benefit less from Haiku's cheaper pricing because the input token cost dominates.
- User tier: enterprise users may have SLAs that mandate Opus; free-tier users can tolerate Haiku latency.
For more on how routing connects to the broader workflow, see the Task Decomposition & Routing Strategies concept page and task decomposition in this glossary.
How It Compares
| Approach | Routing decision time | Adapts to request content | Cost overhead |
|---|---|---|---|
| Static tier per endpoint | Deploy time | No | None |
| Classifier-first (Haiku router) | Per-request | Yes | ~1 Haiku call |
| Rule-based (regex / token count) | Per-request | Partially | None |
| Confidence-threshold hybrid | Per-request | Yes | ~1 Haiku call |
How It's Tested & Common Confusions
How Model Routing Is Tested on the CCA-F Exam
Common question angle — cost optimisation scenario: You are given a mixed traffic description (80% FAQ lookups, 15% code tasks, 5% architectural reviews) and asked which routing strategy minimises cost while maintaining quality. The correct answer routes FAQ → Haiku, code → Sonnet, architectural → Opus.
Common confusion: Candidates often assume routing is determined statically (per endpoint) rather than dynamically (per-request classifier). The exam may present a scenario where a "code generation" endpoint receives both trivial one-liners and multi-file refactors; the right pattern is dynamic classification, not a blanket per-endpoint tier assignment.
Watch for: Questions that embed a budget_tokens parameter in the routing logic. This is legacy — budget_tokens is removed on Opus 4.7+ and Fable 5 (returns HTTP 400). Correct answers steer reasoning depth via output_config: {effort: ...}, not budget_tokens.
Frequently Asked Questions
Can I use the same Claude model to classify routing AND answer the request?
Technically yes, but it defeats the purpose. The value of classifier-first routing is that you pay Haiku rates for the cheap classification step. If you use Opus to classify, you incur Opus cost before you even know whether the task warrants it. Use the smallest model that can reliably distinguish complexity tiers — Haiku is the standard choice for this role.
What happens if the classifier routes a complex task to Haiku by mistake?
Quality degrades silently: the response looks fluent but may contain subtle errors, missed constraints, or incorrect reasoning steps. Best practice is to set a confidence threshold below which the router escalates to Sonnet rather than defaulting to Haiku. Pair this with an [evaluator-optimizer](/glossary/evaluator-optimizer) layer that checks output quality and can trigger a re-run at a higher tier.