Claude Opus 5: What I’d Measure Before Switching My Coding Agents

The interesting part of Claude Opus 5 isn’t just the benchmark jump. It’s the claim that a model priced like Opus 4.8 can handle work that previously justified paying for Fable 5.

Anthropic’s July 24, 2026 release puts Opus 5 at $5 per million input tokens and $25 per million output tokens, with a 1M-token context window. That is half Fable 5’s standard token pricing. The reported gains cover coding, knowledge work, reasoning, and long-running agents.

For me, that makes it a candidate for expensive agent workloads—not an automatic replacement for every model in a routing table. I’d evaluate it on completed jobs, retries, and latency rather than token prices alone.

Start with the API contract

Here are the specifications I’d want in front of me before planning a migration, as listed in the Anthropic model documentation:

Property	Claude Opus 5
Release date	July 24, 2026
API model ID	claude-opus-5
Standard input / output pricing	$5 / $25 per million tokens
Context window	1M tokens, default and maximum
Maximum synchronous output	128K tokens
Message Batches output limit	Up to 300K tokens through beta support
Knowledge cutoff	May 2026
Thinking	Adaptive thinking enabled by default
Effort settings	low, medium, high, xhigh, max
Default effort	high
Fast mode	Approximately 2.5× generation speed at $10 / $50 per million tokens
Fast mode availability	Claude API only, research preview
Data retention	Supports zero data retention

Opus 5 sits below the Fable 5 / Mythos 5 frontier tier released in June 2026. Anthropic positions it as the everyday premium option for complex agentic coding and enterprise work.

It is also the default model on Claude Max and the strongest option on Claude Pro. Its May 2026 knowledge cutoff makes it the most current Claude model in the reported lineup.

Those are useful defaults, but the operational changes matter more to an agent implementation than the product positioning.

The migration details I’d check first

The Opus 5 changes documentation describes several changes that affect request configuration and orchestration.

Thinking is no longer an opt-in assumption

Adaptive thinking is enabled by default. The effort dial controls how much work the model puts into a response:

• low
• medium
• high, the default
• xhigh
• max

Higher effort improves reported performance on difficult tasks, but consumes more tokens and adds latency. Disabling thinking is restricted at the highest effort levels.

I wouldn’t migrate an existing agent and immediately set everything to max. I’d compare effort settings on the same task set first. Lower effort may already beat the older model while preserving the economics that make the migration worthwhile.

Tool definitions can change during a conversation

A beta feature allows tools to be added or removed mid-conversation without invalidating the prompt cache.

That is relevant to staged agents: a workflow can change which tools are available as it moves between phases. The reported benefits are better cache economics and tighter control over tool access.

I’d explicitly test both cache behavior and tool availability across those transitions rather than treating this as a transparent change.

Safety blocks can trigger model fallback

The API can automatically route a request blocked by a safety classifier on Opus 5 or Fable 5 to another suitable model, allowing a helpful response instead of an error.

For a production system, I’d want to know when that routing happened. A completed request is useful, but model substitution should be accounted for when evaluating output quality and behavior.

Large context and large output are separate limits

The full 1M-token context window is available by default and is also the maximum. Synchronous output tops out at 128K tokens; Message Batches can reach 300K with beta support and the required beta header.

Anthropic reports strong instruction following and reasoning across the large context window. I’d still test the actual document and repository layouts my application sends. Context capacity is not, by itself, a workload evaluation.

Fast mode buys latency, not cheaper tokens

Fast mode is a Claude API research preview offering approximately 2.5× the default token-generation speed at twice the standard price.

That means $10 per million input tokens and $50 per million output tokens. I’d reserve it for latency-sensitive paths rather than asynchronous work where standard pricing and batching are more attractive.

What the benchmark claims actually say

The reported results are strong, but they mix Anthropic evaluations, third-party reporting, and less precisely quantified observations. I’d keep those distinctions intact.

Evaluation	Opus 5	Fable 5	Opus 4.8	Reported context
Frontier-Bench v0.1	43.3%	33.7%	18.7%	Reported state of the art; more than twice the prior Opus score
GDPval-AA v2	1,861 Elo	1,747 Elo	Lower	Professional knowledge work
CursorBench 3.2	Within 0.5% of Fable’s peak	Peak reference	—	Opus at max effort, roughly half the cost per task
ARC-AGI 3	Approximately 30.2%	—	Approximately 1.5%	Reported as 3× the next-best result
SWE-bench Verified	96.0%	95.0%	88.6%	Software engineering
SWE-bench Pro	79.2%	80.3%	69.2%	Software engineering
Zapier AutomationBench	Approximately 1.5× the next-best pass rate	—	—	End-to-end business tasks
OSWorld 2.0	Strong; some reports put it above Fable’s best at roughly one-third the cost	—	—	Computer use

