Best Claude Model for Coding 2026: Opus 5 vs Sonnet 5

Before the framework, the facts it rests on. These are the self-serve models available on the Claude API as of August 7, 2026, with their standard rates per million tokens.

Claude Haiku 4.5 sits at $1 input and $5 output — the volume tier, and the only model here that predates the 5-series naming.

Claude Sonnet 5 is $2 input and $10 output per million tokens. That began as introductory pricing; Anthropic later dropped the planned September 1 move to $3/$15, so $2/$10 is now the standard rate. It supports a 1M-token context window and up to 128K output tokens per synchronous request.

Claude Opus 5 is $5 input and $25 output — the same rate card Opus has carried since 4.5, so the July 24 launch raised capability without raising price. It's the default model on Max plans, supports 1M-token context and 128K output, and has a Fast Mode running at roughly 2.5x speed for double the rate ($10/$50), available on the first-party Claude API only.

Claude Fable 5 is $10 input and $50 output, positioned for frontier agentic work. Anthropic launched Fable alongside Mythos 5 on June 9, 2026, briefly suspended access on June 12 to comply with U.S. export controls, and restored it on July 1 after those controls were lifted. Mythos 5 is not a self-serve option — it's a trusted-access lane under Anthropic's Project Glasswing.

Two discounts apply across the board and matter more than most model-switching decisions. Prompt caching cuts cache hits to roughly a tenth of standard input cost — Opus 5 cached input reads at $0.50 per million instead of $5.00 — which is enormous for agentic coding, where the same codebase context gets re-read on every turn. The Batch API halves both input and output rates for work that tolerates a delay, putting Opus 5 at $2.50/$12.50.

Here's the mistake I made for my first two months of serious Claude Code use, and the one every price-comparison table quietly encourages.

Per-token pricing tells you what a successful pass costs. It tells you nothing about how many passes you'll need. And on agentic coding — where the model reads files, plans, edits across a codebase, runs commands, and reacts to what breaks — the number of passes is the entire cost story.

Work the arithmetic on a real shape of task. Say a cross-module refactor takes a capable model one pass: read context, plan, edit six files, run the test suite, fix one failure, done. Now say a cheaper model at 40% of the price takes three passes, because the first attempt missed a dependency, the second broke a type, and the third finally landed after you re-prompted with the constraint you shouldn't have had to state. Three passes at 40% each is 120% of the expensive model's cost. You paid more and you spent forty minutes supervising instead of reviewing.

That's the whole case for Opus 5 on hard work, and notably it's the case Anthropic's own positioning makes: Opus earns the gap on long agentic runs where fewer retries beat a cheaper per-token rate, while Sonnet wins on high-volume drafting and classification. It's rare that a vendor's framing and a user's experience line up this cleanly, so I'll say plainly that mine does.

The inverse is equally true and gets less attention. On tasks where the cheap model succeeds first time — and that is most tasks — every rupee spent on the expensive model is waste. Running Opus 5 to add a prop to a component is not diligence, it's a habit you haven't examined.

So the operational rule is simple: start on the cheaper model, and escalate the moment you notice you're re-prompting rather than reviewing. The second re-prompt is the signal. Not the third, not the fifth — by then you've spent the difference twice over.

This is the table taped to the inside of my head. Find your task on the left; the model is on the right.

Most of the decision collapses into this one comparison, so it deserves its own section.

The price relationship is clean: Opus 5 at $5/$25 is roughly 2.5x Sonnet 5's $2/$10 — and with the 5.5 generation, Opus 5.5 at $4/$20 is 2x Sonnet 5.5. Note how small that gap is, because it matters for anyone budgeting past August — the gap between default and escalation is about to shrink by a third, which makes escalating cheaper in relative terms than it is today.

Capability-wise, both carry 1M-token context and up to 128K output, so this is not a context-window decision. It's a reasoning-depth decision. What I notice in daily use is that Sonnet 5 is excellent at executing a plan and Opus 5 is better at making one. Give Sonnet a well-scoped instruction and it lands cleanly and fast; give it an underspecified problem across six files and it will produce something plausible that misses a constraint you didn't state. Opus is markedly better at the 'what am I actually being asked to do here' phase — which is why the most cost-effective pattern I've landed on is a split, not a choice.

The split: plan on Opus, execute on Sonnet. Use Opus 5 for the architectural pass — have it read the relevant modules and produce the plan, the file list, the sequence, the risks. Then switch to Sonnet 5 to carry out the steps. You pay the premium on the small, dense reasoning portion of the work and the cheap rate on the large, verbose execution portion. On the API this is straightforward. Inside Claude Code it's a `/model` switch between plan mode and execution, and it's the single biggest cost lever I've found that doesn't involve accepting worse output.

