Claude Opus 5 vs Sonnet 5 Explained: Benchmarks, Pricing, and the Effort Toggle That Actually Matters

Anthropic shipped two new flagship models within four weeks of each other this summer: Claude Sonnet 5 on June 30, 2026, and Claude Opus 5 on July 24, 2026 [1][2]. That is an unusually tight release window for two models in the same family, and it leaves a genuinely practical question for anyone building on the Claude API or paying for a Claude Pro or Max seat: which one should you actually be using, and for what.

This is not a marketing comparison. It is a walkthrough of the real benchmark numbers, the real pricing, and the mechanism that matters most in this generation: the effort toggle, a setting that lets you dial how much test-time compute a single Claude request spends thinking before it answers. Get the effort setting wrong and you either overpay for a task that did not need it, or underpay and get an answer that is not good enough to ship.

Step 1: What Actually Changed Between the 4.x and 5 Generations

Sonnet 5 is described by Anthropic as the most agentic Sonnet model the company has shipped, built to make plans, use tools like browsers and terminals, and run autonomously at a level that previously required a larger, more expensive model [1]. The headline claim from the launch is that Sonnet 5 performs close to Opus 4.8 across reasoning, tool use, coding, and knowledge work, at a meaningfully lower price [3].

Opus 5 followed less than a month later and is positioned differently: a step change for the Opus tier specifically aimed at long-running agents, with Anthropic describing it as coming close to the frontier intelligence of Claude Fable 5 at half the price, and stating it more than doubles Opus 4.8's score on Frontier-Bench v0.1 at a lower cost per task [2]. Opus 5 is now the default model on Claude Max and the strongest model available on Claude Pro [2].

A few things are genuinely new rather than just incremental:

• A five-level effort control (low, medium, high, xhigh, max) that replaces the older, coarser "thinking budget" style controls, giving you a direct dial on how much reasoning the model does per request.
• An updated tokenizer. The same input text can require roughly 1.0 to 1.35 times more tokens with the 5-generation tokenizer depending on content, which matters if you are estimating costs from historical Sonnet 4.6 or Opus 4.8 usage [4].
• Lower rates of hallucination and sycophantic behavior compared to the 4.6 generation, according to Anthropic's own reporting, alongside stronger default resistance to prompt injection attacks [3].
• Real-time cyber safeguards enabled by default, part of a broader push toward safer autonomous tool use as these models are trusted with more agentic responsibility [4].

That last point deserves a bit more context, because it is a direct consequence of the same agentic capability improvements that make these models more useful. A model that can autonomously browse the web, execute terminal commands, and edit files is also a model that can be manipulated into doing those things by content it encounters while performing a task, for example a webpage or a file that contains hidden instructions designed to redirect the agent. Anthropic's reporting on both launches emphasizes stronger default resistance to exactly this class of prompt injection attack, alongside cleaner and more consistent refusal behavior on requests that are unsafe regardless of how they are phrased [3]. If you are building an agent that has any autonomous tool access, this is not a footnote. It is one of the practical reasons to prefer the 5 generation over 4.x even for workloads where the raw benchmark improvement alone would not justify a migration.

What This Means If You Are on Claude Pro or Max, Not the API

Not everyone comparing these two models is choosing an API model string. If you are a Claude Pro or Max subscriber, the choice is simpler but still worth understanding. Opus 5 is now the default model on Claude Max and the strongest model available on Claude Pro [2], meaning subscribers on those plans already get Opus-tier reasoning without manually selecting a model for most conversations. Where the effort toggle still matters for subscribers is in longer, more complex chats: some Claude clients expose an extended thinking or effort-style control directly in the interface, and turning it up for a genuinely hard problem, a large refactor, a long research question, a complex spreadsheet formula, follows the exact same logic covered in Step 2, just without writing any API code. Turning it up for a quick factual question mostly adds wait time without adding value.

None of this is abstract. If you are running an agent that browses the web, edits files, or calls internal tools on a schedule, the combination of better tool use and an explicit effort dial is the actual product change here, more than any single benchmark number.

Step 2: The Effort Toggle, and Why It Is Not Just a Speed Setting

The effort parameter is the single most consequential addition in this generation, and it is worth understanding mechanically rather than treating it as a vague "quality slider."

Modern reasoning models spend a variable amount of compute at inference time before producing a final answer, generating and evaluating intermediate reasoning steps. Research on test-time compute scaling has shown that spending more inference-time compute on a hard problem can improve accuracy by an amount comparable to, and in some regimes exceeding, what you would get from a substantially larger base model [5]. The effort parameter is Anthropic's productized version of that idea: instead of a fixed amount of reasoning per request, you choose how much.

