Claude Opus 4.6: Features, Benchmarks & Pricing

Opus 4.6 moves beyond the standard 200,000 token limit to a massive 1M token context window. This is roughly 700,000 words, enough to hold an entire corporate document library or a complete codebase in memory.

Two caveats matter before you rearchitect anything around it. The 1M window shipped as a beta on the Claude Platform rather than as a general default, initially gated to higher usage tiers, and it carries its own price. Requests whose input exceeds 200,000 tokens move onto a premium band at $10 (£7.40) per million input tokens and $37.50 (£27.80) per million output, double and roughly 1.5 times the standard rate respectively. Anything under 200K bills at the ordinary price, so the long window costs nothing until you actually use it.

The MRCR v2 figure is the one worth understanding properly, because it is what separates a large context window from a usable one. MRCR v2 is a multi-round co-reference retrieval test: the model is asked to find and correctly attribute specific material buried among many near-identical distractors across the full window. It is deliberately much harder than classic needle-in-a-haystack, which is why Sonnet 4.5 collapses to 18.5% on the 8-needle 1M variant while Opus 4.6 holds 76%. In practical terms, that is the difference between a model that technically accepts a million tokens and one that can still reason over what it read at token 900,000.

The workloads this unlocks are specific rather than universal. Whole-repository reasoning, long-running agent sessions that would previously have needed aggressive summarisation, discovery-style document review, and multi-hour coding tasks where the accumulated diff history is itself important context. For ordinary chat and short coding turns, the standard 200K window remains both cheaper and entirely sufficient.

Opus 4.6 introduces adaptive thinking, replacing the old manual budget system. The model now dynamically decides when and how much to think based on task complexity.

There are four effort levels: low, which skips extended reasoning almost entirely for straightforward requests; medium; high, which is the default and the setting Anthropic recommends for most production traffic; and max, reserved for the hardest problems where latency and token spend are secondary to getting the answer right. The published ARC-AGI-2 result, for instance, was produced at max effort with a 120,000 token thinking budget, which is a useful reminder that headline benchmark numbers are often set at a configuration nobody runs in production.

The practical benefit of adaptive thinking is that it removes a tuning decision that developers were consistently getting wrong in both directions. Set budget_tokens too low and the model was cut off mid-reasoning on genuinely hard tasks; set it too high and every trivial request paid for deliberation it did not need. Handing depth allocation to the model turns a fixed cost into a variable one that tracks task difficulty, which on mixed workloads is both cheaper and more accurate.

The trade-off is predictability. If your application depends on tight, consistent latency, a model that may decide to think for a long time on an unusually awkward input is harder to plan around than one with a hard ceiling. Capping the effort level is the lever to reach for there, and it is worth exercising early rather than discovering the variance in production.

Available as a research preview, Fast Mode delivers up to 2.5x faster output generation. It's the same frontier intelligence running on optimized inference infrastructure.

Anthropic opened Fast Mode to the public on 07/02/2026, two days after the model itself, describing it as an early experiment and noting that its own teams had been building with a 2.5x-faster build of Opus 4.6 internally. It ran with a 50% introductory discount ($15/$75 per million tokens) for the first week or so before settling at the full rate. At $30 (£22) input and $150 (£111) output per million tokens, that is a 6x multiple on standard Opus 4.6 pricing for identical intelligence, delivered faster.

In Claude Code it is toggled with the /fast command rather than an API parameter. One detail catches people out and is worth internalising: switching Fast Mode on mid-conversation re-bills your entire existing context at the uncached input rate. Flipping it on fifty thousand tokens into a session is an expensive way to speed up the next reply. Enable it at the start of a session if you know you will want it, and leave it off otherwise.

Whether the premium is worth paying is genuinely workload-dependent. For an interactive coding loop where a human is sitting waiting, halving the wait on every turn can pay for itself in attention alone. For batch work, background agents or anything where nobody is watching the cursor blink, the same money buys six times as much ordinary Opus 4.6, which is almost always the better trade.

The figures below are Anthropic's published results for the launch configuration, with GPT-5.2 as the closest competitive reference point at the time of release. They are vendor-reported, so treat them as a map of where Anthropic believes the model is strong rather than as independent replication.

Two things stand out. The first is that the gains are not uniform: Opus 4.6 wins decisively on agentic coding, browsing and abstract reasoning, and loses on multimodal understanding, where GPT-5.2 and Gemini 3 Pro both score higher. If your product is image-heavy, the frontier leader on paper is not necessarily the right pick.

The second is that SWE-bench Verified is now effectively saturated as a differentiator. Opus 4.6 at 80.8% is statistically indistinguishable from Opus 4.5 at 80.9%, and Anthropic's own reporting averages over 25 trials to reach 80.9%, which tells you how much run-to-run variance sits inside that number. Where 4.6 pulls away from its predecessor is on the harder, longer, more agentic evaluations: Terminal-Bench 2.0 climbs from 59.8% to 65.4%, OSWorld from 66.3% to 72.7%, BrowseComp from 67.8% to 84.0%, and ARC-AGI-2 from 37.6% to 68.8%. That pattern, flat on classic coding and sharply up on sustained tool use, is the honest summary of this release.

One figure that circulated widely deserves a correction. There is no official METR time-horizon measurement for Opus 4.6. The hour-count figures shared on social media in February 2026 were independent extrapolations from published benchmark results, produced with item response theory rather than METR's own task suite, and their authors were explicit that the estimates were provisional and likely optimistic. Anthropic's own claim is qualitative: the model sustains agentic tasks for longer. Treat any specific hour figure as unverified.

