Claude Opus 5 Landed at the Top of Every Leaderboard. The Interesting Part Is Not the Score.

Claude Opus 5 Landed at the Top of Every Leaderboard. The Interesting Part Is Not the Score.

Anthropic shipped Claude Opus 5 yesterday, July 24, 2026. By the time I checked Hacker News this morning it had 1,669 points — the highest I have seen for a model launch story in months. The Artificial Analysis leaderboard already had it ranked #1 at an Intelligence Index of 61, ahead of Fable 5 (60) and GPT-5.6 Sol at max effort (59). On Frontier-Bench v0.1 it reportedly more than doubles Opus 4.8’s performance. On ARC-AGI 3, which tests novel problem-solving, it scores three times higher than the next-best model. On Zapier’s AutomationBench it passes around 1.5 times as many tasks as the next-best model for the same cost per task, and at its lowest effort setting it still passes more tasks than any competing model.

All of that is real and matters. But I have been sitting with the announcement for several hours now, and I think the community is focused on the wrong number. The leaderboard position is a footnote. The engineering decision that will actually change how you build is the effort settings system, and nobody is talking about it with the specificity it deserves.

What “Effort Settings” Actually Is

Opus 5 ships with five discrete effort levels: low, medium, high, xhigh, and max. These are not cosmetic. They are a continuous knob over reasoning compute — the model literally thinks harder or less hard based on your instruction. The pricing and latency data from Artificial Analysis makes this concrete:

Look at what is happening here. At low effort, Opus 5 scores 51 on the Intelligence Index — a number that would have been frontier territory eighteen months ago — for $0.36 per task and a 13-second response. At max effort it costs $2.03 and takes 72 seconds. The intelligence gap between low and max is 10 points. The cost gap is 5.6x. The latency gap is over 5x.

This is not a marketing feature. It is a fundamental shift in how you model inference cost in production. The mechanism Anthropic is exposing here is control over how much extended thinking the model does before producing output. At low effort, the model produces answers using the same fast pattern-matching that drives conventional inference. At max effort, it is running a longer internal reasoning chain — thinking through the problem, backtracking, checking its own work — before writing a single output token. The difference in quality is real, and so is the difference in cost and time.

I want to be precise about what this means at a systems level. When you set effort to low, you are essentially running Opus 5 as a very capable non-reasoning model. The 51 Intelligence Index at low effort is not meaningfully lower than Claude Sonnet 5 non-reasoning (42 on the same index). When you set effort to max, you are running what is effectively a frontier reasoning model that sits at the top of every independent benchmark. Same model binary, same API endpoint, same behavioral quirks — just different compute budget per request.

Why This Breaks the Existing Mental Model

Until now, the standard architecture for AI-powered products was: pick the smartest model you can afford, route cheap tasks to a smaller model. You had Haiku for classification and routing, Sonnet for most tasks, Opus for the hard stuff. The problem with this approach is that model switching is brittle. Different models have different failure modes, different instruction-following behaviors, and different latency profiles. Every model boundary in your system is a potential inconsistency.

I have watched teams spend weeks calibrating routing logic — building classifier layers that decide whether a given request deserves the expensive model — only to discover that the classifier itself has a non-trivial error rate. When the classifier sends a hard question to Haiku, you get a bad answer. When it sends a simple question to Opus, you overpay by 20x. The ground truth label for “is this task hard enough to warrant Opus?” is inherently ambiguous, and model-switching architectures force you to commit to a binary that does not match reality.

The problem compounds in agentic workflows. An agent that uses a cheap model for planning and an expensive model for execution will eventually produce plans that the expensive model cannot faithfully execute, because the planning model does not accurately predict what the execution model can and cannot do. I have debugged this exact failure pattern in production systems more than once. The agent produces a perfectly reasonable plan from the cheap model’s perspective, and then the expensive model gets partway through execution, realizes the plan has an implicit assumption it cannot satisfy, and either hallucinates or fails. The root cause is that the two models do not share a coherent world model.