One migration note if you're moving from Opus 4.8: Opus 5 sits in its own rate-limit bucket. Opus 4.5 through 4.8 share a combined pool that Opus 5 does not draw from, so shifting traffic across doesn't free headroom in the old pool. There's also a behavioural change worth testing before you swap in production — on 4.8, a request omitting the thinking field ran without thinking; on Opus 5 the same request behaves differently. Run your existing prompts against it before assuming a drop-in swap.

The two ends of the range get dismissed too quickly in most guides — one as too weak to bother with, the other as the obvious premium choice. Both dismissals are wrong.

Haiku 4.5 is the most underused model in the lineup for developers. At $1/$5 it costs half of Sonnet's rate and a fifth of Opus (and Haiku 5.5, released October 7, 2026, cuts that to $0.10/$0.50), and for genuinely mechanical work the quality difference is invisible because the task has no room for judgement. Adding TypeScript prop types across a directory. Generating test scaffolding from a component signature. Parsing a log file into a table. Writing commit messages from a diff. Converting a JSON fixture set into another shape. These are tasks where the specification is the whole problem, and once the specification is clear, model reasoning depth stops mattering. The rule I apply: if I could write a regex for it given an hour, Haiku can do it in a second, and paying Opus rates for it is a small ongoing tax on inattention.

Where Haiku is genuinely wrong: anywhere a mistake is expensive to detect. Silent logic errors in business rules, anything touching money or permissions, anything where 'looks right' and 'is right' diverge. The cheap model's failure mode isn't refusing — it's confidently producing something plausible.

Fable 5 has the opposite problem: it's easy to reach for because it's the frontier tier, and usually unnecessary. At $10/$50 it's twice Opus 5's rate, and Anthropic's own framing for the Opus 5 launch was that it approaches Fable's performance at half the price. That's a vendor telling you not to buy the expensive thing, which is worth taking seriously. Fable also carries conservative safeguards: queries on some sensitive topics receive a response from Opus 5 instead, triggering in under 5% of sessions on average by Anthropic's account. For coding that's mostly irrelevant, but on long autonomous runs it does mean the model handling your session isn't guaranteed to be the one you selected — a wrinkle worth knowing about before you build a benchmark around it.

My honest position: I've used Fable 5 on real work and I keep struggling to construct a coding task that justifies it over Opus 5 since July 24. That may say more about my workload than the model. If yours involves genuinely frontier agentic autonomy, test it — and if you find the task where the gap is real and reproducible, I'd like to hear about it in the comments, because I haven't found mine.

Everything above prices models in API terms, because that's the only place the arithmetic is visible. Inside Claude Code on a subscription, the meter is different in ways that change the decision.

On a Pro or Max plan you are not paying per token — you're drawing against a usage budget shared across Claude Code, Claude chat and Cowork. Burn tokens in one and you lose capacity in the others. Anthropic governs that budget with two clocks: a rolling five-hour window that starts on your first message rather than on a fixed schedule, and a weekly cap on top of it. Max plans carry two weekly caps — one across all models, and a separate one for Sonnet specifically.

That last detail is the one people miss, and it inverts part of the advice above. On Max, heavy Sonnet use draws against a dedicated Sonnet allowance rather than competing with your Opus headroom. Running everything on Opus because you can doesn't just cost more capability-per-task than you need — it burns the shared pool that your harder work depends on, while a separate Sonnet budget sits unused. Opus 5 being the default model on Max makes this easy to do by accident.

Practically, inside Claude Code: switch with `/model`, plan on Opus, execute on Sonnet, and treat the five-hour window as a resource you're allocating rather than a limit you bump into. When you do hit a ceiling, every paid consumer plan now has an extra-usage toggle that continues at standard API rates with a monthly spend cap you set — which means the per-token pricing in this article stops being theoretical the moment your subscription budget runs out. That's the point where model choice becomes a direct bill again, and where per-token rates show up on your card.

Most articles in this category test models. I'm going to do something less tidy and more useful: tell you which models built a system that is currently taking real money from real customers, and where that ladder turned out to be wrong.

The build. MumsStitch is a women's fashion ecommerce site I own and operate — Next.js frontend, Express backend, PostgreSQL, deployed on DigitalOcean behind Nginx with PM2. I built the backend, a payment gateway integration, an SMTP service, S3 image storage and a shipping API integration. Separately I built a functional CRM, and I took over a client backend another developer had built.

Fable 5 handled planning, the backend, and the payment gateway. The heaviest work went to the heaviest model, at $10/$50 per million tokens. On architecture decisions and payment code specifically, a wrong answer is expensive and hard to detect, so I bought the most capable tier available at the time rather than optimising cost. The gateway has run correctly in production since launch.

