Claude Opus 5 Released: Benchmarks, Pricing and API Changes

Anthropic shipped Claude Opus 5 on July 24, 2026, and the pitch is unusual for a frontier release: it costs exactly what Opus 4.8 costs. Same $5 per million input tokens, same $25 per million output. What changes is what you get for that money, and a few API defaults that will quietly break code you wrote for the older model. We put claude-opus-5 head to head against Opus 4.8 on real Terraform, Kubernetes, and Bash work through the Claude API on July 25, 2026, one day after release, and verified every claim below against the live API and the official docs.

This review covers the Claude Opus 5 specs and pricing, the benchmark claims from the official announcement, our own tested results with real linters as the judge, and the migration gotchas for anyone calling the model from scripts, pipelines, or Claude Code. If you compared notes when Sonnet 5 landed, this is the other half of the Claude 5 rollout story.

Claude Opus 5 specs and pricing

Opus 5 slots between Sonnet 5 and Fable 5 in the current lineup. Anthropic positions it as coming close to Fable 5’s frontier intelligence at half the price, and the spec sheet backs the framing:

The May 2026 knowledge cutoff is worth pausing on. It is the freshest cutoff in the whole lineup, four months ahead of Fable 5, which matters for anything involving recent tooling releases, provider APIs, or Kubernetes deprecations. There is also a fast mode that runs roughly 2.5x faster at twice the base price. It is a research preview for now, waitlist-gated on the API, and reachable through usage credits in Claude Code, so do not build a latency budget around it before your account has access.

You can confirm the limits yourself from the Models API:

curl -s "https://api.anthropic.com/v1/models/claude-opus-5" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" | jq '{id, max_input_tokens, max_tokens, effort: .capabilities.effort, thinking: .capabilities.thinking}'

The response confirms the 1M input window, the 128k output ceiling, and one detail the announcement glosses over: the old enabled thinking type is gone entirely on this model.

{
  "id": "claude-opus-5",
  "max_input_tokens": 1000000,
  "max_tokens": 128000,
  "effort": {
    "supported": true,
    "low": { "supported": true },
    "medium": { "supported": true },
    "high": { "supported": true },
    "xhigh": { "supported": true },
    "max": { "supported": true }
  },
  "thinking": {
    "supported": true,
    "types": {
      "enabled": { "supported": false },
      "adaptive": { "supported": true }
    }
  }
}

If your code sets thinking: {type: "enabled"} with a token budget, that request shape does not carry over. More on the migration traps further down.

What Anthropic claims on benchmarks

The announcement leads with agentic coding numbers. On Frontier-Bench, Anthropic says Opus 5 surpasses every other model and more than doubles Opus 4.8’s score at a lower cost per task. On CursorBench at max effort it lands within half a percent of Fable 5 while costing half as much per token. The ARC-AGI 3 claim is the boldest: three times the score of the next best model.

The agentic numbers follow the same pattern. On OSWorld, the computer-use benchmark, Opus 5 reportedly beats Fable 5’s best result at just over a third of the cost, and its Zapier AutomationBench pass rate runs about 1.5x the next best model at the same spend. Science workloads gain too, with organic chemistry up 10.2 percentage points over Opus 4.8 and protein sequence prediction up 7.7.

One honest caveat Anthropic includes: on the OSS-Fuzz security evaluations, Opus 5 identifies vulnerabilities about as well as Mythos 5, the restricted-access sibling of Fable 5, but remains substantially behind it at developing exploits for what it finds. Vendor benchmarks are marketing until reproduced, so we ran our own comparison.

Opus 5 vs Opus 4.8 on real DevOps work

Both models got identical prompts through the raw Messages API at their default settings, which is exactly what a team migrating model IDs would experience. Three tasks: write an OpenTofu VPC module with per-AZ NAT gateways and input validation, fix a Kubernetes Deployment we had seeded with six bugs, and write a defensive log rotation script. Real tools judged the output, not us. The whole verification loop ran from one terminal: query the Models API, inspect the per-request thinking spend, then hand the generated code to the linters.

Here is how each task went.

Terraform: Opus 5 passes tflint clean, Opus 4.8 does not

Both modules passed tofu validate on the first try. The linter separated them:

tflint --chdir=tfcheck-claude-opus-4-8

Opus 4.8’s module drew two warnings that would fail a strict CI gate:

2 issue(s) found:

Warning: terraform "required_version" attribute is required (terraform_required_version)

Warning: Missing version constraint for provider "aws" in `required_providers` (terraform_required_providers)

