Lesson 3 of 4 · Claude API & Development
Choosing the Right Model
Choosing the Right Model
Story: The $12,000 Mistake
Marcus ran engineering at a SaaS company building an AI-powered customer support platform. When it came time to choose a Claude model, he did what most engineers do: he picked the best one. "We're building a premium product," he told his team. "Our customers deserve the best. We're going with Opus for everything."
Three months later, Marcus was staring at an API bill of $12,000 for a single month. His platform handled about 50,000 support tickets per month. Each ticket went through three stages: classification (routing to the right team), response generation (drafting a reply), and quality check (reviewing the draft before sending). Every stage used Opus.
When his team actually benchmarked the stages, the results were humbling:
| Stage | Opus Accuracy | Sonnet Accuracy | Haiku Accuracy |
|---|---|---|---|
| Classification | 97.2% | 96.8% | 95.1% |
| Response Generation | 94.5% | 92.1% | 78.3% |
| Quality Check | 96.0% | 95.2% | 88.7% |
For classification, Haiku was within 2% of Opus -- and 20x cheaper. For quality checks, Sonnet matched Opus closely. Only response generation showed a meaningful gap. Marcus restructured: Haiku for classification, Sonnet for quality checks, Opus only for the most complex response generation (about 15% of tickets that Sonnet flagged as difficult).
<ConceptCard
front="Choosing the Right Model"
back="Choose Haiku for speed and cost on simple tasks, Sonnet for balanced everyday use, and Opus when maximum reasoning quality justifies the higher cost."
/>
New monthly bill: $2,100. Quality metrics barely changed.
<KeyMetric value="$2,100" label="Optimized Monthly Cost" description="Down from $12,000 -- an 82% reduction by matching model capability to task complexity without sacrificing quality" />
The lesson? Choosing the right model isn't about picking the "best" one. It's about matching capability to need, task by task.
---
Concept: A Decision Framework for Model Selection
The Three Dimensions
Every model selection decision involves three trade-offs:
Quality
/\
/ \
/ \
/ \
/________\
Speed -------- CostNo model wins on all three. Your job is to decide which dimension matters most for each specific task.
Dimension 1: Task Complexity
The single most important factor in model selection is how complex the task is. Here's a practical complexity scale:
<StepReveal steps='[{"label":"Level 1 -- Pattern Matching (Haiku)","content":"Binary classification, entity extraction, sentiment analysis, format conversion, simple Q&A with clear answers"},{"label":"Level 2 -- Reasoning Required (Sonnet)","content":"Code generation, content creation, summarization, multi-step instructions, conversational AI"},{"label":"Level 3 -- Deep Analysis (Opus)","content":"Legal/medical analysis, architectural decisions, creative writing, research synthesis, autonomous agentic tasks"}]' />
Level 1 -- Pattern Matching (Haiku)
Tasks with clear inputs and deterministic-ish outputs:
- Binary classification (spam/not spam)
- Entity extraction (pull names, dates, amounts from text)
- Sentiment analysis (positive/negative/neutral)
- Format conversion (restructure data from one format to another)
- Simple Q&A (lookup-style questions with clear answers)
<Callout type="tip">
Use Choosing the Right Model in a low-risk branch or scratch project first. That keeps the lesson concrete without making your first attempt carry production pressure.
</Callout>
Level 2 -- Reasoning Required (Sonnet)
Tasks that need understanding and judgment:
- Code generation (writing functions, debugging)
- Content creation (marketing copy, technical writing)
- Summarization (distilling long documents into key points)
- Multi-step instructions (following complex workflows)
- Conversational AI (maintaining context, natural dialogue)
Level 3 -- Deep Analysis (Opus)
Tasks requiring extended reasoning or creative judgment:
- Legal/medical analysis (high-stakes, nuanced interpretation)
- Architectural decisions (trade-off analysis, system design)
- Creative writing (nuanced fiction, persuasive essays)
- Research synthesis (combining multiple sources into insights)
- Agentic tasks (autonomous multi-step work)
Dimension 2: Latency Requirements
Response time matters more than most developers realize. Here's what each model typically delivers:
| Model | Time to First Token | Full Response (500 tokens) |
|---|---|---|
| Haiku 3.5 | ~200ms | ~1.5s |
| Sonnet 4 | ~400ms | ~3s |
| Opus 4 | ~800ms | ~8s |
These are approximate values. Actual latency depends on prompt length, output length, server load, and region.
<TryThis title="Measure the Choosing the Right Model Tradeoff">
- Choose one task you repeat often.
- Run it with the model, cost, or performance setting discussed in this lesson.
- Record latency, quality, and cost so you can choose intentionally next time.
</TryThis>
Latency-Critical Use Cases:
- Autocomplete/typeahead -> Haiku (users expect <500ms)
- Chat interfaces -> Sonnet with streaming (users tolerate 1-3s for first token)
- Background processing -> Opus is fine (users aren't waiting)
- Real-time moderation -> Haiku (must be faster than the content it's moderating)
Dimension 3: Cost Analysis
Understanding cost requires understanding tokens. Here's the current pricing:
| Model | Input (per 1M tokens) | Output (per 1M tokens) |
|---|---|---|
| Haiku 3.5 | $0.80 | $4.00 |
| Sonnet 4 | $3.00 | $15.00 |
| Opus 4 | $15.00 | $75.00 |
<FlowDiagram steps={["Start with Sonnet for all tasks","Benchmark quality per task","Promote to Opus only where quality measurably improves","Demote to Haiku where quality does not meaningfully drop"]} />
To make this concrete, let's calculate costs for a real scenario: processing 10,000 customer support tickets per day, where each ticket averages 500 input tokens and 300 output tokens.
The Decision Flowchart
Here's the practical flowchart I use for every new task:
START
|
v
Is the task simple classification,
extraction, or routing?
|
+-- YES -> Haiku
|
v
Does the task require deep reasoning,
creativity, or high-stakes judgment?
|
+-- YES -> Can you afford Opus pricing?
| |
| +-- YES -> Opus
| |
| +-- NO -> Sonnet + extended thinking
|
v
Sonnet (default for everything else)Benchmarking Your Specific Use Case
Generic benchmarks are useful for orientation, but your specific use case may behave differently. Here's how to run your own evaluation:
<ComprehensionCheck
question="What is the main benefit of using Choosing the Right Model well in Claude Code?"
optA="Treat Choosing the Right Model as a one-time setup and assume it will keep working without any further review."
optB="Choose the model or workflow for Choosing the Right Model based on the task's actual complexity, latency needs, and cost."
optC="Use Choosing the Right Model mainly to avoid reading the project itself, since direct context is less important than fast output."
correctId="b"
explanation="Choose the model or workflow for Choosing the Right Model based on the task's actual complexity, latency needs, and cost. That is the pattern the lesson is pushing you toward."
/>
---
Apply: Building a Model Selection Matrix
For a real project, create a spreadsheet or document that maps every API call in your application to a model. Here's the template:
<DoDont do="Start with Sonnet for everything, then promote to Opus or demote to Haiku based on measured benchmarks" dont="Default to Opus for all tasks because it is the most capable -- at scale this costs 5-20x more than necessary" title="Model Selection Strategy" />
<TryThis>
Build your own selection matrix for a project you're working on:
- List every place your app calls the Claude API (or will call it).
- For each call, classify the complexity (Level 1/2/3 from above).
- Note the expected daily volume and latency requirements.
- Calculate the monthly cost for all-Opus vs. optimized model selection.
- The difference is your potential savings -- often 60-80%.
</TryThis>
<PromptCompare>
Same classification task, different models:
Prompt: "Classify this email as spam or not-spam: 'Congratulations! You've been selected for a $1000 gift card. Click here to claim.'"
Haiku (0.3s, $0.0004): "spam" -- Fast, correct, minimal.
Sonnet (1.1s, $0.003): "This email is spam. It uses urgency tactics ('Congratulations!'), an unrealistic offer ($1000 gift card), and a suspicious call to action ('Click here to claim')." -- Correct with explanation.
Opus (3.2s, $0.015): Same quality as Sonnet but 3x slower and 5x more expensive. For this task, Sonnet and Haiku are clearly better choices.
The extra capability of Opus adds nothing for well-defined classification tasks.
</PromptCompare>
---
Reflect: Making the Decision
<Callout type="tip">
The golden rule of model selection: Start with Sonnet for everything. Benchmark. Then promote to Opus only where quality measurably improves, and demote to Haiku only where quality doesn't meaningfully drop. Let data drive the decision, not assumptions.
</Callout>
<Callout type="warning">
Beware the "Opus for everything" trap. It's comfortable to use the most capable model because you never have to worry about quality. But at scale, this comfort costs 5-20x more than necessary. And in many cases, Opus isn't actually better -- it's just slower and more expensive. Always benchmark your specific tasks.
</Callout>
Questions to ask during your next architecture review:
- Have I classified every API call by complexity? Many applications have a mix of simple and complex tasks. Treating them all the same wastes money.
- Do I have fallback models configured? If Opus is down or rate-limited, can your system gracefully fall back to Sonnet?
- Am I measuring quality per model per task? Without metrics, you're guessing. Build automated evaluations and run them weekly.
- Is my team aligned on the decision framework? If different engineers pick models based on gut feel, you'll end up with inconsistent costs and quality.
<KeyTakeaways>
- Model selection has three dimensions: quality, speed, and cost -- no model wins on all three
- Classify tasks by complexity: Level 1 (Haiku) for pattern matching, Level 2 (Sonnet) for reasoning, Level 3 (Opus) for deep analysis
- Start with Sonnet as your default -- promote to Opus or demote to Haiku based on benchmarks, not assumptions
- Build a model selection matrix that maps every API call to a specific model with documented reasoning
- Always benchmark your specific use case -- generic benchmarks don't capture your task's unique characteristics
- Configure fallback models for resilience -- if your primary model is unavailable, the system should degrade gracefully
- The cost difference between all-Opus and optimized model selection is typically 60-80% at scale
- Review quarterly -- as models improve, a task that needed Opus last quarter might work fine with Sonnet today
</KeyTakeaways>
---
Next lesson: We'll dive into the financial side -- pricing tiers, rate limits, token economics, and how to estimate and control your API costs.
Use ← → to navigate, Space to mark complete