Two precisions, because payment code is where readers should hold me to a higher standard. I read the code and tested every scenario I could construct, repeatedly, before go-live. And I didn't treat my own review as sufficient — the brand's CEO independently tested the payment flows before we shipped. AI-generated, developer-reviewed, client-verified. That's a different claim from 'it works in production'.

Opus 4.8 handled medium-weight work and the hardest debugging. The standout came from the client backend I inherited: built with Claude by another developer, its Swagger documentation was broken and wouldn't update even after repeated redeploys — the kind of bug that looks like a deployment problem and isn't. Opus 4.8 found it. Reasoning-shaped problem, not typing-shaped, which is exactly the profile where escalating pays. It also did the frontend analysis work: PageSpeed Insights remediation and technical SEO fixes.

That story carries the uncomfortable lesson of this article. The same tool that built my payment gateway correctly built a backend with broken documentation that shipped unnoticed. The difference wasn't the model. It was whether anyone reviewed the output.

Then Opus 5 launched, and the ladder moved. After July 24 I gave it the offer and discount logic for MumsStitch — running in its higher-reasoning mode, spanning both backend and frontend, touching pricing rules, cart behaviour and display. That is a full-stack feature of genuinely Fable-5 weight, and it landed. It's been working correctly since. I also used it for bulk product SEO metadata across the catalogue and for a vulnerability review pass.

So the finding this article exists to report: the ladder shifts down a tier. I paid $10/$50 for work that Opus 5 subsequently handled at $5/$25, because Opus 5 didn't exist when I built it. If you're standing where I was in June, you almost certainly don't need to start at the frontier tier — Anthropic's near-Fable-performance-at-half-price positioning matched my experience, which is a sentence I write rarely.

The limit on that finding, stated plainly: offer logic is not a payment integration. It's complex, full-stack and money-adjacent, but the failure mode of a mispriced discount is recoverable in a way that a broken payment flow isn't. I have not put Opus 5 on a payment gateway, so I won't tell you it's proven there. What I'll say is that on the hardest non-payment work I've given it, it did not feel like a step down from Fable 5.

Sonnet 5 did content and SEO prose, not application code. I'm flagging that deliberately: I recommend Sonnet 5 as a scoped-execution default on the strength of its positioning and my lighter use of it, not on production application code I built with it.

Limits on all of this. One developer, one stack — TypeScript, React, Node, Postgres — on codebases I know well. These are shipped outcomes, not controlled trials: I picked a model per task and lived with it rather than running the same task three ways. Treat it as one practitioner's ladder rather than a ranking.

Four pieces of fine print separate a working answer from a stale one.

First, a correction to my own August warning. When I published this, Sonnet 5's $2/$10 rate was introductory, with standard $3/$15 pricing due September 1. That increase was cancelled: $2/$10 is now Sonnet 5's standard price. Then the lineup moved again. Claude Opus 5.5 launched September 22, 2026 at $4/$20 (cheaper than Opus 5's $5/$25), Sonnet 5.5 followed on September 28 at $2/$10, and Haiku 5.5 arrived October 7 at $0.10/$0.50 for prompts up to 100K tokens ($0.50/$2.50 above that). Both Opus 5.5 and Sonnet 5.5 also price cache hits at 5% of base input instead of the usual 10%, which matters for agentic coding where cache reads dominate. The decision framework below doesn't change. Each rung just has a newer, cheaper model on it.

Second, the rate-limit bucket structure. Opus 5 does not share a pool with Opus 4.5 through 4.8. If you're running production traffic on 4.8 and planning a migration, moving requests to Opus 5 gives you fresh headroom rather than reallocating existing headroom — helpful, but it also means you can't test-migrate a slice of traffic and expect the old pool to loosen.

Third, the discounts that outperform model-switching. Prompt caching discounts cache hits to roughly 10% of standard input cost, and for agentic coding — where the same repository context is re-read on every single turn — cache reads dominate token volume. One report of heavy Claude Code usage found over 90% of tokens in large-project sessions were cache reads. Before you downgrade a model to save money, check whether you're caching. The Batch API's 50% cut applies to anything that can tolerate a delay: overnight refactors, bulk documentation passes, test generation across a repo.

Fourth, the standing caveat on all of this. Between June 9 and July 24, 2026, the lineup gained two models, briefly lost two to export controls, regained them, and then gained a new flagship. That is four material changes in seven weeks. Any article recommending a specific Claude model — including this one — has a shelf life measured in weeks, not years. The framework should outlast the names; verify the names before you act on them.