Two things stand out to me.

First, “near Fable” does not mean uniformly below Fable. Opus 5 has higher reported scores on Frontier-Bench, GDPval-AA, and SWE-bench Verified, while Fable retains the higher SWE-bench Pro result.

Second, effort settings belong next to benchmark numbers. The CursorBench comparison uses max effort. It isn’t evidence that every default request will land within the same margin.

The qualitative reports are also relevant to coding agents:

• More complete multi-file changes and large refactors, with fewer stubs.
• Better self-verification, correction, judgment, and consistency.
• Stronger persistence on long-horizon tasks.
• Better multi-agent coordination with fewer conflicts.
• Improved diagrams and generative visualizations.

Reported improvements extend to financial modeling and scientific tasks, including protein sequence effects and molecular structure inference. Some internal evaluations describe fewer turns and lower latency.

Anthropic also describes Opus 5 as its most aligned Claude model to date, with reduced deceptive behavior. I’d treat that as a reported model property, not a reason to remove application-level controls.

The cost calculation I care about

Standard token pricing is unchanged from Opus 4.8:

Billing mode	Input per million tokens	Output per million tokens
Standard	$5	$25
Fast mode	$10	$50

Prompt caching and batching change the effective bill. Cache hits are priced at $0.50 per million tokens, cache writes cost more than ordinary input, and the Batch API offers a 50% discount.

The more useful comparison is cost per successful job. A model can justify a higher per-token price if it needs fewer attempts, fewer tool turns, or less generated output to finish the same work.

Reports describe 26% fewer tokens for equivalent reasoning quality, alongside time savings on multi-step professional tasks. Those claims are worth testing, but I wouldn’t apply that percentage to a budget without measuring my own workload.

For context, the source’s approximate standard pricing comparison is:

Model	Input / output per million tokens	Context	Where I’d consider it
Haiku 4.5	Approximately $1 / $5	200K	High-volume, simple tasks
Sonnet 5	Approximately $2–3 / $10–15	1M	Everyday advanced work
Opus 5	$5 / $25	1M	Complex coding, agents, knowledge work
Fable 5	$10 / $50	1M	Ambitious long-horizon agents; public Mythos-class capability
Mythos 5	Restricted pricing and access	1M	Specialized high-risk research

Provider and gateway pricing can differ. I’d also keep synchronous requests, batch jobs, and cache-heavy sessions separate in cost reports; a single blended token rate hides too much.

Where I’d use it—and where I wouldn’t

My first evaluation targets would be tasks where failed attempts are expensive:

• Repository-scale engineering: multi-file features, refactors, root-cause debugging, and long-running coding sessions.
• Document-heavy knowledge work: research synthesis, financial models, and multi-step business automation.
• Scientific reasoning: biology and chemistry workflows where the reported gains match the task.
• Production agents: systems that benefit from stronger persistence, verification, and tool coordination.

That includes workflows built around Claude Code, Cursor, or custom agent frameworks. Biology-related requests blocked on higher models may also route to Opus 5.

I wouldn’t default to it for simple chat or high-volume, low-complexity processing. Haiku or Sonnet remain the more natural candidates there. At the other end, the hardest cybersecurity or long-horizon research problems may still justify Fable or Mythos, where access and use are appropriate.

Choosing an access path

Opus 5 is available through:

• Claude.ai web and apps.
• The Claude API, using claude-opus-5.
• Amazon Bedrock.
• Google Cloud Vertex AI / Gemini Enterprise Agent Platform.
• Microsoft Foundry.
• Third-party gateways.

Bedrock offers zero data retention by default in supported regions. Opus 5 also supports zero data retention more broadly, unlike the reported constraints around Fable 5.

For a genuinely multi-provider application, a unified API such as CometAPI can consolidate billing and routing across 500+ models, with OpenAI-style chat completions and Anthropic Messages support, including applicable effort/thinking controls. Check the gateway’s current model listing, exact identifier, pricing, and feature coverage before switching.

I’d prefer direct Anthropic or cloud-provider access when native feature availability, regional residency, or zero-data-retention guarantees without an intermediary are requirements.

My rollout criterion: better completed work

I’d put Opus 5 behind an evaluation route before making it the default:

1. Replay representative coding and knowledge-work tasks.
2. Compare effort settings rather than testing only max.
3. Track success rate, retries, tool turns, tokens, and elapsed time.
4. Test cache preservation when changing tools.
5. Evaluate Fast mode separately from standard and batch execution.
6. Review fallback behavior alongside the system card and safety documentation.

The reported combination is appealing: near-frontier capability, unchanged Opus pricing, and API changes that fit real agent workflows. But the migration only pays off if it improves completed work in the system I actually run.

---

Originally published at cometapi.com