Matching Model Choice to Task Demands
CoreAlign model selection with the task's needs · Difficulty 2/5
Explanation
Matching the Model to the Demand
Model selection is about matching a model to what the task actually demands:
- Speed/cost matter, reasoning is simple -- a faster, lower-cost model (Haiku). The canonical exam example: generating a high volume of short customer-reply drafts, where speed and cost matter more than deep reasoning. The correct choice is the faster, lower-cost model, not the top-tier one.
- Balanced everyday work -- Sonnet handles most drafting, summarizing, and analysis well.
- Hard, high-value reasoning -- Opus, where the quality gain is worth the added cost and time.
Latency Compounds at Volume
For a single request, using a slower, more capable model just means one slower answer. For a high-volume batch workflow -- thousands of short replies, for example -- that same per-request slowdown compounds across the whole batch. A top-tier model can bottleneck an entire workflow even though each individual answer it produces is higher quality.
Common exam traps
- Ignoring latency for high-volume tasks -- a slow top-tier model can bottleneck a batch workflow even if each individual answer is higher quality.
- Picking a model based on the hardest request the workflow might ever see, rather than the typical request it actually handles.
Key Takeaways
- Simple, high-volume, latency-sensitive work calls for a faster, lower-cost model (Haiku)
- Sonnet is the right fit for balanced everyday drafting, summarizing, and analysis
- Opus earns its cost only on hard, high-value reasoning where the quality gain justifies it
- Per-request latency compounds across a high-volume batch workflow
- Match the model to the typical request the workflow handles, not the hardest case it could see
Glossary Terms
The fastest and most cost-effective Claude model tier, optimized for high-throughput, low-latency tasks like classification, extraction, and simple Q&A. Carries a 200K-token context limit (vs 1M on Sonnet/Opus) and is the recommended first-pass router in tiered pipeline architectures.
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.
The most capable Claude model tier, excelling at complex multi-step reasoning, nuanced analysis, and high-stakes creative tasks. Highest accuracy but most expensive and slowest. Best suited for tasks where output quality outweighs cost and latency concerns.
The balanced Claude model tier offering the best trade-off between capability, speed, and cost for most production applications. The recommended default for new systems — handles the majority of complex tasks effectively without Opus-level expense.
Related Concepts