Here is what that looks like in practice through the API:

python
/code
import anthropic

client = anthropic.Anthropic()

def ask(question: str, effort: str = "high", model: str = "claude-sonnet-5"):
    """Call Claude with an explicit effort level. Lower effort trades reasoning
    depth for speed and cost, higher effort spends more test-time compute on
    harder problems. Valid effort values for the 5 generation are low,
    medium, high, xhigh, and max (xhigh and max are Opus-tier only)."""
    response = client.messages.create(
        model=model,
        max_tokens=4096,
        effort=effort,
        messages=[{"role": "user", "content": question}],
    )
    return response.content[0].text

# A quick classification task does not need deep reasoning.
quick_answer = ask("Is this support ticket billing or technical?", effort="low")

# A multi-step agentic coding task benefits from more test-time compute.
deep_answer = ask(
    "Refactor this payment retry logic to handle partial failures safely.",
    effort="high",
    model="claude-opus-5",
)

A few concrete implications follow directly from this mechanism:

• Low and medium effort are appropriate for short, well-scoped tasks: classification, extraction, simple rewrites, single-turn question answering. Spending extra reasoning here mostly burns tokens without changing the answer.
• High effort is the sensible default for most production agent work: multi-step coding tasks, tool-calling workflows, and anything where a wrong intermediate step compounds into a wrong final result.
• xhigh and max are Opus 5 exclusive and are reserved for genuinely hard problems. Reporting from early users notes that max occasionally underperforms xhigh while costing more, which suggests more reasoning is not strictly monotonic in quality and is worth benchmarking on your own workload rather than assuming higher is always better [6].

This same idea, giving developers an explicit effort or reasoning-depth parameter rather than a single fixed behavior, mirrors the direction other labs have taken with their own reasoning models. OpenAI's API exposes a nearly identically named reasoning_effort parameter across its o-series and GPT-5 series models, with supported values including low, medium, high, and, on newer models, xhigh [10]. The convergence on the same vocabulary across two competing labs is not a coincidence. It reflects a broader industry shift: model quality is no longer just a function of which model you call, it is a function of which model at which effort level for which specific task.

How Effort Levels Are Implemented Under the Hood

The mechanism underneath an effort setting is variable-length reasoning. At low effort, the model produces a short or empty internal reasoning trace before its final answer. At higher effort levels, it generates a longer chain of intermediate reasoning tokens, tokens the user typically does not read directly but that the model uses to work through the problem before committing to a final response.

The research literature calls this test-time compute scaling, and the original demonstration of the idea, from Snell, Lee, Xu, and Kumar, compared two ways of spending extra compute at inference time: letting a model generate a longer reasoning chain for a single attempt, versus generating several shorter attempts and picking the best one through a verifier or majority vote. Their result was that, for a fixed compute budget, adaptively choosing how to spend it based on problem difficulty outperformed a fixed strategy, and could match the performance of a model roughly 14 times larger on some tasks [5]. That is the theoretical basis for why an effort dial is valuable at all: it is not just "let the model think longer," it is "spend compute proportional to how hard this specific request actually is."

This is also why effort is not strictly monotonic in quality, as the max-versus-xhigh anomaly on Opus 5 illustrates. A longer reasoning trace gives the model more opportunity to explore the solution space, but it also gives more opportunity to talk itself out of a correct early answer or wander down an unproductive line of reasoning, particularly on problems that were already within the model's capability at a lower effort level.

Step 3: The Benchmark Numbers, Side by Side

Anthropic's own launch benchmarks, corroborated by independent write-ups from DataCamp and MarkTechPost, give a reasonably complete picture of where each model lands relative to its predecessor and its sibling [4][7].

A few things stand out reading this table:

Sonnet 5 closed most, not all, of the gap to Opus 4.8. On SWE-bench Pro, Sonnet 5's 63.2% sits closer to Opus 4.8's 69.2% than to its own predecessor's 58.1%, which supports Anthropic's framing of Sonnet 5 as "near-Opus performance at Sonnet pricing." But it did not fully close the gap, and on Terminal-Bench 2.1 and OSWorld-Verified, the pattern repeats: real improvement, real gap remaining.

