The One Opus 5 Setting Nobody Talks About Is Already Costing You

Opus 5 Got Cheaper to Think Hard, and That Changes Your Architecture

Every post about Opus 5 today covers the same ground: state of the art on Frontier-Bench, close to Fable 5 on CursorBench at half the price. Those numbers hold up. There is a more interesting story sitting underneath them, about what happens to an infrastructure bill once a model gets this good at deciding when to think and when to just answer.

Opus 5 launched today at the same $5 input and $25 output price per million tokens as Opus 4.8. Same price, meaningfully higher intelligence, a 1M token context window, and adaptive thinking that defaults to high effort on the API and inside Claude Code. That detail is worth sitting with, because it functions less like a benchmark number and more like a billing behavior.

Effort Is the Story Here

Buried inside the launch notes is a single setting most coverage skips past: adaptive thinking defaults to high effort, on by default, both on the API and inside Claude Code. Nobody has to turn this on. It just runs that way unless a team explicitly caps it.

That default is not a small detail. CodeRabbit's testing put a number on it: per review call, Opus 5 read about 60.5k input tokens and wrote about 9.5k output tokens on average, against roughly 40.5k in and 5.8k out for GPT-5.6 doing the same task.

At Opus 5's $5 input and $25 output pricing, that extra token volume adds a real premium to every single call, before anyone touches the effort dial.

For a chat interface, that shift stays invisible. For a production agent running thousands of calls a day, it becomes one of the largest cost variables in the stack, and it's set to "on" the moment a team starts using the model.

Independent Testing Confirms the Tradeoff

CodeRabbit put Opus 5 through roughly 100 verified error patterns pulled from open source pull requests, comparing effort levels against their production reviewer mix. Their numbers give the effort default some measurable weight. At x-high effort, Opus 5 produced a cleaner actionable comment stream than baseline, 39.3% precision versus 35.2%, but caught fewer known issues, 55.2% versus 61.1%. Higher effort bought precision at the cost of coverage, and the trade held across their runs rather than improving everything at once.

Token usage is where a meaningful share of the cost premium comes from, since every call carries a bigger context in and a longer answer back.

Effort scaling turned out to be uneven rather than linear. The medium-effort configuration caught the most issues overall but produced 110 nitpicks and lower full-stream precision. High effort wrote less output than medium, while x-high wrote more, so assuming higher effort always means a better or more expensive answer would be the wrong read. Nitpick volume climbed roughly fourfold over baseline at x-high, which adds review time for anyone downstream filtering the output before it reaches a developer or another agent.

Reading the Cybersecurity Fallback as a Routing Decision

Anthropic built Opus 5 to reroute cybersecurity-sensitive prompts to Opus 4.8 automatically. Most coverage frames this purely as a safety feature. It also works as a routing decision happening inside an inference stack, one worth planning for at the infrastructure layer from the start.

If an agent occasionally touches code review, log analysis, or anything exploit-adjacent, a portion of Opus 5 traffic lands on Opus 4.8 instead, with its own cost and latency profile. Teams benchmarking Opus 5 in isolation and then deploying to production benefit from accounting for this fallback path in their cost models early, since it shapes production numbers differently than a clean test run. The same pattern showed up with Fable 5, where benign security work occasionally triggered elevated safeguards, though less often with Opus 5.

Reading the Benchmarks Like an Infrastructure Engineer

Anthropic's numbers show Opus 5 outperforming every model at any given cost point on OSWorld 2.0, a benchmark built around computer use rather than pure reasoning, surpassing Fable 5's best result at roughly a third of the cost. That number deserves priority attention for anyone building agents that operate tools, browsers, or terminals, because it works as a cost efficiency claim as much as an intelligence claim. A model that is smart and a model that is smart per dollar spent are two different products, and OSWorld 2.0 measures the second one.

The organic chemistry and protein function gains, up 10.2 and 7.7 points over Opus 4.8, respectively, are the kind of numbers that get buried under coding benchmarks but carry weight for anyone serving life sciences workloads. This signals training investment in domains many competitors have largely skipped.

Builder Versus Reviewer: Two Different Jobs

Opus 5 makes a stronger case as a builder than as a reviewer. One of their engineers described it as calmer than earlier Opus models, taking time to clarify goals and offering several credible approaches on open-ended projects. On larger agentic tasks, it coordinated hundreds of background agents with improved design judgment over Opus 4.8, though it remained slower and more cautious around security-adjacent work than Fable 5.

As a reviewer, Opus 5 x-high reads more like a specialist than a generalist. It is strong on configuration errors and code quality, spotting integration details and maintainability problems well, but weaker on logic errors, race conditions, and API misuse. That makes it a useful second opinion on correctness-heavy or concurrency-heavy changes, paired with a broader, recall-oriented reviewer rather than standing in alone.

What the Community Is Weighing

The loudest pre-launch conversation centered on naming and trust as much as capability. Weeks of leak threads speculated Anthropic might skip the Opus 5 name entirely in favor of the Mythos tier. That speculation reflects something familiar: developers remember releases that shifted personality and formatting behavior with little warning, like the more formal, memo-style outputs some noticed with Opus 4.7 that shaped writing-heavy workflows differently than expected.

The community's interest, once the dust settles, centers on whether the model behaves predictably at scale and whether the effort default matches the budget teams planned for.

What This Means If You Are Building on GMI Cloud

Model selection is increasingly becoming effort-level selection. Teams getting the best economics out of Opus 5 are the ones profiling which parts of their pipeline genuinely need high effort reasoning, and which parts can shift to a cheaper, capable option now available.

GMI Cloud hosts Opus 5 alongside 200+ models on GPU infrastructure built for this kind of mixed-effort, mixed-model routing.

A short checklist for testing Opus 5 on your own pipeline before rollout:

• Test every effort level you plan to use, including low and medium, rather than assuming higher effort scales cleanly

• Compare a restrictive prompt against a broader report-then-filter approach, since narrow instructions can suppress useful findings

• Tune conciseness and severity settings before developers get used to skimming past the noise

• Measure how verification instructions affect runtime, tokens, and cost, and trim what doesn't earn its keep

• Break down misses by category and severity so you know where a second, recall-oriented model needs to sit alongside it

Try it with curl:

curl https://api.gmi-serving.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $GMI_API_KEY" \
-d '{
"model": "anthropic/claude-opus-5",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Hello!"}
]
}'

Route the hardest reasoning work to Opus 5. Route everything else to a model priced for the effort level the task needs. That is the game right now, separate from which model tops a leaderboard this week.

Try It on GMI Cloud

Opus 5's OpenAI-compatible API means any team already calling an LLM endpoint through GMI Cloud's serverless inference can swap in Opus 5 with a one-line model change, the same pattern GMI has used for the entire Claude lineage.

Start with the playground at console.gmicloud.ai to run a prompt, move to the serverless API for pay-as-you-go testing, and benchmark the workload itself, token usage, latency, and cost, before committing to a dedicated deployment.