· 7 min read ·
When to use each Claude model
Practical guide to when to use Haiku, Sonnet, Opus or Fable depending on the type of task, and what happens when a new version comes out.
Most people pick a Claude model on day one and never touch it again. Some always leave it on the most powerful one and end up overpaying for tasks that don’t need it; others leave it on the cheapest one and get weak answers when the problem is actually hard. The rule we use is simple: the cheapest model that does the task well, and go up only when it falls short.
To apply it without memorizing version names, it helps to think of the models as roles, not as a power scale.
Think of a four-person team
The easiest way to remember when to use each model is to picture a team of four people, ordered from least to most capable, and also from faster and cheaper to slower and pricier.
- Haiku, the intern. Simple tasks, solved fast, hard to get wrong.
- Sonnet, the assistant. Knows a bit of everything. The default choice for day-to-day work.
- Opus, the expert. Slower and more expensive, but better at the hard stuff.
- Fable, the director. The expert among experts. Reserved for the longest, most complex work, the kind that can run without you watching it.
The general rule is to start at the bottom and go up only when the result isn’t good enough. The assistant carries most of the day; the intern clears the mechanical load; the expert and the director get called in only when the task genuinely needs them.
Haiku, the intern
Searching the web and summarizing it. Pulling data off a page. Sorting things into categories. Saving information in the right place. Reading a file and extracting what matters. None of these tasks need deep reasoning, they need speed and not tripping over the obvious, and that’s where Haiku is fast, cheap and reliable.
Where it really pays off is in subagents: small helpers that Claude launches in parallel, each one handling a piece of the work. With twenty pages to read, twenty interns working at once come out cheap and finish almost instantly. It’s the fastest and cheapest of the four, so it shines when there are many small, well-defined tasks, not when a single task is hard.
Don’t ask it to design the solution or make decisions with many variables in play. It’s good at executing something that’s already clear, not at deciding what to do.
Sonnet, the assistant
If you’re unsure which model to use and the task isn’t clearly complex or clearly trivial, the choice is Sonnet. Getting the default model right saves more than optimizing every individual choice.
It knows a bit of everything, responds fast, and is reasonably priced: writing an email, reviewing a draft, answering questions, putting together a first version, making code changes that aren’t critical, organizing information. The most recent version gets close to expert-level quality on daily coding and step-by-step tasks, and it’s still fast and affordable. For most day-to-day work, this is the default model.
Only when the task starts demanding too much (a problem that needs multi-step reasoning, a plan that has to be redone more than once) is it time to move up to the expert.
Opus, the expert
You pay more per token, but a well-thought-out plan saves hours of misdirected work, and that’s Opus’s territory: designing a system’s architecture, chasing a bug that won’t give in, mapping out a plan that needs several passes of thinking, making decisions with many variables in play.
When the task is complex, Opus takes its time: it reasons, tests, corrects and tries again until it lands on a good answer. It’s slower and costs more than the assistant, but it shows on hard work, especially when it comes to planning. When a big task needs to be thought through before touching it (breaking it down, anticipating problems, deciding the order), Opus is the one who actually thinks it through.
Long tasks, complex system design, bugs that hide well, heavy intellectual work like analysis, reports or documents: in all of these cases it keeps the context organized as the task grows.
Fable, the director
Fable is the director, the highest rank on the team, the most senior of all: very complex or very long tasks, with a lot of reasoning and iteration ahead, that can also run on their own without direct supervision. That’s where it delivers: building a well-specified system and getting it right the first time, running for hours without needing corrections, reviewing code and debugging it thoroughly, reading dense or messy images, coordinating several subagents at once.
It’s also the slowest and most expensive, so it doesn’t make sense to put it on work the assistant solves in seconds. It’s worth saving for what no other model on the team handles well. It performs best on processes you launch and let run, not on quick tasks that need judgment at every step.
When a new version comes out
Models get updated, and that can complicate the rule. A common case: someone uses Opus 4.8 for the hard stuff, then Sonnet 5 comes out, almost as capable as that Opus but faster and cheaper. The temptation is to switch to Sonnet 5 for complex tasks.
Our recommendation is not to change anything about the previous method.
If Sonnet 5 has come out, Opus 5 is around the corner. And when it arrives, it will pull ahead of Sonnet on the hard stuff again, closing exactly the gap that seemed to have narrowed. Reorganizing the method every time a new model comes out means changing things constantly for no reason.
The rule holds version after version because it’s not about numbers, it’s about roles. The intern, the assistant, the expert and the director are still there; only their names change, and they get better. In our experience, it pays to keep the method and wait: as soon as the next Opus arrives, the gap between models comes back.
New versions improve each model, but the order between them stays the same. In general, the current Opus reasons better than the current Sonnet.
Subagents and the model field
When working with subagents in Claude, each one carries a small configuration header (the frontmatter) that defines how it behaves. One of those settings is model, and that’s where you set which model it uses.
The trick is to write the model name without a version: haiku, sonnet, opus, fable. Not haiku-4-5, just haiku.
---name: web-researcherdescription: Searches the web and summarizes what it finds.model: haiku---Why no version? Because that way, when a new version of Haiku comes out, agents start using it automatically, without touching anything. You write haiku once and it always runs on the best Haiku available.
You can also do the opposite. Instead of the generic name, you write the model’s full id, with its version and date, like claude-haiku-4-5-20251001, and the agent stays locked to that exact version no matter what comes after.
The generic name is the right default: agents benefit from every improvement at no cost. Pinning a specific version makes sense only when there’s a reason for it. Maybe an older or smaller version is cheaper or faster than that particular job needs. Or maybe it’s a production agent that has to behave the same way every time, and a new release that changes its output, even for the better, is a risk worth avoiding.
It’s the same idea as the previous section, just automated. You choose by role, not by version number, and improvements arrive on their own, unless you decide to freeze one on purpose.
The whole guide in one table
Everything above fits in a table.
| If the task is… | Call | Unless… |
|---|---|---|
| Search, summarize, extract or save data | Haiku | it needs judgment → Sonnet |
| Day-to-day work: writing, reviewing, answering, routine edits | Sonnet | it gets stuck on something that needs reasoning → Opus |
| Architecture, stubborn bugs, plans that need several passes | Opus | it’s huge and can run without supervision → Fable |
| Very complex or very long, autonomous and unsupervised | Fable | it can be split into simple pieces → Haiku / Sonnet |
| A subagent searching and gathering in parallel | Haiku | each piece needs deep reasoning → Sonnet / Opus |
Starting at the bottom and moving up, not the other way around, is the part people forget most. Choosing the most powerful model “just in case” is the most expensive mistake, and also the most common one.
Always use the cheapest one that does the job well, and go up only when you need to.