Sonnet 5 actually edges out Opus 4.8 on one metric. On GDPval-AA v2, a knowledge-work benchmark, Sonnet 5 scores 1,618 against Opus 4.8's 1,615. This is a useful reminder that "flagship tier" and "best at every task" are not the same claim. Task type matters more than model tier alone.

Opus 5's headline number is SWE-bench Verified at 96%, with SWE-bench Pro, the harder and more adversarial successor benchmark, at 79.2% when run at xhigh effort [6]. That effort-level caveat matters: Opus 5's best scores are specifically effort-dependent, which is the entire point of the toggle discussed above. A default or medium-effort Opus 5 call will not automatically reproduce the numbers in Anthropic's launch materials.

Independent reviewers echo the same shape of result. Geeky Gadgets' hands-on coding review found Opus 5 strong on structured coding and benchmark tasks but noted friction in some interactive workflows [8], and Lenny's Newsletter's review similarly described a model that is "brilliant but annoying" in places, strong at the hard reasoning tasks it was built for while occasionally being verbose or slower than expected in casual use [9]. Benchmark tables are real data, but they measure a narrower slice of behavior than "how does this feel to use all day," and it is worth reading both.

How This Stacks Up Against the Rest of the 2026 Frontier

Anthropic's own launch materials do not include head-to-head numbers against every competing frontier model, and it would be a mistake to invent comparison figures Anthropic itself has not published. What can be said with confidence is qualitative rather than a specific score: as of August 2026, the frontier field also includes OpenAI's GPT-5.6, Google's Gemini 3.1, and open-weight releases like DeepSeek V4, each iterating on the same general pattern of tiered model families with effort or reasoning-depth controls. Sonnet 5 and Opus 5's jump on SWE-bench Pro and Terminal-Bench keeps Anthropic competitive on agentic coding specifically, which has been the company's most consistently emphasized strength across the 4.x and 5 generations. If you need a hard number for a competing model before making a purchasing decision, treat any figure not published by that model's own maker, or corroborated by at least two independent named outlets, as unverified, the same standard applied to every number in this post.

Step 4: Pricing and What It Actually Costs Per Task

Sonnet 5 launched with introductory pricing through August 31, 2026, before stepping up to its standard rate [1]. Opus 5 kept the same list price as Opus 4.8, which is notable given the benchmark jump it represents [2][6].

Raw per-token pricing is not the same as per-task cost, since Opus 5 at xhigh effort will generate more reasoning tokens per request than Sonnet 5 at low effort, on top of the roughly 2.5x per-token price gap. A simple way to reason about this:

python
/code
def cost_per_task(input_tokens: int, output_tokens: int, input_price: float, output_price: float) -> float:
    """Rough cost of a single task given per-million-token pricing.
    Sonnet 5 introductory pricing (through Aug 31, 2026) is $2 / $10 per
    million input/output tokens. Opus 5 is $5 / $25 per million tokens,
    the same as Opus 4.8."""
    return (input_tokens / 1_000_000) * input_price + (output_tokens / 1_000_000) * output_price

sonnet_task = cost_per_task(input_tokens=8_000, output_tokens=2_000, input_price=2.0, output_price=10.0)
opus_task = cost_per_task(input_tokens=8_000, output_tokens=2_000, input_price=5.0, output_price=25.0)

print(f"Sonnet 5 task: ${sonnet_task:.4f}")
print(f"Opus 5 task:   ${opus_task:.4f}")
print(f"Opus 5 costs {opus_task / sonnet_task:.1f}x more per task at this token mix")

At the token mix in that example, Opus 5 costs roughly 2.5 times more per task purely from list pricing, before accounting for the fact that a harder task run at higher effort will also generate more output tokens, compounding the gap further. This is exactly why blanket "always use the best model" advice is expensive advice in practice, and why the routing logic in Step 6 matters more than picking a single winner.

There is also an API-only Fast mode for Opus 5, priced at $10 input / $50 output per million tokens, roughly double the standard Opus 5 rate, for workloads where latency matters more than cost [6]. That option did not exist in the 4.x generation and is a direct acknowledgment that "best model" and "fastest model" are now separately purchasable properties.

Step 5: When to Actually Reach for Each Model

Putting the benchmarks and pricing together, a few concrete patterns fall out.

Reach for Sonnet 5 at low or medium effort when:

• The task is short, well-defined, and has a clearly checkable output, like structured data extraction, ticket triage, or simple content classification.
• You are running high request volume where per-task cost compounds fast, such as processing thousands of documents or messages per day.
• Latency matters more than squeezing out the last few points of benchmark accuracy.