Effort settings on a single model eliminate that boundary. Instead of “send this to Haiku or Opus,” you set effort based on what you know about the task category, and you stay on the same model throughout. The behavioral consistency you get from a single model — same instruction-following quirks, same context handling, same output format tendencies — is worth more than most engineers realize until they have debugged a system where two different models are arguing with each other’s outputs.

The operational simplification is also real. One model means one set of system prompts to maintain, one set of rate limits to track, one set of error responses to handle, one behavioral profile to document for your team. Multi-model architectures are conceptually appealing but operationally expensive. Every additional model in your stack is another thing that can change when the provider pushes an update.

The Real Numbers on the Cost Tradeoff

Let me make this concrete with the actual Artificial Analysis data. Opus 5 at low effort (Intelligence Index: 51, $0.36/task) sits comfortably above Claude Sonnet 5 non-reasoning (42, $0.37/task). You are paying essentially the same price and getting a materially smarter model. That comparison alone should make product teams reconsider their default tier selection.

Opus 5 at medium (56, $0.62) beats Opus 4.8 at max (56, $1.80) at one-third the cost. This is the most practically significant number in the entire announcement. If you are currently running Opus 4.8 for your production workloads, switching to Opus 5 at medium gives you the same Intelligence Index score for one-third the price. The catch is that Intelligence Index is an aggregate; there will be specific task categories where the distribution of performance differs between the two. But as a starting point for your migration decision, “same intelligence at one-third the cost” is a compelling prior.

Opus 5 at high (59, $1.06) is where it gets interesting relative to the competition. GPT-5.6 Sol at high scores 56 for $0.45 — cheaper, but lower intelligence. GPT-5.6 Sol at max scores 59 for $1.04 — same intelligence at a very similar price. At that price point they are essentially tied on the Intelligence Index, and the decision comes down to task-specific performance, latency tolerance, and which behavioral profile fits your application. Opus 5 high has a 30-second total response time versus 161 seconds for GPT-5.6 Sol at max. If you can operate at Opus 5 high effort and get the same intelligence as GPT-5.6 Sol max at roughly the same cost, you also get much faster responses.

The quote from Cursor’s co-founder Sualeh Asif is telling: “Claude Opus 5 delivers near Fable 5 intelligence at Opus speed and cost.” That is not a press quote — that is a product architecture statement. Cursor is using Fable 5 as the reference for their hardest coding tasks. If Opus 5 at max approaches that level at half the cost, it means the model tier boundary between Opus and Fable is narrowing in ways that will reshape pricing across the industry.

Lovable’s co-founder Fabian Hedin made the more operationally significant observation: “It isn’t just better on our hardest agentic coding tasks, up 22% over Opus 4.7, it’s steadier, with far less variance run-to-run. For the millions of builders on Lovable, that consistency is the whole game. Reliable results, build after build.” Variance reduction in agentic workflows is genuinely hard to measure and easy to undervalue. When an agent runs 50 steps and one step fails because the model had an off day, debugging that failure is expensive. Predictable behavior at a given effort level is a feature that does not show up in aggregate benchmark scores.

What the Benchmark Stories Are Not Telling You

Three of the Frontier-Bench anecdotes in the Anthropic announcement deserve more attention than they are getting, because they reveal something about the model’s architecture that benchmark numbers cannot capture.

The first: on a task where the model was given a drawing of a machine part and asked to write code to reconstruct it as a 3D FreeCAD model, Opus 5 was intentionally given no way to directly view the drawing. It responded by writing its own computer vision pipeline to extract geometry from raw pixels, then reconstructed the full machine part. It succeeded repeatedly. No competing model with the same setup could solve it after five attempts.

