Claude Opus 5 Explained: Architecture, Benchmarks and Deployment (2026)
On 24 July 2026, Anthropic shipped Claude Opus 5 and quietly moved the goalposts for what a frontier model costs to run. It kept the price of its previous top model, held the context window at a full million tokens with no long-context surcharge, and posted a 96.0% score on SWE-bench Verified — the kind of number that used to justify a price premium, not the absence of one. The result is a model positioned near the intelligence tier of much pricier rivals while charging roughly half as much for output.
This post is a durable reference for that specific model: what Anthropic has actually disclosed, what remains deliberately secret, what the benchmarks say, and how to deploy it without overpaying. It is not a survey and not marketing. Where a figure is unpublished, this page says so rather than guessing.
What this covers: lineage, the disclosed architecture and the parts that are not disclosed, training signals, sourced benchmarks, pricing and deployment paths, honest failure modes, and a decision matrix against three peer models.
Context and Background
For two years the frontier-model market has run on a simple assumption: the smartest models cost the most to call. Anthropic’s own line reinforced it — each Opus generation sat at the top of the price sheet, with cheaper Sonnet and Haiku tiers underneath for latency-sensitive or high-volume work. Buyers learned to route: Opus for the hard reasoning, Sonnet for the bulk, Haiku for the trivial.
Claude Opus 5 complicates that mental model. It arrives as the new default on the Claude Max consumer plan and the strongest model available on Claude Pro, which signals that Anthropic now treats near-frontier reasoning as the baseline experience rather than a paid upgrade. On the API it costs the same as the model it replaces, so the old “Opus is the expensive one” heuristic no longer maps to a capability cliff. The competition has been pushing the other direction — chasing raw benchmark leadership at rising prices — which is exactly the gap Anthropic is targeting.
The broader context is agentic coding. Over 2025 and 2026 the industry’s flagship benchmark shifted from trivia-style knowledge tests toward SWE-bench and its harder variants, which measure whether a model can resolve real GitHub issues inside real repositories using tools. That is the terrain Opus 5 is built to win, and it is why so much of Anthropic’s messaging centers on coding agents and computer use rather than on essay quality. For a fuller treatment of the protocol layer that makes these agents portable across tools, see our explainer on the Model Context Protocol architecture. Anthropic’s own Claude platform documentation is the primary source for the specifications discussed below.
What Claude Opus 5 Actually Is: Reference Architecture
Claude Opus 5 is Anthropic’s closed, hosted frontier model released on 24 July 2026, exposed through the API as claude-opus-5. It offers a one-million-token context window as both default and maximum, up to 128,000 output tokens on the synchronous Messages API, a per-request effort control, adaptive extended thinking that is on by default, and native tool and computer use — all at $5 per million input tokens and $25 per million output tokens.
That direct-answer paragraph is the whole model in one breath. The rest of this section unpacks the parts you can actually reason about, and the diagram below draws the request path from prompt to output alongside the internals Anthropic has chosen not to reveal.
Figure 1: The Claude Opus 5 request path — context intake, effort control, adaptive thinking, tool use, and output limits — with the undisclosed internal architecture shown as a separate, sealed box.
Figure 1 reads top to bottom. A request enters claude-opus-5, is placed in a context window that holds up to one million tokens, passes through an effort setting that governs how much reasoning compute the model spends, runs adaptive extended thinking, optionally calls tools including the computer-use action set, and emits up to 128,000 tokens synchronously or up to 300,000 through the Batch API. The lower box lists what Anthropic does not publish — parameter count, dense-versus-mixture layout, attention variant, and tokenizer — connected by a dashed “unknown internals” edge to make the boundary explicit.
The context window is a genuine million tokens, at no premium
The headline specification is the context window. Claude Opus 5 accepts up to one million tokens of input, and — this is the important part — that figure is both the default and the maximum. There is no separate long-context tier, no beta header to unlock it, and no per-token price step-up once a prompt crosses some threshold. On several earlier frontier models, large contexts either required an opt-in flag or triggered a higher rate above a boundary such as 200,000 tokens. Opus 5 removes that complexity: a 20,000-token prompt and an 800,000-token prompt are billed at the same $5 per million.
The practical consequence is architectural. Teams that previously built elaborate retrieval pipelines to keep prompts under a limit can, for many workloads, simply put the whole corpus in the window — an entire service’s source tree, a full contract set, a quarter of support tickets. That does not make retrieval obsolete, and it does not make long contexts free of accuracy risk (more on that in the failure-modes section), but it removes the pricing penalty that used to force premature summarization.
Effort control is the cost-capability dial
The second disclosed lever is the effort control: a per-request setting of low, medium, or high that governs how much reasoning compute the model spends before answering. Some launch reporting also described an “xhigh” mode for the most demanding problems; treat that label as reported rather than as an official tier confirmed in the core documentation. The API defaults effort to high, which is unusual — most providers default to their cheapest, fastest setting.
Effort is not a different model; it is the same weights spending more or less time thinking. Low effort suits routine transformation and classification where latency matters and the answer is not deeply contingent. High effort suits multi-step debugging, planning, and anything where a wrong-but-confident answer is expensive. Because the dial is per request, a single application can send trivial calls at low effort and hard calls at high effort without maintaining two integrations.
Adaptive extended thinking is on by default
Third, Opus 5 uses adaptive extended thinking by default. Rather than forcing a fixed reasoning budget, the model adapts how much internal deliberation it does to the difficulty of the task. This pairs naturally with the effort control: effort sets the ceiling, adaptive thinking decides how much of that ceiling a given prompt actually needs. For developers migrating from a model where extended thinking was an explicit, separately toggled feature, the shift is that reasoning is now the baseline behavior, not an add-on you remember to switch on.
Tool use and computer use are native, not bolted on
The fourth pillar is the agent surface. Opus 5 ships with the enhanced computer-use action set — Anthropic references it as computer_20251124, which includes actions such as zoom — and strong instruction following across long tool-calling sequences. Computer use means the model can drive a graphical interface by reasoning over screenshots and issuing mouse and keyboard actions, but with an important boundary: your application must implement the actual screenshot capture and input execution. Claude requests an action; your harness performs it and returns the result. The model never touches your machine directly.
This matters for how you think about the model’s ceiling. The coding and multimodal scores are not abstract intelligence measurements; they are proxies for how well the model plans, calls tools, reads results, and recovers from errors across many turns. A model that is brilliant in a single response but loses the thread over a fifty-step agent loop is not useful for the workloads Opus 5 targets. The design emphasis here — adaptive thinking, high default effort, native tool use — is coherent precisely because those pieces compound in long agentic sessions. If you are wiring Opus 5 into an agent, the portability layer to reach for is the Model Context Protocol, which standardizes how the model discovers and calls external tools without hard-coding each integration.
Lineage, Training Signals and Benchmarks
Claude Opus 5 is the current top of a fast-moving series. The lineage runs Opus 4.6 to Opus 4.8 to Opus 5, and it ships as a matched pair with Claude Sonnet 5, the mid-tier sibling covered in our Claude Sonnet 5 deep-dive. Readers who want the prior Opus generation for comparison can consult our Claude Opus 4.6 architecture and capabilities analysis. Understanding that cadence matters: point releases in this family arrive months apart, so any specific benchmark number is a snapshot, not a permanent fact.
What changed versus Opus 4.8
The clearest deltas from Opus 4.8 are not architectural claims — Anthropic does not frame them that way — but capability and platform changes. Coding scores rose, multimodal agentic performance jumped sharply, the model became the default on Claude Max, and prompt caching got cheaper to enter, with the minimum cacheable prefix dropping to 512 tokens from 1,024. Pricing held flat. Put plainly: same sticker, more capability, and a lower barrier to caching savings.
Training: what is reported and what is not
Figure 2: A schematic of the training stages every modern frontier model passes through. For Claude Opus 5, the pretraining scale and objective are not disclosed; the post-training stages are described in general terms and labeled as reported.
Figure 2 traces the generic pipeline — pretraining corpus, pretraining objective, base model, supervised fine-tuning, reinforcement learning from feedback, agentic and tool-use training, safety and alignment tuning, shipped model — and marks which stages Anthropic actually characterizes. This is where honesty matters most, because it is the section other write-ups are most tempted to invent.
Here is the hard boundary. Anthropic does not publicly disclose Claude Opus 5’s parameter count, whether it is a dense model or a Mixture-of-Experts design, its attention variant, its tokenizer or vocabulary size, or the composition and scale of its training data. None of those numbers appear in the official documentation, and any source presenting a specific figure for them is speculating. This page will not repeat such guesses.
What is reasonable to say, at the level Anthropic and standard practice support, is directional. The model has a knowledge cutoff of May 2026 — the most current of any Claude model at launch — which tells you the pretraining data extends at least to that date. The post-training clearly includes heavy investment in agentic and tool-use behavior, given the coding and computer-use results, and in safety and alignment tuning consistent with Anthropic’s published safety framework. Describe those as reported directions, not as disclosed hyperparameters. The exact objectives, data mix, and compute budget remain undisclosed.
Benchmarks, as sourced
Figure 3: Claude Opus 5’s reported coding benchmark results as of July 2026 — SWE-bench Verified, SWE-bench Pro, and SWE-bench Multimodal — with the qualitative meaning of each.
Figure 3 summarizes the numbers that matter most for the model’s positioning, all in the SWE-bench family because that is where Opus 5 is aimed. The reported results are:
| Benchmark | Claude Opus 5 (reported) | What it measures |
|---|---|---|
| SWE-bench Verified | 96.0% | Resolving verified real GitHub issues with tools |
| SWE-bench Pro | 79.2% | Harder, longer-horizon repository tasks |
| SWE-bench Multimodal | 59.4% (up from 38.4%) | Issues requiring visual/UI understanding |
Read these carefully. SWE-bench Verified at 96.0% is a frontier-class agentic-coding result and the headline the launch leaned on. SWE-bench Pro at 79.2% is strong but not a clean sweep — reporting around launch noted that at least one rival edged Opus 5 on Pro, a reminder that “best on Verified” and “best everywhere” are different claims. The most striking delta is SWE-bench Multimodal: the jump from 38.4% on the prior Opus to 59.4% is far larger than the coding gains, and it is the single best evidence that the multimodal and computer-use training in this generation did real work.
A methodology caveat belongs here. SWE-bench scores depend heavily on the agent scaffold, the number of allowed attempts, and the exact test split; a headline percentage is only comparable when the harness is held constant, which across vendors it rarely is. Treat these figures as reported by Anthropic and corroborated by early third-party coverage, and weight your own evaluation on your own repositories above any published number. The canonical description of the benchmark and its splits lives at the SWE-bench project site.
There is also a benchmark-hygiene point worth stating plainly. SWE-bench Verified is a curated subset that human annotators confirmed to be solvable and well-specified, which is why scores on it run higher than on the raw or Pro variants. A 96.0% on Verified does not translate to 96% of arbitrary real-world tickets resolved; production issues are messier, under-specified, and often require touching code the model never sees. The gap between Verified and Pro — roughly sixteen points here — is a decent proxy for how much harder your unfiltered backlog will be than a clean benchmark. Plan capacity and human-review budgets against the harder number, not the headline.
The multimodal result deserves one more sentence of interpretation. SWE-bench Multimodal issues require the model to understand screenshots, rendered UI, diagrams, or other visual context to produce a fix. The near-21-point jump to 59.4% is the clearest single signal that this generation invested in vision-grounded agent work, and it lines up with the enhanced computer-use action set. If your work involves front-end bugs, visual regressions, or anything where the defect is only visible when rendered, this is the metric to watch — and the one where Opus 5 separates most sharply from its own predecessor.
Access, Pricing and Deployment
Figure 4: How to reach Claude Opus 5 — the Claude API, Amazon Bedrock, and the Claude apps — with the pricing modes that sit under the API path.
Figure 4 lays out the deployment surface. There are three ways in, and one thing you cannot do.
The three access paths are the Claude API (model identifier claude-opus-5), Amazon Bedrock (as anthropic.claude-opus-5), and the Claude consumer apps, where Opus 5 is the default on the Max plan and the strongest option on Pro. The thing you cannot do is self-host: Opus 5 is a closed, hosted model with no open weights. There is no checkpoint to download, no VRAM sizing to plan, and no quantization decision to make. If your requirements include on-premise or air-gapped deployment with model weights under your control, Opus 5 is out and you should be looking at open-weight alternatives such as those in our Kimi K3 reasoning-model deep-dive.
The pricing, precisely
Standard API pricing is $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8. Three modifiers change the effective rate:
- Prompt-cache hits are billed at $0.50 per million tokens — a tenth of the base input rate — which makes caching the single highest-leverage optimization for any workload with a stable prefix. The minimum cacheable prefix is 512 tokens in this generation.
- The Batch API cuts both input and output by 50%, to roughly $2.50 input and $12.50 output per million, for asynchronous work that tolerates a delayed response.
- Fast mode roughly doubles the rate (about $10 input, $50 output) in exchange for approximately 2.5 times the speed, for latency-critical interactive paths.
Output limits scale with the path too. The synchronous Messages API caps output at 128,000 tokens; the Batch API reaches 300,000 tokens when you send the output-300k-2026-03-24 beta header. For a report-generation or bulk-transformation job, batching is therefore a double win — half the token price and more than double the output ceiling — at the cost of latency.
A worked cost example
Concreteness helps. Suppose an agentic code-review job sends a 200,000-token repository context and a 20,000-token instruction set, and receives a 15,000-token review. At standard rates the input costs (220,000 / 1,000,000) x $5 = $1.10 and the output costs (15,000 / 1,000,000) x $25 = $0.375, for about $1.48 per run. Now cache the 200,000-token repo context across a day of reviews: cached input drops to (200,000 / 1,000,000) x $0.50 + (20,000 / 1,000,000) x $5 = $0.10 + $0.10 = $0.20, and the run falls to about $0.58 — a roughly 60% reduction driven almost entirely by the cache. Move the same job to the Batch API and you halve it again. The lesson: on Opus 5, the list price is the starting point, and caching plus batching routinely take real workloads well below it.
One subtlety the worked example hides: output tokens dominate more than they look. Output is priced at five times input, and when adaptive thinking runs at high effort, the model may spend a substantial share of the response budget on internal reasoning tokens before it emits the visible answer. That is usually worth it for hard tasks, but it is why two calls with identical prompts can bill differently, and why lowering effort on simple endpoints reduces cost on the expensive side of the ledger. If your bill is drifting upward, look at output-token volume and effort settings before you look at input.
Latency, throughput and migration notes
Anthropic does not publish fixed latency or tokens-per-second guarantees for Opus 5, and real numbers vary with prompt size, effort, output length, and load. Two directional facts are safe to design around. First, high default effort and adaptive thinking mean first-token and total latency will be higher than a non-reasoning model at the same prompt — budget for it in interactive UIs, or drop to low effort where responsiveness beats depth. Second, fast mode exists specifically to trade money for speed at roughly 2.5x, so a latency-critical path has a lever that does not require changing models. For migration from Opus 4.8, the API surface is largely compatible; the changes to plan for are that effort now defaults to high (audit your cost), extended thinking is on by default (adjust if you relied on it being off), and the prompt-cache minimum dropped to 512 tokens (you may now be able to cache prefixes that were previously too short to qualify).
Trade-offs, Gotchas, and What Goes Wrong
No frontier model is free of sharp edges, and pretending otherwise is how teams end up surprised in production. Here are the specific ones for Claude Opus 5.
Long context is not the same as perfect recall. A one-million-token window means the model accepts that much input; it does not guarantee uniform attention across all of it. On very long prompts, mid-context detail can be under-weighted relative to material near the start or end — the well-documented “lost in the middle” failure that affects long-context models broadly. If a specific fact must drive the answer, place it deliberately and consider a targeted retrieval step rather than trusting a million-token dump to surface it on its own.
High effort is the default, and it costs. Because the API defaults effort to high, a naive integration that fires many small calls will spend more reasoning compute — and more output tokens on thinking — than the task needs. For high-volume, low-complexity endpoints, explicitly setting low or medium effort is a real cost lever, not a micro-optimization. Audit your call mix before assuming the bill is fixed.
“Best on Verified” is a narrow claim. The 96.0% SWE-bench Verified headline is genuine, but SWE-bench Pro at 79.2% shows the model is not uniformly ahead of every rival on every coding split. Do not let one benchmark stand in for a purchasing decision; the split that matches your actual work — long-horizon refactors, multimodal UI tasks, or short bug fixes — is the one to weight.
No weights means no offline story. The closed, hosted nature is a hard constraint, not a preference. Regulated, air-gapped, or data-residency-restricted deployments cannot use Opus 5 the way they can an open-weight model. Bedrock availability helps with some compliance postures but does not change the fact that you never hold the weights.
Undisclosed internals limit deep debugging. Because Anthropic does not publish the architecture, you cannot reason about tokenizer edge cases, attention behavior, or expert routing from first principles the way you can with an open model. When behavior surprises you, you are limited to black-box probing. Build your evaluation harness accordingly and do not assume you can explain every failure mechanistically.
Practical Recommendations
Treat Claude Opus 5 as the default for reasoning-heavy and agentic work, and engineer around its cost levers rather than its list price. Start by routing: send hard, contingent tasks to Opus 5 at high effort, and push genuinely trivial work to a cheaper model or to low effort — do not pay for high-effort reasoning on a formatting call. Then make caching a first-class part of your prompt design: structure prompts so the large, stable material forms a cacheable prefix, and you will often cut input cost by an order of magnitude.
For any workload that tolerates latency — nightly reviews, bulk document processing, evaluation runs — default to the Batch API for the 50% discount and the higher output ceiling. Reserve fast mode for genuinely interactive, latency-critical paths where the 2.5x speed justifies double the price. Finally, verify claims on your own data: run your real repositories and documents through the model before trusting any published benchmark, because the split that matches your work is the only one that predicts your results.
A short checklist:
- Route by difficulty; set effort explicitly instead of accepting the high default everywhere.
- Design a cacheable prefix and confirm cache hits in your billing.
- Use the Batch API for asynchronous jobs; send the
output-300kbeta header when you need long outputs. - Do not architect for offline or air-gapped use — Opus 5 has no open weights.
- Benchmark on your own tasks; treat 96.0% SWE-bench Verified as directional, not decisive.
How Claude Opus 5 Compares
The right question is rarely “which model is best” but “which model wins my use case at my budget.” The matrix below compares Claude Opus 5 against Claude Sonnet 5, Kimi K3, and GPT-5.6 across four common jobs. Ratings are directional guidance for practitioners, not benchmark scores, and reflect the trade-offs discussed above.
| Use case | Claude Opus 5 | Claude Sonnet 5 | Kimi K3 | GPT-5.6 |
|---|---|---|---|---|
| Frontier agentic coding | Best fit — 96.0% SWE-bench Verified, agentic training | Strong, cheaper for bulk coding | Competitive on reasoning; open-weight option | Strong rival; verify on your splits |
| Long-context document analysis | Excellent — 1M tokens, no premium | Good; lower cost per call | Depends on served context limit | Competitive; check context pricing |
| Self-hosted / air-gapped deployment | Not possible — closed, no weights | Not possible — closed, no weights | Best fit — open weights, self-hostable | Not possible — closed, no weights |
| High-volume, cost-sensitive tasks | Use low effort + caching + batch | Often the better default here | Strong if you run your own inference | Compare effective rate after discounts |
Read the matrix as a router, not a ranking. If your work is frontier coding or large-context reasoning and you are comfortable on a hosted API, Opus 5 is the default recommendation, and caching plus batching keep it affordable. If your dominant cost is high-volume, low-complexity calls, Sonnet 5 is frequently the better economic fit within the same ecosystem — the Sonnet 5 deep-dive covers where that line falls. If you need the weights in your own environment for compliance or control, no closed model qualifies and Kimi K3 is the one to evaluate. And if you are already invested in a rival ecosystem, benchmark GPT-5.6 on your exact splits rather than trusting cross-vendor headline numbers, since harness differences make those comparisons unreliable.
Frequently Asked Questions
What is Claude Opus 5 and when was it released?
Claude Opus 5 is Anthropic’s frontier large language model, released on 24 July 2026 and exposed on the API as claude-opus-5. It became the new default on the Claude Max plan and is the strongest model available on Claude Pro. It offers a one-million-token context window, up to 128,000 output tokens synchronously, a per-request effort control, adaptive extended thinking on by default, and native tool and computer use. It is a closed, hosted model with no open weights, positioned as near-frontier intelligence at roughly half the price of comparably capable rivals.
How much does the Claude Opus 5 API cost?
Standard pricing is $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8. Prompt-cache hits are billed at $0.50 per million — a tenth of the base input rate. The Batch API discounts both input and output by 50%, to roughly $2.50 and $12.50 per million. Fast mode roughly doubles the rate for about 2.5 times the speed. The full one-million-token context is included with no long-context premium, so effective cost depends heavily on how aggressively you cache and batch.
How large is the Claude Opus 5 context window?
Claude Opus 5 has a one-million-token context window, and that figure is both the default and the maximum — there is no separate long-context tier, beta header, or price step-up to reach it. Output is capped at 128,000 tokens on the synchronous Messages API and up to 300,000 tokens through the Batch API when you send the output-300k-2026-03-24 beta header. Note that accepting a million tokens is not the same as perfect recall across all of them, so place decision-critical facts deliberately.
What are Claude Opus 5’s benchmark scores?
As reported at launch, Claude Opus 5 scored 96.0% on SWE-bench Verified, 79.2% on SWE-bench Pro, and 59.4% on SWE-bench Multimodal — the last a large jump from 38.4% on the prior Opus. The Verified score is frontier-class for agentic coding, while the Pro result shows it is not uniformly ahead of every rival. Benchmark numbers depend on the agent scaffold and test split, so treat them as directional and validate on your own repositories.
What is the effort control in Claude Opus 5?
Effort control is a per-request setting — low, medium, or high — that governs how much reasoning compute the model spends before answering. The API defaults to high. Some launch coverage also mentioned an “xhigh” mode for the hardest problems, which should be treated as reported rather than officially confirmed as a core tier. Effort is not a different model; it is the same weights thinking more or less. Setting low or medium on high-volume, low-complexity endpoints is a meaningful cost lever.
Can I self-host Claude Opus 5?
No. Claude Opus 5 is a closed, hosted model with no open weights, so there is nothing to download, no VRAM to size, and no quantization to choose. You access it through the Claude API, Amazon Bedrock, or the Claude apps. If your requirements include on-premise, air-gapped, or data-residency-restricted deployment with model weights under your control, Opus 5 does not qualify and you should evaluate open-weight alternatives such as Kimi K3 instead.
Further Reading
- Claude Sonnet 5 explained: architecture and benchmarks — the mid-tier sibling that ships as a series with Opus 5.
- Anthropic Claude Opus 4.6 architecture and capabilities — the prior-generation Opus for lineage comparison.
- Kimi K3 reasoning model deep-dive — the open-weight alternative for self-hosting.
- Model Context Protocol architecture — how agents built on Opus 5 stay portable across tools.
- External: Anthropic Claude platform documentation and the SWE-bench project.
By Riju — about