Reach for Sonnet 5 at high effort when:

• You are doing standard agentic coding work: implementing a feature, writing tests, fixing a well-scoped bug. This is the effort tier that produced the 63.2% SWE-bench Pro score, already a large jump over Sonnet 4.6's 58.1%.

Reach for Opus 5 at high or xhigh effort when:

• The task is long-horizon: a multi-file refactor, an agent that needs to stay coherent across dozens of tool calls, or research synthesis where an error early in the chain propagates into a wrong final answer.
• The cost of a wrong answer meaningfully exceeds the cost difference between the two models, which is true for most production-critical code changes and most customer-facing agent decisions.
• You specifically need the highest available coding ceiling. At 96% on SWE-bench Verified, Opus 5 is currently the strongest coding-focused Claude model available [2].

A useful case study here is content pipelines with multiple dependent generation steps, the kind of workflow behind tools like Text2Shorts in Miraflow AI, where a topic becomes a script, then scene visuals, then a finished video. A pipeline like that typically has a mix of task types in a single run: a script-writing step that benefits from stronger reasoning about narrative structure, and a formatting or metadata-extraction step that does not need much reasoning at all. Applying the same effort level to every step in a multi-stage pipeline is one of the most common ways teams overpay without realizing it.

Case Study: Walking Through a Realistic Migration

Consider a hypothetical but representative agentic coding setup: an internal tool that reads a bug report, locates the relevant files, proposes a fix, writes a test, and opens a pull request for review. Under the 4.x generation, a team running this pipeline had two practical choices: run everything on Sonnet 4.6 and accept a lower success rate on harder bugs, or run everything on Opus 4.8 and accept roughly 2.5 times the per-task cost even for trivial one-line fixes.

With the 5 generation and its effort toggle, the same pipeline can be restructured around three stages instead of one flat model choice. First, a triage stage classifies the bug report's apparent complexity using Sonnet 5 at low effort, a fast, cheap classification task. Second, the actual fix generation runs on Sonnet 5 at high effort for anything triaged as routine, which the benchmark numbers above suggest should now succeed on a meaningfully larger share of tasks than it would have under Sonnet 4.6. Third, anything that fails its generated test suite, or that triage flagged as touching a high-risk area like payment or authentication code, escalates to Opus 5 at high or xhigh effort for a second attempt.

The net effect of this kind of restructuring is not that every task gets cheaper or every task gets better. It is that average cost per resolved bug drops because most bugs are routine and now succeed more often at the cheaper tier, while the ceiling for genuinely hard bugs goes up because Opus 5 at xhigh is a stronger fallback than Opus 4.8 was. That combination, a better cheap tier and a better expensive tier, is the actual value of this release for anyone running production agentic workflows, more than either model's standalone benchmark score.

Step 6: A Production Routing Pattern

The practical answer to "Sonnet 5 or Opus 5" for most teams is not a single model choice, it is a router. Here is a simplified version of the pattern:

python
/code
def route_task(task_type: str, estimated_steps: int) -> dict:
    """A simple complexity-based router. Short, well-defined tasks go to
    Sonnet 5 at low or medium effort. Long-horizon agentic work, or tasks
    where a wrong answer is expensive to catch later, go to Opus 5 at high
    or xhigh effort. This mirrors how production teams are reported to be
    splitting traffic between the two models rather than defaulting to the
    most expensive option for every request."""
    if task_type in ("classification", "extraction", "short_qa") and estimated_steps <= 3:
        return {"model": "claude-sonnet-5", "effort": "low"}
    if task_type in ("coding", "refactor", "agentic_workflow") and estimated_steps <= 8:
        return {"model": "claude-sonnet-5", "effort": "high"}
    if task_type in ("long_running_agent", "multi_file_refactor", "research_synthesis"):
        return {"model": "claude-opus-5", "effort": "high"}
    return {"model": "claude-opus-5", "effort": "xhigh"}

print(route_task("short_qa", 1))
print(route_task("coding", 6))
print(route_task("long_running_agent", 20))

A few production notes on top of that simplified version:

• Log the actual effort level and model used per request, not just the request type. Effort routing decisions drift as prompts and task distributions change, and you want to be able to audit whether your router's assumptions are still true a few months later.
• Re-benchmark after any model upgrade. A router tuned against Sonnet 4.6 and Opus 4.8's relative strengths is not guaranteed to route optimally for Sonnet 5 and Opus 5, since the gap between tiers changed meaningfully in this generation, as the benchmark table above shows.
• Treat xhigh and max as an escalation path, not a default. A common pattern is to run a task at Sonnet 5 high effort first, and only escalate to Opus 5 xhigh if the output fails a validation check, a test suite, or a confidence heuristic. This keeps the expensive tier reserved for the fraction of requests that actually need it.
• Canary new effort-level defaults before rolling them out fleet-wide. Since higher effort is not guaranteed to improve every task, a change from high to xhigh effort should be validated against a held-out set of real requests before becoming the new default, not assumed to be a strict upgrade.
• Set hard per-request token ceilings even at high effort levels. Reasoning models can occasionally generate unusually long reasoning traces on ambiguous prompts. A ceiling protects against a single malformed request consuming an outsized fraction of a budget.
• Separate your escalation trigger from your retry logic. A request that fails validation because of a genuine model error should escalate to a higher effort tier. A request that fails because of a transient tool timeout should simply retry at the same tier. Conflating the two wastes the expensive tier on problems a plain retry would have solved.

If you want a visual, hands-on walkthrough instead of just the numbers, this full review of Sonnet 5 against Opus 4.8 covers real coding tasks run against both models side by side, which is a useful sanity check against the benchmark table above.

If you would rather visualize the effort-versus-cost tradeoff as a short generated clip, here is a video prompt built around the same balance-scale idea used in the hero image, written for a Wan-style video model:

A pastel-toned brass balance scale sits on a wooden desk, one pan holding a small dense glowing sphere, the other holding a larger, lighter glowing sphere. The dense sphere's pan slowly tips down as a soft blue readout of numbers rises beside it, then the lighter sphere's pan rises quickly with a soft green readout beside it, the two panels settling into balance. Clean scientific motion-graphics style, precise geometric shapes, soft pastel lighting, no readable text, no logos, no people, smooth steady camera push-in.

Benchmarking This on Your Own Workload

Every number in the table above comes from Anthropic's launch benchmarks or independent review coverage, and general-purpose benchmarks like SWE-bench Pro or GDPval-AA v2 are useful for comparing models in the abstract, but they are not a substitute for testing against your actual task distribution. A practical benchmarking pass before committing to a routing strategy looks like this:

• Pull a representative sample of real requests, at least 50 to 100, spanning the difficulty range your system actually sees, not just the hardest or easiest cases.
• Run the same sample through Sonnet 5 at each supported effort level and Opus 5 at each supported effort level, holding every other variable, prompt template, tool access, temperature, constant across runs.
• Score outputs against a task-specific rubric, not a generic quality rating. For a coding task, this might mean running the generated code against a real test suite rather than having a human eyeball it.
• Plot cost against success rate for each model and effort combination. The model and effort level that sits on the efficient frontier of that plot, the best success rate for a given cost, or the lowest cost for a given success rate, is your actual answer, and it will often differ from whatever combination scored highest on a general benchmark like the ones in Step 3.

This is the same principle behind the routing pattern in Step 6, applied one level up: before you can route intelligently between models, you need real evidence for your specific workload about where each model and effort level actually pays off.

Common Mistakes and Misunderstandings

A handful of mistakes show up repeatedly when teams first migrate to the 5 generation.

• Assuming higher effort is always better. As the max-versus-xhigh reporting on Opus 5 shows, more test-time compute is not strictly monotonic in output quality for every task, and it always costs more [6].
• Estimating cost from old token counts. The updated tokenizer means the same input can consume 1.0 to 1.35 times more tokens than it did under Sonnet 4.6 or Opus 4.8, which silently inflates cost estimates carried over from the previous generation [4].
• Treating Sonnet 5 as strictly worse than Opus 4.8. On knowledge-work tasks measured by GDPval-AA v2, Sonnet 5 edges out Opus 4.8 outright. Benchmark tier and task fit do not always align.
• Applying one model and one effort level to an entire multi-step pipeline. As discussed in Step 5, this is usually where the most avoidable spend hides.
• Ignoring the qualitative reviews in favor of only the benchmark table. Both Geeky Gadgets and Lenny's Newsletter found real friction points in day-to-day use of Opus 5 that a benchmark score alone does not surface [8][9].
• Confusing Fast mode with a higher effort level. Opus 5's API Fast mode, at roughly double the standard per-token price, optimizes for lower latency, not deeper reasoning. Pairing Fast mode with a low effort setting on a hard task will not reproduce Opus 5's benchmark-leading scores, since those numbers come from standard mode at high or xhigh effort.
• Skipping the benchmarking step entirely and copying someone else's routing thresholds. The task router pattern in Step 6 is a starting structure, not a set of universal cutoffs. A team whose "coding" tasks are mostly small bug fixes and a team whose "coding" tasks are mostly large refactors should end up with meaningfully different thresholds for when a request escalates from Sonnet 5 to Opus 5, even though both teams might label their tasks the same way.