This is not a benchmark story. This is a story about a model that, when faced with a missing tool, built the tool. That capability — recognizing a gap in its own environment and instrumenting around it — is what differentiates an agent that gets stuck from one that completes. The formal name for this is metacognitive task decomposition: understanding not just what needs to be done, but what capabilities are required to do it and whether those capabilities are available. Most agents I have seen in production fail at exactly this point. They receive an instruction, determine they cannot complete it directly, and either hallucinate a solution (pretend they completed the step), fail silently, or produce an error that the orchestrating system cannot handle gracefully.

Opus 5 apparently did none of those things. It understood that viewing the drawing was a prerequisite for the task, determined that the viewing capability was absent, built a substitute capability from available primitives, and completed the task. That is a different capability class than “can solve hard math problems.”

The second anecdote: given a real bug in a popular open-source package manager, Opus 5 found the root cause and fixed an edge case that the community’s existing patch had missed. The competing model fixed only the surface symptom and reported the bug resolved. This is a standard failure mode I recognize from code review work. The fastest answer is often the wrong one, and models that stop at the first plausible fix create bugs that are harder to find than the original — because now the obvious symptom is gone and only the edge case remains. A model that argues with the community patch and digs deeper is genuinely useful in a different way than one that just produces code quickly.

The third: a trading firm engineer used Opus 5 to build a market data feed for a new exchange in a single session, including building its own test harness because no live feed was available to validate against. Previous models could not complete the task at all. What I find significant here is the test harness part. Building a test infrastructure to validate your own output when the ground truth is unavailable is a second-order capability that most models skip. They produce code that looks correct, describe what it should do, and move on. Opus 5 apparently understood that the absence of a live feed was a validation problem, not just a missing dependency, and addressed it proactively.

The Safety Architecture Is More Interesting Than It Looks

Anthropic’s approach to cybersecurity capabilities on Opus 5 is worth examining carefully, because it represents a more sophisticated policy position than “refuse anything that sounds dangerous.”

They intentionally avoided training Opus 5 on cyber tasks, but acknowledge it has still improved substantially on them through general capability gains. On OSS-Fuzz, their internal cybersecurity benchmark, Opus 5 is close to Mythos 5 at identifying software vulnerabilities, but substantially behind on developing exploits for those vulnerabilities. The distinction between finding a vulnerability and exploiting it is where they are drawing the line.

The practical implementation: binary-based vulnerability scanning, penetration testing, and exploit generation are blocked. Source code vulnerability analysis is allowed. When the classifier triggers on Opus 5 or Fable 5, API users can configure automatic fallback to Opus 4.8 rather than receiving a refusal. The Cyber Verification Program (CVP) provides verified security researchers and enterprises with a less restricted version of Opus 5.

From an engineering perspective, this is a more useful approach than blanket refusals. The classifier is explicitly tuned to be proportionally less restrictive than Fable 5 — Anthropic states they expect it to intervene 85% less often than the Fable 5 classifier. That is a stated policy parameter, not an accident. Security teams that want to use Opus 5 for defensive work — vulnerability scanning in source code, threat modeling, detection engineering — can do so without hitting constant refusals, while the exploitation path remains gated behind the CVP process.

The alignment result is worth noting as well: on Anthropic’s automated behavioral audit, Opus 5 scores 2.3 on overall misaligned behavior — the lowest of their recent model family, lower than Fable 5, lower than Sonnet 5. Higher capability and lower misalignment in the same model is not guaranteed. The typical pattern in capability development is that as models become more capable, they also become more capable of pursuing misaligned goals more effectively. The fact that Anthropic is reporting lower misalignment scores at higher capability — and publishing the number rather than burying it — suggests they have some confidence in the methodology. I would want to understand their behavioral audit methodology in more detail before taking that number at face value, but the direction is the right one.

A Note on the New API Features

Two features shipped alongside Opus 5 that have received essentially no coverage despite being architecturally significant.