Opus 4.6 was clearly optimised for agents rather than chat, and the tool-use benchmarks bear that out. On τ2-bench, which evaluates multi-turn tool calling against a simulated user, it scores 91.9% on the retail split and 99.3% on telecom, ahead of both Opus 4.5 and GPT-5.2. On OSWorld, which measures computer use in a real desktop environment, it reaches 72.7% against 66.3% for its predecessor. On Finance Agent, a domain-specific agentic evaluation, it scores 60.7%.

There is one genuine regression, and it is worth knowing about before you deploy. On MCP Atlas, which tests coordination across many Model Context Protocol tools, Opus 4.6 scores 59.5% against Opus 4.5's 62.3%. That is a small drop, but it runs against the direction of every other agentic number in the set, and it lands in exactly the place that matters for teams building large MCP tool surfaces. The mitigation is orchestration logic at the application layer: keep the tool set presented to any single call small and well-described rather than exposing several dozen tools and expecting the model to route perfectly.

Combined with the 1M context window, the practical shape of a well-built Opus 4.6 agent is a long-lived session with a narrow, carefully curated tool set and plenty of accumulated history, rather than a short session with an enormous tool catalogue. That is close to the opposite of how most 2025-era agent frameworks were designed, and it is the main reason teams migrating from earlier models often see disappointing results until they rethink the harness. Our guide to Claude Code workflows covers the same principle from the practitioner side.

The most commercially interesting result is not a coding benchmark at all. GDPval-AA measures performance on economically valuable professional knowledge work, scored as an Elo rating, and Opus 4.6 posts 1606. That is roughly 144 points clear of GPT-5.2 and about 190 points clear of Opus 4.5, which in Elo terms is not an incremental improvement but a different tier of expected win rate against the same opponents.

Domain evaluations point the same way. Opus 4.6 scores 90.2% on BigLaw Bench, a legal-work evaluation, and 91.3% on GPQA Diamond, the graduate-level science question set, up from 87.0% for Opus 4.5. On Humanity's Last Exam it reaches 40.0% without tools and 53.0% with them, the highest figure among frontier models at release.

ARC-AGI-2 deserves its own note because the jump is so large: 37.6% to 68.8% in a single generation, against 54.2% for GPT-5.2 and 45.1% for Gemini 3 Pro. ARC-AGI-2 is specifically constructed to resist memorisation, rewarding the ability to infer a novel rule from a handful of examples. A near-doubling on that benchmark is the strongest evidence in the release that adaptive thinking is doing real work rather than simply spending more tokens. The caveat, again, is that the published score was set at max effort with a very large thinking budget, so it represents the model's ceiling rather than its default behaviour.

• ✕
  Prefilling is gone: Assistant message prefilling is not supported on Opus 4.6. Migrating to structured outputs is required.
• !
  Output Tokens: Maximum output tokens doubled to 128K. SDKs require streaming for large requests to avoid timeouts.

The prefill removal is the one that breaks running code rather than merely degrading it. On earlier Claude models it was common to seed the start of the assistant turn, typically an opening brace, to force JSON output or to pin a response format. On Opus 4.6 that request returns a 400 error outright. The supported replacements are structured outputs, which constrain the response to a schema directly, or moving the formatting instruction into the system prompt. Neither is difficult, but both require a code change, so audit for prefill usage before switching the model identifier in production.

The output-token change is subtler. Doubling the ceiling to 128K means a single request can now legitimately run long enough to exceed default HTTP timeouts, which is why the SDKs require streaming above a threshold rather than allowing a blocking call. If your service currently buffers a complete response before returning it, that assumption needs revisiting alongside any retry logic, since a partially streamed long response is a different failure mode from a clean timeout.

Everything else is additive. The model identifier is claude-opus-4-6, tool definitions, the Model Context Protocol and prompt caching all behave as before, and the effort parameter is optional with a sensible default. For most codebases the migration is a model string change, a prefill audit and a streaming check.

The headline standard rate is unchanged from Opus 4.5, which is the quiet story of this release: a substantially more capable model at the same price per token. Sterling figures are indicative conversions of dollar list prices, and UK customers should assume VAT on top.

Three levers materially change what you actually pay. Prompt caching is the largest for agentic workloads, where a long, stable system prompt and tool schema are resent on every turn. Batch processing halves the rate for anything that does not need a synchronous answer, which covers most evaluation, classification and bulk document work. And effort control is now a cost lever in its own right: dropping from high to low on routine traffic cuts thinking tokens directly, and thinking tokens bill at the output rate.

On availability, Opus 4.6 shipped simultaneously across the Anthropic API, AWS Bedrock, Google Vertex AI and Microsoft Foundry, as well as claude.ai for Pro and Team subscribers. That matters for enterprise buyers who need the model inside an existing cloud commitment rather than on a separate Anthropic contract. For consumer plan pricing rather than API rates, see our Claude pricing guide.

Opus 4.6 is the right default if your workload is agentic: long-running coding sessions, computer use, deep web research, or professional knowledge work where the GDPval-AA gap translates into fewer rejected drafts. It is also the obvious choice for anything that genuinely needs to reason across a very large body of text, because the MRCR v2 result shows the long context is usable rather than merely available.

It is the wrong default for high-volume, low-complexity traffic. Classification, extraction, routing and short-form generation do not benefit from frontier reasoning and will cost five times what a Sonnet-class model charges to do the same job. The mature pattern in 2026 is a tiered stack: a cheap model for the bulk, Opus for the hard calls, with the routing decision made in your own code rather than delegated to the most expensive model in the estate.

If you are migrating, the honest expectation is that classic coding benchmarks will look flat while sustained agentic work improves noticeably. Budget an afternoon for the prefill and streaming changes, leave effort at the default of high, and resist enabling Fast Mode until you have measured whether latency is genuinely your bottleneck. For the longer technical treatment, including Anthropic's own evaluation methodology, see our Opus 4.6 deep dive.