Claude Opus 5 vs Sonnet 5: Which to Build On 2026

The founder's guide to choosing the Claude model your product runs on, without overpaying or under-building.

In under two months in mid-2026, Anthropic shipped four Claude 5 models, and two of them, Claude Sonnet 5 and Claude Opus 5, are the ones most founders will actually build on. Claude Sonnet 5 landed June 30, 2026 as "the most agentic Sonnet model yet" - Anthropic. Claude Opus 5 followed on July 24, 2026, pitched as coming "close to the frontier intelligence of Claude Fable 5 at half the price" - Anthropic.

But here is the problem: the two models are much closer than their tier names suggest, and picking wrong costs you money in one direction or reliability in the other. Sonnet 5 is cheaper and, on many real product jobs, nearly as good. Opus 5 is stronger on the hardest work but carries a premium and a thinking-on-by-default meter that quietly runs up your bill. Most guides treat this as a benchmark beauty contest. It is not. For a founder, the question is not "which model is smarter" but "which model delivers the outcome my product sells, at the lowest cost per success."

This guide answers that from first principles. It breaks down exactly what each model is, the real benchmark and pricing data (with the caveats the marketing pages leave out), the dollar math on realistic workloads, and a decision framework you can apply to your own product. It also covers why the smartest answer is often not to pick one model at all, but to route between them. We will get specific about pricing, effort levels, caching, tokenizers, and the routing patterns production teams already use. Where the data is contested, we say so.

Contents

1. The real question is not "which is better," it is "which to build on"
2. The 2026 Claude ladder at a glance
3. Claude Sonnet 5: the workhorse most products should start on
4. Claude Opus 5: the frontier, at half the frontier price
5. Head to head: where they diverge, and where they draw
6. The economics: what each model actually costs to run
7. The decision framework: which model for which product surface
8. Do not pick one, route: the three-tier pattern
9. The competitive context: GPT-5.6 Sol, Gemini 3.1 Pro, and open weights
10. How founders actually build on this in 2026
11. Failure modes, limits, and the fine print
12. The 2026 outlook: cadence, price compression, and agents
13. Conclusion: a decision framework you can act on

1. The real question is not "which is better," it is "which to build on"

Start with the structural question, because it changes every answer downstream. When a founder buys a model to build a product on, they are not buying intelligence in the abstract. They are buying outcomes: a support ticket resolved, a pull request merged, a document summarized correctly, a multi-step task completed without a human babysitting it. Intelligence is the input. The outcome is the product. And in 2026, raw intelligence has become cheap and abundant enough that the input is rarely the binding constraint. The binding constraint is cost per successful outcome across the specific mix of jobs your product runs all day.

That reframing matters because it inverts the usual instinct. The instinct is to reach for the most capable model and feel safe. But the most capable model is only the right default when the marginal cost of a wrong answer is high and the volume is low. Flip either of those, high volume or cheap-to-catch errors, and a smaller model that is 90 percent as good at a third of the price wins on the only metric that reaches your P&L. This is why the honest version of the Opus-versus-Sonnet decision is almost never a single verdict. It is a portfolio decision, and the portfolio is defined by your workload, not by a leaderboard.

Consider what actually varies between two products that both "use an LLM." A high-volume classification feature might fire 100,000 times a day on short prompts where a mistake is caught by a downstream rule. A long-horizon coding agent might fire a few hundred times a day on enormous prompts where a mistake wastes an hour of autonomous work and produces subtly broken code. These two products should not run on the same model, even inside the same company. The first wants the cheapest model that clears a quality bar. The second wants the most reliable model you can afford, because reliability is the product.

• Cost per successful outcome beats price per token as the metric that matters
• Volume and error-cost determine whether cheaper-but-weaker wins or loses
• Your workload mix is the real input, not a single benchmark number
• The default answer is a portfolio, not one model for everything

The practical implication is that you should resist any guide (including the loudest parts of this one) that hands you a single winner. What you want instead is a map: which model fits which kind of job, what each costs when you run it at your volume, and how to combine them. We build that map across the next twelve sections. If you are earlier in the journey and still deciding what to build at all, our companion piece on how to build an app with AI sets the wider context; this guide zooms into the single decision of which engine sits underneath it.

2. The 2026 Claude ladder at a glance

Before comparing two models, it helps to see the whole ladder they sit on, because the tier above and below each one shapes when it is the right choice. As of August 2026, Anthropic's lineup runs from Claude Haiku 4.5 at the cheap end through Claude Sonnet 5 and Claude Opus 5 in the middle to Claude Fable 5 at the frontier - Anthropic pricing. Haiku 4.5 costs $1 per million input tokens and $5 per million output. Fable 5 sits at $10 and $50. The two models this guide is about fall neatly between them, and their pricing is the first clue to how Anthropic wants you to use them.

The key structural fact is that Opus 5 costs exactly half of Fable 5, at $5 input and $25 output per million tokens - Anthropic. That is not a rounding coincidence; it is the entire pitch. Anthropic's own framing is that Opus 5 delivers near-Fable-5 capability at half the sticker, which is why Opus 5 became the default model on Claude Max and the strongest option on Claude Pro - Fortune. Sonnet 5, meanwhile, launched at an introductory $2 input and $10 output per million and became the default for Claude Free and Pro users - TechCrunch. Both carry a 1 million token context window and up to 128,000 tokens of output per request.

Anthropic's own summary chart for Opus 5, below, places the model against prior Claude releases and the field, and it is the fastest way to read where the top of the ladder sits before we score the tiers ourselves.