The first is mid-conversation tool changes on the Claude Platform. Within a conversation, developers can now change which tools Claude can access without invalidating the prompt cache. This sounds like a minor API convenience, but it enables a class of agentic architectures that were previously impractical to build efficiently.

Consider a common pattern in enterprise automation: an agent that needs to first read from a system to understand the state of the world, then decide whether to write back to it, then potentially escalate to a more privileged write operation. In the old API model, you had two choices: give the agent all the tools upfront (including the privileged write), which creates a scope creep problem; or restart the conversation context when you need to upgrade the tool set, which means you pay to re-tokenize everything and lose the prompt cache benefits. Neither option is great.

Mid-conversation tool changes let you do something cleaner: start the agent with read-only tools, let it build up a cached understanding of the system state, then grant write access only after the agent has determined that a write is appropriate, without losing the cached context. For workflows that run for many turns — the kind of multi-day project management use case Anthropic highlights in the announcement — this is not a marginal improvement. It is the difference between building that workflow economically or not building it.

The second feature is automatic fallbacks on the API. Users can configure requests flagged by safety classifiers on Opus 5 or Fable 5 to automatically route to another model rather than returning a refusal. This is operationally significant for any team building a product on top of frontier models, because safety classifier false positives are a real problem in production. When a user asks a legitimate question that happens to pattern-match on a classifier’s triggers, the current behavior is a hard refusal that the user sees directly. With automatic fallbacks, you can route that request to a slightly less capable model that might handle it without triggering the classifier, giving the user a response rather than a wall.

The implementation details matter here and Anthropic has not published them in full. Specifically, I would want to know how the fallback decision is made (does the user see any indication they are on a fallback model?), how billing works when a fallback is triggered, and whether the fallback is configurable to a specific model or automatically selected. These questions will determine whether automatic fallbacks are a useful safety net or a footgun that makes it harder to reason about what model your users are actually interacting with.

Comparing the Competitive Landscape Honestly

Let me put Opus 5 in honest context against its nearest competitors, because the benchmark comparisons in the announcement are self-serving in the usual ways.

Against GPT-5.6 Sol: At max effort, Opus 5 scores 61 versus Sol’s 59, at $2.03 versus $1.04 per task. On pure intelligence per dollar at max, Sol wins. At xhigh effort, Opus 5 scores 60 for $1.56 versus Sol’s 59 for $0.68 at xhigh — Sol is still substantially cheaper for similar intelligence. Where Opus 5 wins is total response time: 43 seconds at xhigh versus 77 seconds for Sol xhigh. If your application can tolerate 43 seconds but not 77, Opus 5 xhigh is the right call. If cost is your primary constraint, Sol is harder to beat at the high-to-xhigh range.

Against Kimi K3: Intelligence Index of 57 for $0.95 per task, but 238 seconds total response time. For any synchronous workload, Kimi K3 is not viable at its current latency. For batch processing — scientific research, overnight report generation, data analysis pipelines — it is competitive on price and intelligence. I expect Kimi K3 to maintain a significant position in the batch processing market where Opus 5’s pricing is hard to justify for large-scale workloads.

Against open weights models: GLM-5.2 at max sits at Intelligence Index 51 — the same as Opus 5 at low effort. If you can run your own inference infrastructure, you are getting Opus-5-low level intelligence at whatever compute costs you pay, with no per-token billing. The gap between the best proprietary models and the best open weights is now around 10 Intelligence Index points at the top end. That gap is real, but it is smaller than it was, and for use cases that do not need frontier intelligence — which is most use cases — open weights at 51 is a serious option.

Against Claude Fable 5: Anthropic positions Opus 5 as “close to Fable 5 intelligence at half the cost.” The Artificial Analysis numbers roughly bear this out — Fable 5 with fallback scores 60 at $2.75 per task, versus Opus 5 max at 61 for $2.03. The intelligence advantage has essentially reversed. Fable 5 used to be the clear intelligence leader; now Opus 5 at max is marginally ahead at lower cost. For Anthropic’s internal product lineup, this creates an interesting tension: if Opus 5 is cheaper and smarter than Fable 5 on most tasks, what is Fable 5’s remaining differentiation? The answer appears to be specific high-risk capability domains — biology research and offensive cybersecurity — where Fable 5 retains the edge, intentionally.