Why This Matters Beyond Pure Coding Work

It is tempting to file effort-tunable reasoning models under "developer tooling" and move on, but the same tradeoff shows up anywhere a generation pipeline has more than one step with a different difficulty profile. A creative pipeline that turns an idea into a finished piece of content, the kind of flow behind the AI Image Generator in Miraflow AI or the cinematic AI video generator, has the same shape: a planning or scripting step that benefits from more careful reasoning, and a mechanical formatting step that does not. Understanding how effort-based routing works for a text model like Claude makes it easier to reason about the same tradeoff when picking settings for other generation tools, including the AI Music Generator, where the "reasoning" toggle plays an analogous role in balancing generation quality against turnaround time. If you are curious about the inference-side half of this story, our breakdown of speculative decoding and how it makes LLM inference 2 to 3 times faster covers the complementary technique of getting a fixed amount of reasoning out faster, rather than choosing how much reasoning to spend in the first place. You can browse more explainers like this on the Miraflow AI blog.

Frequently Asked Questions

Is Claude Opus 5 always better than Claude Sonnet 5? Not on every task. Opus 5 leads on the hardest coding and long-horizon agentic benchmarks, but Sonnet 5 actually edges it out on the GDPval-AA v2 knowledge-work benchmark, and costs meaningfully less per task. The right choice depends on the task, not a fixed ranking.

What does the effort parameter actually control? It sets how much test-time reasoning compute the model spends before answering, from low through max. Higher effort levels generally improve accuracy on hard, multi-step problems but cost more in tokens and latency, and are not guaranteed to help on tasks that were already easy for the model.

Are xhigh and max available on Sonnet 5? No. Based on current reporting, xhigh and max effort levels are Opus 5 exclusive; Sonnet 5 supports low, medium, and high.

Why did Opus 5's price stay the same as Opus 4.8 despite the benchmark jump? Anthropic has not published a detailed explanation, but it is consistent with a broader industry pattern of holding flagship-tier pricing steady release over release while improving the underlying model, rather than passing capability gains through as price increases.

Should I migrate existing Sonnet 4.6 or Opus 4.8 workloads immediately? Re-benchmark on your own task distribution first. The updated tokenizer changes token counts, and effort-level defaults changed enough between generations that a workload tuned for the 4.x generation may not be optimally configured for the 5 generation out of the box.

Does any of this apply outside of coding agents? Yes. Any multi-step generation pipeline, including content creation workflows that plan a script, generate visuals, and assemble a final piece, benefits from matching reasoning depth to task difficulty at each step rather than using one setting throughout.

Conclusion

Sonnet 5 and Opus 5 are not really competitors within Anthropic's own lineup, they are two ends of the same effort-tunable system. Sonnet 5 closed most of the gap to the previous Opus tier at a fraction of the price, and Opus 5 pushed the ceiling higher for the specific class of long-horizon, high-stakes agentic work that can justify the cost. The effort toggle is what makes both of those statements true at once: it turns "which model" into a secondary question behind "how much reasoning does this specific task actually need." Teams that treat effort level as a first-class routing decision, rather than leaving every request at a single default, are the ones actually capturing the cost and quality gains this generation shipped.

References and Sources

[1] Anthropic. "Introducing Claude Sonnet 5."

[2] Anthropic. "Introducing Claude Opus 5."

[3] TechCrunch. "Anthropic launches Claude Sonnet 5 as a cheaper way to run agents."

[4] DataCamp. "Claude Sonnet 5: Features, Benchmarks, and Pricing."

[5] Snell, Lee, Xu, Kumar. "Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters."

[6] Eden AI. "Claude Opus 5 Benchmarks: Scores, Pricing & Routing."

[7] MarkTechPost. "Anthropic Claude Sonnet 5 vs Sonnet 4.6 vs Opus 4.8: Agentic Coding Benchmarks, API Pricing, and Cost-Performance Tradeoffs Compared."

[8] Geeky Gadgets. "Claude Opus 5 Review: Coding and Benchmark Results."

[9] Lenny's Newsletter. "Claude Opus 5 review: this model is brilliant (but annoying)."