OCTOBER 20, 2026
Which Claude Model Should Your Team Use for Coding?
Fable, Opus, Sonnet and Haiku are not four sizes of the same tool. Here is how to pick the right Claude model for each kind of coding work, what each one is good at, and where a human still has to decide.
By Umar Abdullah · Artificial Intelligence
Short answer: use the strongest model where a wrong answer is expensive, and the cheapest model that is good enough everywhere else. In practice that means Opus (or Fable for the hardest problems) for architecture, security review and long-running agent work, Sonnet for everyday feature work, and Haiku for high-volume jobs like test generation, docs and subagents. Picking one model for everything is the most common way teams overpay or under-deliver.
Are the Claude models just small, medium and large versions of one thing?
Not quite. They share a family, but Anthropic positions them for different jobs, and the cost gap between tiers is large. Fable sits at the top for the most demanding reasoning and long-horizon agents. Opus is the strongest everyday choice for complex agentic coding. Sonnet balances speed and intelligence. Haiku is the fast, cheap tier, which Anthropic itself positions for subagents and high-volume work rather than hard coding problems.
Exact prices and context windows change often and some third-party price lists disagree, so check Anthropic's pricing page before you budget. What stays stable is the ordering: Fable costs the most, then Opus, Sonnet and Haiku.
Which model for which kind of work?
| Task | Model to start with | Why |
|---|---|---|
| Architecture, system design, hard debugging | Opus, Fable for the truly hard cases | A wrong decision here costs weeks, so pay for the best reasoning |
| Security review of generated code | Opus | Subtle flaws are exactly where weaker models miss things |
| Long-running agent work across many files | Opus | Stays coherent over many steps |
| Everyday features, refactors, bug fixes | Sonnet | Strong enough, much cheaper, faster |
| Tests, docs, boilerplate, migrations at volume | Haiku or Sonnet | The task is well specified, so the cheap tier is usually enough |
| Subagents doing narrow lookups or checks | Haiku | Many small calls, cost and latency dominate |
What is each tier actually good at?
- Fable. Long, open-ended problems where the model has to hold a lot in its head: deep research-style tasks, tricky system design, or an agent that must plan across a large codebase. Slowest and most expensive, so use it deliberately.
- Opus. The workhorse for hard engineering. It handles multi-file changes, careful refactors and security-minded review, and it stays on track through long agent sessions.
- Sonnet. Fast and capable enough for most day-to-day coding: implementing a well-described feature, fixing a bug with a clear reproduction, writing a component or an endpoint.
- Haiku. Quick and cheap. Best when the task is narrow and well specified, or when you will run it hundreds of times, for example summarising diffs or checking one rule across many files.
Why not just use the best model for everything?
Cost and speed, mostly. Anthropic's own numbers on a coding benchmark subset show the pattern: the top models solve slightly more tasks, but the cost per solved task is far higher, and Anthropic notes the strongest models largely saturate that benchmark. When most tasks are already solvable by a cheaper model, the extra spend buys very little.
The practical rule is to escalate, not default up. Start a task on the cheaper model. If it loops, produces something that fails review, or touches a risky area, move that task up a tier. You pay for the top tier only on the work that needs it.
What does a sensible team setup look like?
- Default to Sonnet for day-to-day work in the editor or CLI.
- Reach for Opus when planning a change that spans many files, reviewing a pull request for security, or running a long agent session.
- Use Haiku in the pipeline, for things like generating test cases, summarising diffs, or fanning out narrow checks as subagents.
- Keep Fable for the rare hard problem, such as a design you cannot afford to get wrong or a research-style task, and treat it as an exception you can justify.
What does this look like on a real feature?
Here is an illustrative flow for adding a "team invites" feature to a SaaS app. It is an example of the routing, not a benchmark.
Only steps 1 and 4 needed the top tier. The bulk of the typing happened on cheaper models.
Ship faster with senior engineers
Direct collaboration, AI-augmented delivery, and no agency markup.
Get in touchWhat are the common mistakes?
- Defaulting to the biggest model "to be safe." It feels safe, but it hides the real safeguard, which is review.
- Defaulting to the smallest model to save money. You then pay it back in rework, and in bugs that reach production.
- Judging models on one impressive demo. A single good answer says little about how a model behaves across your whole backlog.
- Skipping the risk map. Without knowing which code is high-stakes, every model choice is a guess.
- Treating fluent output as correct output. Confident, tidy code can still have a missing authorization check.
Where does a human still have to decide?
Everywhere that matters. No model tier removes the need for a person to own the result. Business logic, scalable architecture, feature priorities, security decisions and edge cases still need senior engineering judgment. We treat the model as a fast pair of hands: it drafts, a senior engineer decides and reviews.
The riskiest mistake is trusting output because it is fluent. AI-generated code that touches authentication, payments or data access should always get a human security review, whichever model wrote it. A stronger model makes fewer mistakes, but it does not make zero, and its mistakes can be harder to spot.
How do you check you picked the right model?
Run the same real task on two tiers and compare three things: did it pass your tests, how much human correction did it need, and what did it cost. Do this on your own codebase, not a public benchmark, because your conventions and your risk areas are what matter. If the cheaper tier passes with light correction, that is your default for that kind of task.
What would we do differently if we were starting today?
Write down your risk areas before you pick models. Teams that decide first which code is high-stakes (auth, money, personal data) route that work to the top tier plus human review by rule, and everything else to cheaper tiers. It removes the daily argument about which model to use and puts the money where mistakes cost most.
If you want help setting up an AI-augmented workflow, see our AI-augmented development approach, our AI app development service, or the AI Code Security Audit for code a model has already written. You may also want to read what to audit in AI-built code.
Sources: Anthropic's model announcements and the Claude Platform docs on optimizing for cost and intelligence. Check Anthropic's pricing page for current rates.