The Effort Architecture as a Signal About Where the Industry Is Going

The reason I keep coming back to effort settings is that it represents a design philosophy that I think is going to spread across the industry, and understanding it now will give you a head start on building correctly for the next 18 months.

The old model of AI product development was: pick the best model you can afford, treat it as a black box, and wrap it with prompt engineering and guardrails. The model itself was essentially a fixed capability unit. You could tune the prompts, but you could not tune how much the model reasoned about your request.

Effort settings are an admission that reasoning compute is a dial, not a binary. The model can reason more or less depending on how much time and money you are willing to spend. This is true of all modern reasoning models — o3, DeepSeek R1, Kimi K3 all have some form of reasoning budget control — but Opus 5’s implementation is the most explicit and fine-grained I have seen deployed to production at scale.

The implication for product architecture is that you need to think about effort as a first-class product decision, not an afterthought. Different task categories within the same product warrant different effort levels. A coding assistant that is helping with initial scaffolding can probably run at effort medium. The same assistant doing final code review before a production deployment should run at effort high or xhigh. A security audit of a new library should run at max. Building the routing logic that makes those decisions correctly — and doing it without the complexity of model switching — is the engineering challenge that effort settings create.

The practical question I would be asking right now, if I were building on Opus 5, is: what is my effort budget per user session, and how do I allocate it across the tasks in that session? The answer to that question is where product differentiation will come from in 2027. Not from which model you use — everybody will be using the same frontier models — but from how intelligently you allocate reasoning compute across the different tasks your users actually need.

My Actual Predictions on How This Changes Deployments

Here is what I think happens over the next six months, stated in terms that can be falsified.

First, routing architectures that rely on model-switching between tiers will start collapsing into single-model deployments with effort settings. The teams that have the most routing complexity — enterprise AI platforms with classifier layers between cheap and expensive models — will find that Opus 5 at medium effort outperforms their routed Sonnet-4.8 baseline while costing less than their Opus-4.8 heavy traffic. I expect to see public case studies on this by Q1 2027. If I am wrong about this, the likely reason is that the Intelligence Index gap between Opus-5-medium and dedicated smaller models is too small to justify the per-task cost premium in high-volume production scenarios.

Second, the practical floor for “serious work” will shift from Sonnet to Opus-low. Opus 5 at low effort (Intelligence Index: 51) for $0.36 per task is more capable than what most teams are running at Sonnet prices today. If this pricing holds — Anthropic has kept Opus 5 at the same price as Opus 4.8, $5 per million input tokens and $25 per million output tokens — the era of using Sonnet as the default “smart enough” model for general tasks is probably ending within the next two model generations.

Third, Zapier’s AutomationBench result is the one I am watching most carefully. Opus 5 at its lowest effort setting passed more tasks than any other model. If that holds across the broader class of business automation tasks — the kinds of multi-step, stateful workflows that enterprise buyers actually want — then the “effort settings unlock a new architecture” story is real, not just a benchmark artifact. The benchmark to watch is not ARC-AGI 3. It is AutomationBench, because that is where the commercial stakes are highest.

Fourth, the mid-conversation tool changes feature will enable a class of progressive-escalation agents that become standard patterns in enterprise AI by mid-2027. The pattern is: start with read-only tools, use cached context to understand state, escalate to write-capable tools only when action is warranted, optionally escalate further to privileged operations with human approval in the loop. If I am wrong about this prediction, the likely reason is that the latency cost of the extra API roundtrips for tool escalation makes the pattern impractical in most production environments.