The assessment table below scores the models a founder would realistically weigh as a build target, including the leading cross-vendor flagship (OpenAI's GPT-5.6 Sol) for honest context. It is scored on four criteria that matter when you are shipping a product, not sitting an exam. Each cell carries the score and the data behind it, and the table is ordered by final weighted score, highest first.

Criteria explained: Cost to Run (30%) weighs sticker price, effective cost per task, and cost-control levers. Coding & Agentic (30%) weighs the benchmarks most product builds depend on (SWE-bench family, Terminal-bench, CursorBench, tool use). Long-Horizon Reliability (20%) weighs frontier reasoning and multi-step autonomy (Artificial Analysis Intelligence Index, Frontier-Bench, ARC-AGI-3). Build Ergonomics (20%) weighs context window, effort control, exclusive features, and how cleanly the model drops into a real stack.

Read the table carefully and one thing jumps out: Opus 5 tops it, but the gap to Sonnet 5 is small (8.9 versus 8.1), and that gap is almost entirely reasoning-and-reliability, not price. The table ranks by weighted capability plus cost, where the strongest model wins. The rest of this guide argues something more useful: that for most founder workloads, the pragmatic default is the second-place model, and the first-place model earns its keep only on the hard minority of jobs. Notice too that GPT-5.6 Sol outranks Fable 5 here, a reminder that Fable 5's frontier premium is a hard sell for product builds when Opus 5 matches it at half the cost. For a broader survey of build targets beyond Claude, our guide to the best AI model to build your app covers the wider field.

3. Claude Sonnet 5: the workhorse most products should start on

Claude Sonnet 5 is the model Anthropic built for the boring, high-volume, in-the-loop work that actually makes up most of a product. Its own launch framing is telling: it is "built to be the most agentic Sonnet model yet," capable of making plans, using browsers and terminals, and running autonomously - Anthropic. That is a deliberate shift. Earlier Sonnet models were positioned as fast and cheap; Sonnet 5 is positioned as fast, cheap, and agentic, which is exactly the combination a founder needs for a coding assistant, a support agent, or a document pipeline that has to run thousands of times a day.

The reason Sonnet 5 matters so much is that it closed most of the gap to the previous flagship. On the coding and computer-use benchmarks that predict real product behavior, Sonnet 5 lands within a few points of Claude Opus 4.8, the model that was Anthropic's top Opus only weeks earlier. Independent reviewers put it at 63.2 percent on SWE-bench Pro against Opus 4.8's 69.2 percent, and 80.4 percent on Terminal-bench 2.1 where Opus 4.8 scored 74.6 percent - ClaudeFast. On the knowledge-work benchmark GDPval-AA v2 it actually edges Opus 4.8, 1,618 to 1,615 - Vellum. Read those numbers as a founder, not a researcher: Sonnet 5 is roughly a previous-generation flagship, at a Sonnet price.

The image below is Anthropic's own benchmark table for Sonnet 5, comparing it against Sonnet 4.6 and Opus 4.8 across the evaluations that map to agentic product work. It is worth studying because it shows the shape of the improvement, not just a single headline number.

Where Sonnet 5 pulls its weight is the everyday middle of your product. It is the model teams reach for when they are in the loop: writing code interactively, answering support questions, classifying and extracting at volume, and running the shorter agentic loops that dominate real usage. Named production users make the point concrete. Zapier reported that Sonnet 5 "finished end to end" on multi-step automation tasks that used to stall halfway - TechCrunch. Lovable, GitHub, ClickHouse, Salesforce partners, and the insurance startup Pace were all cited shipping on it at launch. When companies whose entire product is an AI agent standardize on Sonnet, that is a strong signal about where the price-performance sweet spot sits.

The deeper reason Sonnet 5 is the right default for in-the-loop work is a point about error economics, not raw capability. When a human reviews each step, the cost of a model's occasional miss collapses, because the reviewer catches it before it reaches production. In that regime the rational move is to buy the cheapest model that clears your quality bar and spend the saved money on more calls, faster iteration, or a bigger free tier. The moment you would pay a 1.67x premium to shave a few percentage points off an error rate that a human is already catching for free, you have mispriced the decision. This is why enterprises evaluating models on real work keep landing on Sonnet-class engines for the bulk of their volume: Box, for instance, benchmarked Sonnet on deep reasoning over real enterprise documents and found the newer Sonnet outperformed its predecessor on heavy reasoning Q&A by a wide margin - FourWeekMBA. The lesson generalizes: for supervised, high-volume, recoverable work, competent-and-cheap beats brilliant-and-expensive almost every time.

There are two caveats a founder should log before defaulting to it. First, Sonnet 5 ships with a new tokenizer that maps the same text to roughly 1.0 to 1.35 times more tokens than Sonnet 4.6, which changes your effective cost in ways the sticker price hides - Anthropic. Second, its cybersecurity capability is deliberately weaker than Opus 4.8, which is a feature for safety but a limit if your product genuinely needs offensive-security reasoning. Neither is a dealbreaker for the vast majority of products, but both belong in your model of the model. If your build is specifically a website or web app, the deeper dive in Claude Sonnet 5 for building websites walks through exactly how it performs on that surface.

4. Claude Opus 5: the frontier, at half the frontier price

Claude Opus 5 is the more interesting release, because its story is not really about being smarter than Opus 4.8. It is about repricing the frontier. Anthropic held the Opus price flat at $5 and $25 per million tokens, the same as Opus 4.8, while pushing capability up toward Claude Fable 5, its most capable widely released model - Axios. Since Fable 5 costs $10 and $50, the headline is that you can now get within touching distance of the best model Anthropic ships, for half the money. For a founder deciding whether frontier-grade reasoning is affordable inside their product, that is the single most consequential fact of the summer.

The benchmarks back the framing, though they require reading with care. On Artificial Analysis's aggregate Intelligence Index, Opus 5 at max effort scored 61, first place, edging Fable 5 at 60, GPT-5.6 Sol at 59, and Opus 4.8 at 56, while costing meaningfully less per task than Fable 5 - Artificial Analysis. Anthropic's own launch materials leaned on newer evaluations: Opus 5 more than doubles Opus 4.8 on Frontier-Bench, lands within 0.5 percent of Fable 5 on CursorBench at half the cost, and scores roughly three times the next-best model on ARC-AGI-3 - Anthropic. On independent SWE-bench Verified runs it sits at the top of the public leaderboard around 96 to 97 percent - vals.ai. We will return to why that last number needs an asterisk in Section 5.

Anthropic's CursorBench chart below is the cleanest illustration of the pitch: Opus 5 matching the top tier on agentic coding while sitting at half the price point. Agentic coding is the workload most founders building developer tools or autonomous agents care about most, which is why this specific comparison is the one to internalize.

Opus 5 also ships two things Sonnet 5 does not, and both are levers a serious builder will use. The first is a user-facing effort toggle, published as low, medium, and high (the full API ladder runs low, medium, high, xhigh, and max), letting you trade cost against capability per request - Fortune. The second is a fast mode priced at $10 and $50 per million, roughly 2.5 times the default output speed for double the base price, available on the first-party API only - Codersera. There is one behavioral subtlety that trips up teams migrating from Opus 4.8: on Opus 5, extended thinking is on by default, so reasoning tokens are billed as output whether or not you asked for them. That default is why the effort ladder is your primary cost control, not an optional flourish, a point we develop in the economics section.

It is worth understanding the effort ladder as a genuine cost dial, because it is the mechanism that lets one model serve both cheap and expensive work. Dropping from max to low effort can cut output-token spend by roughly two-thirds on a given task, so a lint fix or a short summary run at low effort costs a fraction of the same call at high effort, while a hard reasoning problem run at xhigh or max spends the tokens it needs to get the answer right - Codersera. The recommended posture is to start at high, not max, and to route roughly 80 percent of traffic through low or medium effort while escalating only the hard minority. Anthropic's own guidance for this generation is that reaching reflexively for max is usually a mistake, because the intelligence ceiling is high enough that lower effort clears most bars at a large token saving. Treat effort as the first thing you tune on any Opus 5 workload, before you even reach for a second model.

The capability that most justifies Opus 5's premium is self-verification on long runs. On a multi-hour autonomous job, a weaker model tends to declare victory prematurely or drift subtly off course, and because no human is watching, the error compounds until you discover it hours later in the output. Opus 5 verifies its own work as it goes, which is why it can carry, in Anthropic's framing, challenging pull requests all the way to tested, verified results without a human checking in partway through - Anthropic. For a founder, the value here is not abstract intelligence; it is the reduction in failed autonomous runs, each of which wastes compute and produces work you then have to detect and redo. When that failure cost is high and hard to catch, the reliability is the product.

The best summary of Opus 5's positioning is that it is the first Opus release written for the people running agent fleets in production, not for chat. Its self-verification behavior lets it run long autonomous jobs without a human checking in partway through, which is precisely the capability that lowers cost per successful task on multi-step work - DigitalApplied. If your product is a long-horizon autonomous agent, or you are assembling an AI-native company tech stack where agents do real operational work, Opus 5 is the model that makes frontier reliability affordable. The rest of this guide is about knowing when that reliability is worth the premium.

5. Head to head: where they diverge, and where they draw

Now put the two models on the same table and reason about the shape of the difference, because the shape is more useful than any single score. The pattern that emerges from every serious comparison is consistent: Sonnet 5 and Opus 5 draw on the middle of the distribution and diverge at the tails. On the ordinary, well-scoped jobs that make up most of a product, Sonnet 5 matches Opus 5 closely enough that the price difference decides it. On the hardest, longest, most ambiguous jobs, Opus 5 pulls clearly ahead. The engineering skill is knowing which tail your task lives in.

The benchmark data tells this story cleanly if you stop looking for a single winner. On aggregate reasoning, Opus 5 leads Sonnet 5 by roughly 6 to 8 points on the Intelligence Index (61 versus 53 to 55), a real and meaningful gap on frontier reasoning, long-horizon planning, and novel-problem solving - Artificial Analysis. But on agentic coding and computer use, where Sonnet 5 posts SWE-bench Pro of 63.2 and Terminal-bench 2.1 of 80.4, the two are close enough that on many real jobs Sonnet fights the flagship to a draw at roughly 40 percent of the cost. One independent head-to-head across sixteen real jobs found Sonnet 5 sweeping the two "build product" personas at a fraction of Opus's price - Sid Saladi. That draw on product-building work, not the reasoning gap, is the finding most founders should act on.

Here is a subtlety that separates careful analysis from benchmark theater. Anthropic dropped SWE-bench Verified from its launch materials for the Claude 5 generation, headlining Frontier-Bench, CursorBench, ARC-AGI-3, and OSWorld instead - Anthropic. Every SWE-bench Verified number you see for these models is third-party, and the third parties disagree. Opus 5 is reported at 96 to 97 percent depending on the run - Eden AI. Sonnet 5's Verified figure is genuinely contested, with blogs citing 82, 85, and even 92 percent, and the 85 number almost certainly a confusion with its Aider Polyglot score - llm-stats. The disciplined move is to lean on the metrics that are consistently reported (SWE-bench Pro and Terminal-bench) and treat any single Verified number as directional. This is the hype filter in action: when a stat varies wildly across sources, it is telling you the stat is noisy, not that one blog found the truth.

The clearest way to see the "draw in the middle" is the grouped comparison below of Sonnet 5 against the model it effectively replaced at the top, Opus 4.8, on three agentic benchmarks. Sonnet 5 matches or beats a former flagship on two of the three, which is the entire reason it can be a default.

Where Opus 5 refuses to draw is the long tail. On ARC-AGI-3 it scores roughly three times the next-best model, on Frontier-Bench it more than doubles Opus 4.8, and its self-verification lets it sustain multi-hour autonomous runs that a cheaper model gives up on or gets subtly wrong - DigitalApplied. It also has exclusive features that matter for complex agents: fast mode for latency-sensitive interactive work and mid-conversation system messages for injecting operator context without breaking the prompt cache, neither of which Sonnet 5 supports. So the head-to-head resolves not to a winner but to a boundary: draw in the everyday middle, Opus 5 wins the hard, long, novel, or correctness-critical tail. The next two sections turn that boundary into money and then into a decision rule. For the tier above both, where multi-day autonomy lives, our guide to Claude Fable 5 for coding and company building picks up the thread.

6. The economics: what each model actually costs to run

Now make it concrete, because the entire Opus-versus-Sonnet decision is really an economics decision wearing a capability costume. The foundational fact is that Anthropic prices its models on a flat 1-to-5 input-to-output ratio across every tier, which means the cost multiple between two models does not shift with your workload mix - Anthropic pricing. Opus 5 is exactly 1.67 times Sonnet 5's standard price, and 2.5 times its introductory price, no matter whether your prompts are input-heavy or output-heavy. That regularity is a gift: it means you can reason about the price gap once and apply it everywhere.

The raw ladder is easiest to see as a chart. Input and output prices scale together, so the visual gap between tiers is the gap you pay at any volume.

Turn the ratios into a real feature and the stakes get vivid. Take a support or chat feature running 2,000 input tokens plus 500 output tokens per call, across 100,000 calls a month. That is 200 million input and 50 million output tokens. On Opus 5 it costs $2,250 a month. On Sonnet 5 at standard pricing it is $1,350, on the introductory rate $900, and on Haiku 4.5 just $450 - Anthropic pricing. The same feature, the same traffic, and a 5x spread from top to bottom of the ladder. If your support answers are caught and corrected by a human or a rule, paying Opus prices for them is simply lighting money on fire. If they go straight to a customer and a wrong answer costs you a churned account, the calculus flips.

Now run the other end of the workload spectrum, because the chat example understates the stakes for agent-heavy products. Take a coding-agent task at 50,000 input plus 10,000 output tokens per run, a realistic shape when the agent reads a chunk of a repository and writes a change. That run costs $0.50 on Opus 5, $0.30 on Sonnet 5 standard, $0.20 on the introductory rate, and $0.10 on Haiku 4.5 - Anthropic pricing. Individually these look trivial, which is exactly the trap. At 10,000 runs a month, the same task becomes $5,000 on Opus 5 versus $3,000 on Sonnet 5, a $2,000 monthly gap on a single feature. Multiply by the several agentic surfaces a real product runs and the model choice moves from a rounding error to a line item that shows up in your burn rate. The per-call intuition is misleading; you have to reason at monthly volume to see the decision honestly.

It also helps to remember that you are not buying a fixed price; you are buying a point on a cost-performance curve, and the effort level moves you along it. Anthropic's own cost-versus-performance plot for Sonnet 5 on agentic search, below, shows the shape directly: spending more (higher effort, more tokens) buys more accuracy, with diminishing returns at the top. The practical consequence is that the "price" of a model is really a range, and where you sit in that range is a decision you make per workload, not a fixed number the rate card hands you.

There are three levers that bend these numbers hard, and every serious builder pulls all three. The first is prompt caching: cached input reads cost roughly a tenth of the base rate, so any large fixed context you re-send every turn bills at 90 percent off after the first call, and Opus 5 lowered its minimum cacheable prefix to 512 tokens where Sonnet 5's is 1,024 - eesel AI. The second is the Batch API, a flat 50 percent discount on both input and output for asynchronous jobs returned within 24 hours, which stacks with caching to bill some workloads at around 5 percent of the rate card - CodeWords. The third is effort control: because thinking is on by default on both models, running routine work at low or medium effort caps reasoning-token spend that would otherwise silently inflate every bill.

• Prompt caching cuts re-sent context to about 10 percent of the base rate
• Batch API takes a flat 50 percent off async, non-time-sensitive jobs
• Effort levels cap the thinking tokens that thinking-on-by-default would otherwise bill
• Model routing sends cheap work to cheap models (covered in Section 8)

The caching lever is not theoretical. One developer documented cutting a monthly bill from $720 to $72, a 90 percent reduction, purely by caching about 81,000 tokens of stable context that had been re-billed on every request - Du'An Lightfoot. The arithmetic is stark when you localize it to a single agent turn. Suppose your agent re-sends a 45,000-token stable prefix (system prompt, tool definitions, retrieved documents) on every step. At Opus 5's input rate that slice costs about $0.225 per turn uncached; cached, it reads at roughly a tenth of that, about $0.0225 per turn, after a one-time write. Across a long agentic session with dozens of turns, that is the difference between the fixed context dominating your bill and it nearly vanishing. For any agent that re-sends a large system prompt and tool set every turn, this is the single highest-leverage optimization available, and it applies identically to Opus 5 and Sonnet 5. The practical takeaway is that the sticker-price gap between the two models is real but often swamped by whether you have engineered caching and batching correctly. A founder who has not is overpaying on both models before the model choice even matters. Our deeper treatment of what it costs to build an app with AI puts these API bills in the context of the whole build budget.

6.1 The tokenizer trap that hides in Sonnet 5's price

There is one cost subtlety specific to this generation that catches teams off guard, and it deserves its own treatment because it can quietly undo the savings you thought you were getting. Sonnet 5 and Opus 5 both use a new tokenizer that emits roughly 30 percent more tokens for the same text than the previous generation, with the inflation heaviest on English prose (around 1.4x) and code (around 1.27x for Python) and lightest on languages like Mandarin (roughly unchanged) - Anthropic. Because Opus 5 and Sonnet 5 share the same tokenizer, the effect cancels out when you compare the two to each other. It bites when you compare either one to the model it replaced.

The consequence is counterintuitive: the same text can cost more on Sonnet 5 than on Sonnet 4.6 even though the per-token sticker price is identical or lower. One worked analysis showed a Sonnet 4.6 workload of about $675 a month rising to $810 to $911 on Sonnet 5 at standard pricing once tokenizer inflation compounds, a 20 to 35 percent effective increase despite an unchanged rate card - Finout. During the introductory pricing window the lower rate offsets it; after the window it does not. The lesson for a founder is procedural, not just numerical: do not budget from the rate card alone. Replay a representative sample of your real traffic through the token-counting endpoint on the exact model you plan to ship, and budget from the measured token counts. The rate card tells you the price per token; only your own traffic tells you how many tokens you will actually spend.

There is a routing implication hiding in this too. Haiku 4.5 still uses the older, leaner tokenizer, so sending eligible work to Haiku wins twice: a lower per-token rate and fewer tokens for the same text. That compounding is part of why the routing patterns in Section 8 are so effective, and why the cheapest tier is worth more in your architecture than its raw price suggests. If cost control is your dominant concern, our dedicated guide to cutting AI agent costs with model routing goes deeper than we can here.

7. The decision framework: which model for which product surface

With the capability boundary and the cost math in hand, we can build the actual decision rule, and it is refreshingly concrete once you stop thinking in terms of "better." The organizing principle, drawn from how production teams actually choose, is to map product surfaces to models rather than picking one model for the whole product. Sonnet 5 is the default for the surfaces that are high-volume, latency-sensitive, or human-in-the-loop. Opus 5 is the escalation for the surfaces that are long-horizon, autonomous, ambiguous, or correctness-critical - DataCamp. The word "surface" matters: a single product usually has several, and they do not all want the same engine.

Walk through the common surfaces from first principles. A chat or support assistant is high-volume, latency-sensitive, and usually recoverable if it errs, so it wants Sonnet 5 (or Haiku 4.5 for the simplest tiers). Retrieval-augmented generation and high-volume classification are the same story: bounded tasks, huge call counts, Sonnet 5 at 1.67x cheaper input than Opus and cache reads at $0.30 per million versus Opus's $0.50 - Coursiv. In-the-loop coding, where a developer reviews each step, is Sonnet's home turf and the reason it is the default model in Claude Code. The pattern is that when a human or a cheap downstream check catches mistakes, you should buy the cheaper competent model and pocket the difference.

Opus 5 earns its premium on a different class of surface. Long-horizon autonomous agents that run for many steps with no human checking in are where Opus 5's self-verification and reliability translate directly into fewer failed runs, and a failed autonomous run is expensive because it wastes compute and produces work you have to detect and redo - FullStack. Deep multi-file or multi-repo refactors, ambiguous or novel research, and any task where a wrong answer is costly and hard to catch all belong to Opus 5. The unifying property is not difficulty in the abstract; it is that the cost of a subtle error is high and the error is hard to catch cheaply. That is the exact condition under which paying 1.67x for higher reliability is rational.

The decision diagram below captures the routing logic as a flow you can implement. It is not a rigid switch statement; it is a way of reasoning about which properties of a task push it up or down the ladder.

The honest caveat is that this framework is a starting point, not gospel, and the only way to finalize it is to test on your own data. Every serious comparison converges on the same discipline: benchmark 50 to 100 representative examples from your actual product, compare both quality and total cost, and let your workload decide - NxCode. Public benchmarks predict the direction of the answer; only your traffic gives you the magnitude. If your product is a support agent specifically, we walk through the build end to end in build a support agent for your site, including where the Sonnet-versus-Opus line falls for that surface.

8. Do not pick one, route: the three-tier pattern

Here is the move that separates teams who have shipped agents in production from teams who are still arguing about which model is best: they stopped picking one. The dominant architecture in 2026 is not "choose Opus or Sonnet," it is three-tier routing, where different steps of the same workflow run on different models. The canonical mapping is Opus for planning and orchestration, Sonnet for implementation and generation, and Haiku for retrieval, file navigation, and other cheap mechanical steps - Augment Code. This is not a compromise between the two models; it is a strictly better architecture than committing to either.

The economics are decisive. Because 60 to 80 percent of the calls in a typical coding agent are routine (grep this, read that, apply this edit), routing those calls to Haiku and Sonnet while reserving Opus for the hard planning steps cuts the blended cost dramatically. One documented coding session dropped from about $2.02 on Opus-only to about $0.98 with three-tier routing, a 51 percent reduction, with no loss in output quality on the tasks that mattered - Augment Code. Broader studies of model routing report savings in the 40 to 85 percent range, with one hitting 85 percent while retaining 95 percent of output quality - Morph. The reason is simple arithmetic: your blended cost is the weighted average of your models, and if most of the weight sits on the cheap tiers, the expensive tier barely moves the total.

The pipeline is easiest to picture as a flow, where the expensive model touches the fewest tokens.

Implementing this is more accessible than it sounds, because the tooling already exists. In Claude Code you set the model per slot through environment variables and the /model command, and you can point every slot at a gateway - Morph. A minimal configuration that routes Claude Code through a gateway looks like this:

# Point Claude Code at a routing gateway, then map each slot to a model
export ANTHROPIC_BASE_URL="https://your-gateway.example.com"
export ANTHROPIC_AUTH_TOKEN="your-gateway-key"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="claude-haiku-4-5"
export ANTHROPIC_DEFAULT_SONNET_MODEL="claude-sonnet-5"
export ANTHROPIC_DEFAULT_OPUS_MODEL="claude-opus-5"

Beyond Claude Code, gateways like LiteLLM and OpenRouter proxy requests and can route by rules or automatically, and agent frameworks like the Claude Agent SDK and LangGraph let you select a model per step in code - LiteLLM. Two routing styles are worth distinguishing, because they suit different products. Static routing hard-wires each step of a fixed pipeline to a model (a Coordinator on Opus 5, an Implementor on Sonnet 5, a Reviewer on Sonnet 5), which is simple, predictable, and ideal when your workflow shape is stable. Dynamic routing classifies each request by difficulty at runtime and picks a model on the fly, which extracts more savings but adds a classification step of its own; the overhead only pays for itself above roughly 500 calls a day, below which the added complexity is not worth it - Augment Code. A pragmatic middle path is the escalation ladder: run a step on the cheap tier, and if it fails twice, retry one tier up with the failure report attached, so most work stays cheap and only the genuinely hard calls climb the ladder. The one discipline that governs all of it is the metric we started with: cost per successful task, not price per token. If a cheap model needs re-prompting more than about 20 percent of the time on a given step, its price advantage evaporates and you should promote that step a tier. Route by measured success rate, escalate on repeated failure, and you get most of Opus's reliability at most of Sonnet's price. For teams building this into a genuine operating layer, hiring an AI workforce to run your company shows where routed agents fit into real operations.

9. The competitive context: GPT-5.6 Sol, Gemini 3.1 Pro, and open weights

No model choice happens in a vacuum, and a founder deciding what to build on should know where Opus 5 and Sonnet 5 sit against the rest of the frontier, because the competitive picture affects both leverage and lock-in risk. The single most important context is that as of August 2026, OpenAI's current flagship is the GPT-5.6 family, released to general availability on July 9, 2026 as a three-tier lineup: Sol as the flagship, Terra as the balanced tier, and Luna as the fast tier - MarkTechPost. This matters because it means both major labs now ship a capability ladder, and the founder question of "which tier" is the same shape whether you build on Claude or GPT. We covered OpenAI's ladder in depth in GPT-5.6 Sol vs Terra vs Luna.

On the benchmarks that matter for a build, the two flagships trade blows. GPT-5.6 Sol leads agentic coding on Terminal-bench 2.1 at 88.8 percent (rising to 91.9 percent in its Ultra high-effort mode), and independent runs put it around 96.2 percent on SWE-bench Verified, just behind Opus 5's roughly 97 percent - morphllm. But Sol is priced at $5 and $30 per million, a pricier output rate than Opus 5's $25, and OpenAI declined to report SWE-bench Verified officially - Eden AI. The practical read is that Sol and Opus 5 are genuine peers on coding, with Opus 5 slightly cheaper on output and Sol slightly ahead on terminal-style agentic tasks. There is no runaway winner, which is good news for founders: competition at the top is holding prices down and capability up.

Google's position is the surprising part of the 2026 picture, and it changes the calculus in ways worth naming. As of August 2026, Google's highest-capability model remains Gemini 3.1 Pro, released back in February 2026, because the expected Gemini 3.5 Pro flagship has been delayed and Google's July releases were Flash-tier only - TechCrunch. Gemini 3.1 Pro is a capable 1M-context model, but on coding it trails both leaders meaningfully, at 80.6 percent SWE-bench Verified and 74.8 percent on Terminal-bench 2.0 - NxCode. For a founder building an agentic or coding product, that roughly 16-point gap on SWE-bench Verified is the difference between a model that ships features autonomously and one that needs more hand-holding, which is why Claude and GPT dominate the agentic-build conversation in mid-2026.

The Intelligence Index below ranks the frontier as Artificial Analysis measured it, and it is the single most useful cross-vendor snapshot because it aggregates many evaluations into one comparable number. Note where Opus 5 lands, and note how tight the top of the field is.

The last piece of context is the open-weight frontier, which sets a floor under pricing power and a ceiling on lock-in risk. The strongest open-weight model on coding in mid-2026 is Kimi K3 at 93.4 percent SWE-bench Verified, close enough to the proprietary leaders that self-hosting is a genuine option for teams with the infrastructure to run it - vals.ai. The strategic implication for a founder is subtle but real: because a capable open model exists a few points behind the frontier, no proprietary vendor can price too aggressively, and you always retain a credible exit. That is part of why building on a hosted model like Sonnet 5 or Opus 5 is a defensible default rather than a trap. The intelligence layer is competitive; the value you build on top of it is where the durable business sits, a theme we develop in what it costs to build an app with AI.

10. How founders actually build on this in 2026

Move from theory to the machinery a founder actually touches, because the model choice expresses itself through the tools you build with, not through a raw API call in a vacuum. The most common entry point is Claude Code, Anthropic's agentic coding environment, whose default model is the latest Sonnet precisely because Sonnet scores within a point or two of Opus on the coding benchmarks at roughly 60 percent lower cost - Morph. The design of Claude Code encodes the whole thesis of this guide: run the volume on Sonnet, escalate to Opus with the /model command when a task is hard enough to justify it. If you are building software this way, our guide to building software with AI covers the workflow end to end.

The next layer up is the agent framework, where the model choice becomes a per-step decision. The Claude Agent SDK, LangGraph, and similar tools let you assign a model to each node of a workflow, which is how the three-tier routing pattern gets implemented in practice. This is also where tool use and the Model Context Protocol enter: an agent is only as useful as the tools it can call, and wiring those tools is often more decisive than the model choice itself. As one practitioner who ships production Claude agents put it, "all frontier models are capable; the difference is the ecosystem" - HeroHunt. If you are exposing your own product to agents, our walkthrough on shipping an MCP server for your product shows the mechanics.

That practitioner is Yuma Heymans (@yumahey), who builds autonomous AI agents for a living, from the AI recruiter HeroHunt.ai to the autonomous-company platform behind Founden, and who wires frontier Claude models into products that run in production every day. That is exactly the Opus-versus-Sonnet trade-off this guide walks through: not a benchmark question, but a shipping question about which engine delivers the outcome at a price the business can carry. His point about ecosystem over raw capability is the one most founders underrate. The model is one component; the tools, memory, routing, and orchestration around it are where a product actually gets built.

This is also where the two competing theses about model choice resolve into practice. The mainstream recommendation is "start on Sonnet, escalate to Opus when it pays off," an 80/20 split where a solo developer might pay $10 a month for Sonnet on the 80 percent of tasks where both perform equally and save roughly $480 a year against an Opus-only bill - NxCode. The competing thesis, aimed at teams running production agent fleets, argues that Opus 5's self-verification lowers cost per successful task enough that it should be the default for long-horizon work, and that its price drop removed the frontier-price barrier that used to make this a hard call - DigitalApplied. Both are right for their context, which is the whole point: the answer is a function of your workload, not a universal verdict.

For the many founders who are not technical enough to wire effort flags, routing gateways, and MCP servers themselves, there is a third path: let a platform make the model decision for you. This is the lane Founden occupies. Founden builds and operates a complete company from a description, website, app, billing, and admin, and it picks and routes the underlying models under the hood, so a non-technical founder never has to choose between Opus 5 and Sonnet 5 or tune an effort level. It is one option among several (you can equally assemble the stack yourself), but for founders whose scarce resource is engineering time rather than money, abstracting the model decision away is a legitimate strategy. The deeper you get into running a business on agents, the more this matters, which is the subject of our autonomous business guide.

The video below is a concise launch-day rundown of Opus 5's features, pricing, and effort toggle, useful if you want to see the model and its controls demonstrated rather than described.

11. Failure modes, limits, and the fine print

A guide that only lists strengths is a brochure, so reason honestly about where each model breaks, because the failure modes are exactly the things that will surprise you in production. The first and most common is the cost surprise from thinking-on-by-default. On both Opus 5 and Sonnet 5, adaptive thinking runs unless you disable it, and those reasoning tokens are billed as output. A team migrating from a model where thinking was off can see output-token volume roughly double at matched effort, which shows up as a bill that is higher than the rate card predicted - eesel AI. The fix is not to fight it but to use the effort ladder deliberately: start at high rather than max, and drop to low or medium for routine work. There is a wrinkle on Opus 5 specifically: disabling thinking is only permitted at effort high or below, so a request that pairs disabled thinking with xhigh or max effort is rejected outright.

The second failure mode is behavioral over-eagerness on the frontier model. Opus 5 verifies its own work without being asked, expands task scope beyond what you requested, and narrates more than you may want, all of which are helpful in some contexts and noise in others. The counterintuitive fix, documented in Anthropic's own migration guidance, is to delete verification instructions rather than add them, because telling Opus 5 to "double-check your answer" triggers redundant work it was already doing. This inverts a standard prompting habit, and a prompt library that applies "ask the model to self-check" uniformly will make Opus 5 worse, not better. Budget engineering time for re-tuning prompts when you move onto this generation; the models follow instructions more literally than their predecessors.

A concrete version makes the trap obvious. A team migrates a code-review agent from an older model, carrying forward a prompt that says "be conservative and only report high-severity issues." On Opus 5, which follows that instruction faithfully, the agent investigates just as thoroughly as before, finds the bugs, and then declines to report the ones it judges below the stated bar. Measured recall drops, and the team concludes the new model is worse at finding bugs, when in fact it is better and is simply obeying a filter the old model half-ignored. The fix is to invert the prompt: ask it to report every finding with a confidence and severity label, and move the filtering to a separate downstream step. The same literalism that makes Opus 5 feel like it "regressed" is the property that makes it reliable once your prompts stop fighting it. This is the recurring shape of the frontier-model failure mode: the model does exactly what you said, and what you said was tuned for a model that did not.

The third set of limits is the safety and capability guardrails. Both models ship with elevated cybersecurity safeguards, and Opus 5 in particular is described as Anthropic's most aligned Opus model, least susceptible to being tricked into misuse - Fortune. In practice this means a request that trips a safety classifier returns a refusal rather than an answer, which benign security-adjacent and life-sciences work can occasionally hit as a false positive. Sonnet 5's cyber capability is deliberately weaker still. For most products this is invisible; for a product that genuinely operates in security research, it is a real constraint you should test against your actual prompts before committing.

• Thinking-on-by-default inflates output tokens unless you set effort deliberately
• Sonnet 5's new tokenizer raises effective cost versus the prior generation
• Opus 5 over-verifies and expands scope unless you prune your prompts
• Safety classifiers can refuse benign security-adjacent requests
• Third-party benchmark numbers vary widely and should be treated as directional

The fourth limit is epistemic and worth stating plainly: the benchmark data for this generation is noisier than usual. Anthropic publishes its charts as images and dropped SWE-bench Verified from its launch materials, so the cleanest headline numbers you see are third-party, and they disagree by wide margins - Coursiv. We flagged the Sonnet 5 Verified number ranging from 82 to 92 percent across sources; treat any single figure with suspicion and lean on the consistently reported metrics or, better, on your own evaluation set. There is also a live pricing ambiguity to verify before you budget: Anthropic's documentation lists Sonnet 5 reverting to $3 and $15 on September 1, 2026, but Anthropic has signaled it may keep the introductory $2 and $10 rate in place - Anthropic pricing. Check the live price page before you model your costs, because it swings the Opus-to-Sonnet multiple between 1.67x and 2.5x. Data corruption and silent errors are their own category of failure in AI products, which we treat separately in why AI apps corrupt data and the fix.

12. The 2026 outlook: cadence, price compression, and agents

Step back and reason about the trajectory, because the smart model decision today is partly a bet on where this is heading, and the direction is unusually legible right now. The first trend is cadence. Anthropic shipped four Claude 5 models in under two months in mid-2026, and OpenAI and Google are on similar clips - Axios. The implication for a founder is architectural: build so you can swap models cheaply, because the model you choose today will have a successor within a quarter. Abstract the model behind a routing layer or a gateway, keep your prompts and evals versioned, and treat the specific model ID as a configuration value rather than a foundation. The teams that will move fastest through 2027 are the ones who made the model a swappable component.

The second trend is price compression at the frontier, and Opus 5 is the clearest data point. Anthropic delivered near-Fable-5 capability at half the price, which means the cost of frontier-grade reasoning inside your product roughly halved in a single release while the sticker price of the tier held flat - Anthropic. Extrapolate the pattern and the strategic conclusion is that capability you cannot afford today you will likely afford next quarter, so designing your product around a capability that is just out of reach is often a better bet than it looks. The cost per task on Artificial Analysis's own evaluation illustrates the compression: Sonnet 5 at roughly $1.53, Opus 5 at $2.03, and Fable 5 at $2.75, a frontier that keeps getting cheaper per unit of intelligence delivered.

The third and most consequential trend is the shift from chat to agents. Both Sonnet 5 and Opus 5 were explicitly built for autonomous, multi-step, tool-using work rather than single-turn conversation, and the production users cited at launch are running them as agents, not chatbots - TechCrunch. For a founder, this reframes the model decision one more time: you are not choosing a text generator, you are choosing the reasoning core of an autonomous worker, and reliability over long horizons becomes the property that matters most as agents take on more of the actual work. This is why Opus 5's self-verification and long-run coherence command a premium that a pure chat use case would never justify.

The hands-on Sonnet 5 walkthrough below, the highest-traction independent launch coverage, is a useful watch if you want to see the model driving real agentic tasks rather than answering questions, which is the mode most 2026 products will actually use.

Put the three trends together and the strategic posture writes itself. Assume the model layer will keep getting faster, cheaper, and more agentic on a roughly quarterly cadence; build so you can absorb each release as a config change; and invest your scarce time in the tools, data, routing, and orchestration around the model, because that is the layer that compounds. The intelligence is becoming a commodity input; the durable business is in combining it with domain expertise and a great product. If you are still deciding what that product is, how to start a company in 2026 is the right next read; if you are choosing your coding stack, Claude Code versus Codex versus Devin compares the environments this all runs in.

13. Conclusion: a decision framework you can act on

Strip away the benchmarks and the pricing tables and the decision reduces to a handful of moves you can make today. Default to Claude Sonnet 5. For the large majority of product surfaces, chat, retrieval, classification, and in-the-loop coding, Sonnet 5 delivers roughly previous-flagship quality at a Sonnet price, which is why it is the default in Claude Code and the model production teams reach for first. Starting here is not settling; it is buying the competent model and keeping the difference, and on the 80 percent of tasks where both models perform equally, that difference is real money.

Escalate to Claude Opus 5 when the task lives in the hard tail. Long-horizon autonomous agents, deep multi-file refactors, ambiguous or novel research, and any workload where a wrong answer is costly and hard to catch are where Opus 5's frontier reasoning and self-verification earn their 1.67x premium. The premium is smaller than it used to be, because Opus 5 repriced the frontier to half of Fable 5, so the barrier that once made this a fraught call is largely gone. The trigger is not "this task is important," it is "an error here is expensive and hard to detect cheaply." When that is true, buy the reliability.

Better still, do not choose, route. The architecture that beats both single-model strategies is three-tier routing: Opus 5 to plan, Sonnet 5 to implement, Haiku 4.5 for cheap mechanical steps, which cuts blended cost by roughly half with no loss of quality on the tasks that matter. Judge every step by cost per successful task, not price per token; escalate a step a tier whenever a cheaper model needs re-prompting more than about a fifth of the time. And whatever you choose, build the model as a swappable component, because a better and cheaper successor is one quarter away.

Finally, verify against your own reality before you commit. Benchmark 50 to 100 representative examples from your actual product, measure both quality and total cost on the exact model you plan to ship, and re-check the live pricing page, since Sonnet 5's introductory rate and the tokenizer's effective-cost inflation both move the numbers. If your scarce resource is engineering time rather than budget, a platform like Founden that picks and routes the models for you is a legitimate way to skip the whole decision. Whichever path you take, the winning move in 2026 is the same: treat intelligence as the cheap, swappable input it has become, and pour your energy into the product built on top of it.

This guide reflects the Claude model landscape as of August 2026. Model versions, benchmark results, and especially pricing change frequently. Anthropic's introductory Sonnet 5 rate and third-party benchmark figures are contested, verify current details on the official pricing and model pages before making a purchasing or architecture decision.