Opus 5’s module came back with zero tflint findings. It pinned the provider, declared required_version, and wrote four input validation blocks where Opus 4.8 wrote one, including a dedicated check that the CIDR really is a /16 with its own error message. It reads like code written by someone who has been burned by an unpinned provider before. The trade-off: 301 lines against 194, and 28 seconds of generation against 19.

Kubernetes: both fix all six bugs, Opus 5 fumbles the formatting

The seeded Deployment had a deprecated apps/v1beta2 apiVersion, a selector that did not match the pod labels, a quoted containerPort, a lowercase 512mi memory limit, a liveness probe aimed at the wrong port, and a misspelled configMapReff. Both models fixed all six, and both corrected manifests came back identical, valid under kubeconform -strict.

Opus 5 lost the round anyway. Despite an explicit instruction to return raw YAML with no markdown fences, it wrapped the output in a ```yaml block, which made kubeconform reject the file until we stripped the fences. Opus 4.8 followed the instruction exactly. If your pipeline pipes model output straight into kubectl apply, that is not a cosmetic bug, so keep your fence-stripping guard in place even on the newer model.

Bash: both shellcheck-clean, very different philosophies

Both log rotation scripts passed shellcheck with zero findings. Opus 4.8 delivered a tight 42-line script that met the requirements. Opus 5 delivered 150 lines with a usage function, a die() helper, readonly variables, and double the protected-path guards. Which one you prefer depends on whether you are pasting into a cron job or committing to a repo your team maintains. We would commit the Opus 5 version.

What the meter said

Same per-token price does not mean same bill. Opus 5 thinks by default and writes longer, more defensive output, and both show up in the usage numbers:

Across the three tasks Opus 5 cost about twice as much as Opus 4.8 in practice, roughly $0.14 against $0.07, because thinking tokens bill as output and the model simply writes more. The API now itemizes this: usage.output_tokens_details.thinking_tokens appears in every response, so you can see exactly how much of your bill is reasoning overhead. Notice it spent 244 thinking tokens on the Terraform task, 130 on the debugging task, and zero on the Bash script. The model decides per request whether the problem deserves deliberation, which is adaptive thinking working as designed.

The API changes that can break your Opus 4.8 code

Swapping the model string is not the whole migration. Three behavior changes caught our attention, and we reproduced each against the live API.

First, thinking is now on by default. A request with no thinking field ran without thinking on Opus 4.8; the same request on Opus 5 runs with adaptive thinking enabled. Since max_tokens caps the total of thinking plus visible text, a workload tuned to a tight max_tokens can now hit the ceiling mid-answer. Revisit that parameter before you flip the model ID.

Second, you can still disable thinking, but only at effort level high or below. Combining disabled thinking with xhigh or max effort returns a 400. We hit the endpoint to confirm:

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-opus-5","max_tokens":1024,"thinking":{"type":"disabled"},"output_config":{"effort":"xhigh"},"messages":[{"role":"user","content":"hi"}]}'

The API rejects it with an explicit message:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "output_config.effort 'xhigh' is not supported when thinking is disabled on this model. Use effort 'high' or below, or enable thinking."
  }
}

Third, a few quieter changes reward attention. The minimum cacheable prompt drops from 1,024 tokens to 512, so short system prompts that never cached before now can, with no code change. Two beta headers landed alongside the release: server-side-fallback-2026-07-01 paired with the fallbacks: "default" request parameter re-runs classifier-refused requests on a fallback model automatically (Opus 4.8 for cyber-category refusals), and mid-conversation-tool-changes-2026-07-01 lets you add or remove tools between turns without invalidating your prompt cache. On the losses side, the web fetch tool is not available on Opus 5 and Priority Tier commitments do not cover it yet.

Two dates to put in your calendar. Claude Opus 4.1 retires on August 5, 2026, and Anthropic’s migration guide points those workloads at Opus 5. And if your prompts still carry self-verification boilerplate from older models, the guide now recommends removing it: Opus 5 checks its own work, and stacked verification instructions make it over-verify, which you pay for in output tokens. In Claude Code the model is available immediately, and the token usage discipline matters slightly more now that reasoning tokens ride along by default.

Should you move off Opus 4.8?

For coding and infrastructure work, yes, with one eye on the meter. In our testing the quality delta was real: CI-clean Terraform with pinned providers against lint warnings, and scripts we would actually commit. The per-task cost roughly doubled at the same sticker price, and the fence-wrapping miss proves the output still needs the same guardrails you already have. Teams on Opus 4.1 have no decision to make, only a deadline. Teams on Opus 4.8 with tight latency budgets should test fast mode before switching, since default Opus 5 was consistently slower in our runs. Everyone else gets a smarter model for the same rate card, a fresher knowledge cutoff than anything else in the lineup, and a migration that takes an afternoon if you read the breaking changes first.