Fifth, GLM-5.2’s position at 51 on the Intelligence Index with open weights will attract significant enterprise interest for on-premises and private cloud deployments. By the end of 2026, at least three major enterprise software vendors will announce integrations built on open-weights models at the 50+ Intelligence Index tier, specifically as an alternative to API-based frontier models. If I am wrong, the likely reason is that the operational complexity of running inference infrastructure at scale outweighs the cost and privacy benefits for most enterprise buyers.

One Thing That Concerns Me

The latency at max effort — 62 seconds to first token, 72 seconds total — is a hard constraint for anything user-facing. That is a number you can only deploy in fully asynchronous workflows, where the user submits a request, gets a confirmation, and receives the result when it is ready. The xhigh setting at 34 seconds to first token is still too slow for interactive use unless you are streaming and the user has an exceptionally high tolerance for waiting.

I want to be honest about what this means: the most capable version of Opus 5 is not a conversational model. It is a batch reasoning system that happens to share a name with a conversational model. You deploy it for the same use cases where you would deploy an overnight analysis job — complex document review, comprehensive code audits, scientific literature synthesis — not for the interactive back-and-forth that most user-facing AI products involve.

The 13-second total response at low effort is the number I would focus on for user-facing work. That is borderline acceptable for synchronous interactions where the user is waiting for a response, and the 51 Intelligence Index means you are not compromising dramatically on capability relative to what was frontier two years ago. The real question is whether low effort consistently produces outputs that match what your users need, or whether you will find edge cases where the model takes shortcuts that the reduced reasoning budget reinforces into systematic errors.

Compare this to GPT-5.6 Terra at medium, which scores 46 for $0.18 per task at a 6.6-second total response. For user-facing workloads where speed matters more than frontier intelligence, Terra medium is a more practical option than Opus 5 low, both on cost and latency. Anthropic’s model family has always prioritized quality over speed at every tier, and Opus 5 continues that tradition. It is a deliberate product decision, not an oversight — but it does mean that the frontier intelligence gains in Opus 5 are largely inaccessible to products where user experience requires sub-10-second responses.

What I Am Actually Changing in My Own Approach

I want to be concrete about what this announcement changes for me personally, rather than just offering abstract architectural observations.

I use Claude heavily for research synthesis and writing analysis. My current setup uses Opus 4.8 for substantive analytical tasks. Switching to Opus 5 at medium effort gives me the same Intelligence Index score as Opus 4.8 at max, at one-third the cost. That is the easiest migration decision I have made in a long time. I will make that switch immediately and run it for two weeks to see if the medium effort level produces qualitatively equivalent outputs on the specific tasks I use it for.

For longer, more complex analytical tasks — the kind where I want the model to work through implications carefully and catch its own errors — I will experiment with high and xhigh effort. The Anthropic announcement’s claim that “it catches its own mistakes, so senior engineers can delegate their hardest coding work with confidence” is testable, and I intend to test it on a specific class of analysis tasks where I currently spend significant time reviewing and correcting model outputs.

The mid-conversation tool changes feature is directly relevant to a workflow I have been wanting to build for several months: a research agent that starts by reading a set of sources in read-only mode, builds up a cached understanding, then transitions to writing mode where it synthesizes findings into a structured document. The current tooling made this inconvenient to implement without paying to re-tokenize context at each stage. If the mid-conversation tool change API works as described, I will build that workflow in the next two weeks and report back on whether the practical implementation matches the announcement.

Claude Opus 5 is a real step up. The benchmark positions are genuine, the anecdotes from enterprise customers are consistent with what I would expect from a model with significantly better metacognitive capabilities, and the effort settings architecture is a meaningful innovation in how frontier AI is deployed. But the most valuable thing in the announcement is not the Intelligence Index number. It is the set of architectural primitives — effort as a continuous dial, mid-conversation tool changes, automatic fallbacks — that will shape how production AI systems are built over the next 18 months. That is what I will be paying attention to.