Claude Opus 5.2 vs Claude Opus 5 evaluation concept: two equally bright light channels, amber and ice-blue, entering a transparent measurement gate at twilight, with a clear glass loop curving back as a rollback path

model-comparison

Claude Opus 5.2 vs Claude Opus 5: What to Test First

Q: Will Opus 5 still be available if a new Opus ships?

Anthropic lists claude-opus-5 as active with retirement not sooner than July 24, 2027 on the platforms it operates; Bedrock and Google Cloud set their own dates. That does not guarantee any particular gateway route, so test the fallback route you plan to use.

EvoLink Team

Product Team

September 17, 2026

Updated on September 18, 2026

17 min read

Short answer: keep running Claude Opus 5 and start measuring it properly. As of September 18, 2026, "Claude Opus 5.2" exists only in community posts: we found no model, model ID, price, specification, or benchmark for it in Anthropic's documentation, so there is nothing to compare except reports of faster, less "lazy" output inside Claude Code, and no route to switch to. What you can do now is turn those reports into an evaluation that is ready the day a real point release appears and that tells you, in numbers, whether the change deserves your traffic.

This guide is for teams that already run Opus 5 in production. The evidence behind the routing reports, including the traced "Foundry slug", is in Claude Opus 5.2 release date; channel availability, model ID, and pricing status live on the Claude Opus 5.2 API page. The separate next-generation question is in Claude Opus 6 vs Claude Opus 5.

The Decision at a Glance

Question	Claude Opus 5	"Claude Opus 5.2"	What to do now
Officially named?	Yes, released July 24, 2026	No; a community label	Treat it as a watch item, not a roadmap item
Documented API ID?	`claude-opus-5`	None found in Anthropic docs, SDK lists, or Claude Code builds	Do not put a guessed ID in configuration
Price and limits documented?	$5 / $25 per MTok; 1M context; 128K output	Unknown	Budget against Opus 5
Can you run matched tests today?	Yes, through documented channels	No callable candidate	Freeze the baseline and the replay set now
What do users report?	"Lazy", over-thinks, needs "continue" on long tasks	"Way faster", "clean output", "not lazy" (Claude Code only)	Convert each report into a measurable test
Fallback if you ever switch?	Listed as active, retirement "not sooner than July 24, 2027" on Anthropic-operated platforms	Not applicable	Verify the specific EvoLink route you would roll back to

There is no winner because only one column is a documented product. The useful output of this comparison is the evidence a successor must produce.

Claude Opus 5.2 vs Opus 5: Known Differences and Unknowns

Anthropic's models overview, pricing page, release notes, and Claude Code changelog document Claude Opus 5 and nothing newer in the Opus line. Since September 14, several X accounts have reported that Claude Code routes some Opus 5 requests to a newer build. No post includes an identifier or a request record, reports disagree on which apps and plans are affected, and Anthropic has not commented.

Four things that circulate with the reports are covered in full in the release tracker and only summarized here:

the "Foundry claude-opus-5-2.yaml" is a community registry entry whose values equal Opus 5's;
"five effort levels including xhigh and max" is Opus 5's documented ladder today;
an "Opus 5.1" was rumored in August and never released under that name;
asking the model who "Tibo" is reads generated text, not model identity.

One official fact matters for everything below. Anthropic's versioning documentation says model weights are fixed for a given ID, that an updated version "ships under a new model ID", and that serving infrastructure such as the request router and sampling logic can change and is "the most likely cause" of behavior differences on a stable ID. A faster session under the same name is therefore not, by itself, a new model. It also means a real point release would arrive as a new ID that you opt into, which is what makes a controlled evaluation possible.

What Users Report, and What Would Count as Evidence

The reports agree on what changed, which makes them a usable test specification even though they prove nothing about a model.

Community report (Claude Code, September 14–17)	The Opus 5 complaint it answers	What would count as evidence
"way faster" / "overthinks less"	Long thinking before output at high and xhigh effort	Same task set, same effort level: wall time and output tokens per accepted task, over several days
"not lazy", "loves to do longer tasks"	Stopping mid-task and asking the user to continue	User nudges per completed long task; completion rate without intervention
"really clean output" (X); less bloated or over-engineered code (a Reddit thread we could only read second-hand)	Over-engineered or verbose implementations	Diff size versus requested scope; reviewer edits per accepted change
Better on visual and 3D tasks and "getting close to Astra-level", though the same poster still puts Astra ahead	Weaker visual and spatial work	Matched visual tasks with a fixed rubric, if that workload matters to you
A forum user reported having it one evening and losing it again afterwards	Not a complaint; a warning	Any improvement must persist across days and CLI versions before it is a baseline

Which Improvement Is Worth a Switch, by Task

"Better" means different things for different workloads. Decide per task class what you measure first and what size of improvement would justify the migration work. The thresholds are yours; the table only says where to look.

Task class	Measure first	Also watch	An improvement worth switching for
Interactive Q&A and chat	p50 and p95 time to first useful answer	Acceptance rate, output tokens	Latency moves from "users notice" to "users do not", with no drop in acceptance
Repository-scale coding	Test pass rate on accepted changes	Diff size versus requested scope; reviewer edit time	More changes pass tests on the first attempt, and diffs stay inside the requested files
Long-running agents	Completion rate without human intervention	Nudges per task, tool-error recovery, total tokens per completed task	Tasks that needed a "continue" or a rescue now finish unattended, without a token blow-up
Structured extraction	Parse or schema-validation success rate	Retry count, cost per valid record	Fewer invalid outputs at the same or lower cost per valid record
Batch document work	Cost per accepted document	Throughput within the batch window, cache hit rate	Lower cost per accepted document with the deadline still met

If a task class has no measurable problem on Opus 5 today, it has no reason to move, whatever the new model scores elsewhere.

What Claude Opus 5 Already Delivers

Opus 5 is the measurable side of this comparison:

API model ID claude-opus-5, a dateless pinned snapshot;
$5 input and $25 output per million tokens; cache writes $6.25 (5-minute) and $10 (1-hour); cache reads $0.50; batch at half price; research-preview fast mode at $10 / $50 on the Claude API only;
1M-token context with no smaller variant; 128K max output;
adaptive thinking on by default; effort low, medium, high (default), xhigh, max; thinking can be disabled only at high or below;
thinking tokens are billed as output tokens and count toward max_tokens.

On EvoLink, the Claude Opus 5 page lists the current route. Check the documented ID, the returned model field, usage, and billing with your own key before treating it as a baseline.

What Past Opus Releases Changed, Sorted by Impact

Not every change in a release breaks an integration. Keeping the three kinds apart tells you what to re-test.

Release	Date	Documented breaking change	Cost or behavior change	New capability
Opus 4.6	Feb 5, 2026	—	Adaptive thinking introduced	1M context; 128K output; context compaction
Opus 4.7	Apr 16, 2026	Non-default `temperature`, `top_p`, `top_k` return a 400	New tokenizer: the same text counts as more tokens	`xhigh` effort; higher-resolution vision
Opus 4.8	May 28, 2026	—	—	Fast mode; agentic and reasoning gains
Opus 5	Jul 24, 2026	Thinking on by default; disabling thinking at `xhigh` or `max` returns a 400	Thinking tokens billed as output raise output volume at the same rates; longer default responses	512-token cache minimum; mid-conversation tool changes (beta)

All of these releases listed $5 / $25 per million tokens. The gaps between them were 42 to 70 days, and September 18 is day 56 after Opus 5. For the previous generational step, see Claude Opus 5 vs Claude Opus 4.8. Both facts are history, not a forecast: a future point release could bring any of the three kinds of change, or none.

Compatibility Checks Before Any Switch

Surface	What to check	Why
Model identifier	The ID is documented by Anthropic or the cloud channel you use; Bedrock and Google Cloud have their own formats	A guessed string can fail or be aliased by a proxy to an unrelated model
Thinking and effort	Re-run your effort matrix; test the disable path and the 400 behavior	Opus 5 changed both; defaults can move again
Token accounting	Re-measure input, output, and cache tokens per task	Tokenizer and thinking changes alter the bill at an unchanged list price
Sampling parameters	Grep configuration for parameters the model rejects	4.7 turned non-default sampling values into errors
Structured output and tools	Replay parsers and schema validation; inject tool failures	Anthropic's Opus 5 notes say code that reads `content[0].text` must select blocks by `type`, because a response can begin with thinking blocks
Fallback	Log when a fallback served the request and make it an explicit experiment arm	Mixed-model results contaminate the comparison

On identity: logging the returned model field, the request ID, usage, and the invoice is necessary, and it is not independent proof of the underlying weights, because a server or proxy supplies every one of those fields. What you can establish is consistency between the documented ID mapping, the returned metadata, trusted upstream records, and billing. That is enough to make a substitution traceable, which is the practical goal.

The Paired Evaluation

1. Freeze the Opus 5 baseline

Record prompts, tools, effort level, context state, accepted-task rate, wall time, input and output tokens, cache use, retries, reviewer time, and known failure cases. Include the sessions where Opus 5 asked you to "continue" or over-engineered a change; those are the reports' claims, and you need the before numbers.

2. Build three replay groups

known-success tasks, to catch regressions;
known Opus 5 failures (laziness, verbosity, over-thinking), to measure replacement value;
frontier tasks that currently need a human or a different route.

A planned Claude Opus 5 versus Opus 5.2 evaluation sends matching task sets through identical tools and timing checks; the balanced output is an illustration of fair testing, not measured parity

3. Add the candidate only when it is a documented, consistent route

A candidate enters the harness when its ID is published by Anthropic or your cloud channel, an authenticated request succeeds, the returned metadata agrees with the documented mapping, and usage reconciles with the published price. Then use the same prompts, tools, timeouts, effort policy, retry rules, and reviewers as the baseline.

A Worked Cost Example

The number that decides a switch is not total spend. It is what you pay for each task that passes acceptance:

API cost per accepted task = total API spend for the evaluation group ÷ tasks that passed acceptance

Everything the group consumed goes in the numerator: failed attempts, retries, and fallback calls included. Count cache writes and reads as they are actually billed. Thinking tokens are already billed as output tokens, so do not add them a second time. Keep human review time in its own column rather than converting it into API dollars.

The figures below are invented to show the arithmetic. They are not measurements of any model.

	Baseline group	Candidate group
Tasks attempted	100	100
Total API spend, including failures and retries	$12.00	$14.00
Tasks that passed acceptance	80	95
API cost per accepted task	$12.00 ÷ 80 = $0.150	$14.00 ÷ 95 = $0.147
Tasks a person still has to fix or redo	20	5

The candidate group spent $2.00 more and is still slightly cheaper per accepted task, because more of its spend produced usable work. The larger effect is in the last row: fifteen fewer tasks go back to a person. The reverse case is just as real. If the candidate had spent $16.00 for 85 passes, its cost per accepted task would be $0.188, and the extra quality would have to justify a 25% higher unit cost. Run the division before reading the headline numbers.

An Acceptance Record You Can Fill In

Vague gates such as "materially better" or "latency holds" cannot be checked. Write the threshold before the run, from the business requirement of that task class, then record what happened. Copy this table once per task class.

Field	Your threshold (set before the run)	Baseline result	Candidate result	Met?
Task class and replay group	—
Sample size (tasks attempted)	minimum: ____
Pass rate (passed ÷ attempted)	at least ____ % and no lower than baseline on the known-success group
p95 latency	at most ____ s
API cost per accepted task	at most $ ____
Retries and fallback calls per 100 tasks	at most ____
Human fix time per accepted task	at most ____ min
Nudges per long task (agents only)	at most ____
Consistency over ____ days	no threshold missed on any day

A scale-up condition that can be executed reads like this: route 5% of this task class to the candidate when every row is met on at least ____ tasks over ____ days; return to 0% the first day any row is missed. There is no universal threshold. A support bot and a nightly refactoring job should not share one.

Switch by Task, and Test the Way Back

The realistic outcome is a routing policy, not a global switch. Move the task classes that passed their record, in the order of the matrix above, and leave the rest on Opus 5.

A planned Claude Opus 5.2 canary and rollback path: most traffic stays on the amber baseline route, with a small evaluation branch and an explicit return path; this is not a live deployment

The way back needs its own test. Anthropic's deprecations page lists claude-opus-5 as active with retirement "not sooner than July 24, 2027", and says its dates apply to Anthropic-operated platforms (the Claude API, Claude Platform on AWS, and Microsoft Foundry) while Amazon Bedrock and Google Cloud set their own schedules. That is an evaluation window. It does not guarantee the capacity, permissions, or status of the specific route you would fall back to. Before any canary, send real traffic through the Opus 5 fallback route you intend to use, confirm quota and permissions, and rehearse the configuration change that returns traffic to it.

Keep Opus 5 where it already meets your pass-rate, latency, and cost targets, where a migration has no measured upside, or where your logging cannot yet separate primary from fallback calls. Waiting is not passive while you are collecting baselines; it becomes passive only when delivery is blocked for a model that has not been announced.

EvoLink's unified API keeps model choice in routing configuration rather than application code, which makes a challenger cheap to add and cheap to remove. Nothing in this plan requires an Opus 5.2 route to exist today.

Review the current Claude Opus 5 route Get the Claude Opus 5.2 API launch alert

FAQ

Has Claude Opus 5.2 been announced?

We found no mention of it in Anthropic's model catalog, release notes, pricing page, or newsroom as of September 18, 2026. The newest Opus is Claude Opus 5.

Is Claude Opus 5.2 better than Claude Opus 5?

There is no evidence-based comparison, because no documented, callable Opus 5.2 exists. Community reports describe faster and less lazy output inside Claude Code, without a model identifier or measurements.

What do users say Opus 5.2 fixes?

Speed, over-thinking, laziness on long tasks, and verbose or over-engineered code. Those are the right categories for a replay set, and they are claims, not results.

How do I compare cost fairly?

Divide the evaluation group's total API spend, including failures and retries, by the number of tasks that passed acceptance. Compare that figure, not total spend or list price, and report human fix time separately.

Will a newer Opus use up my quota or budget faster?

Unknown until it can be measured. Some users already report higher Opus 5 consumption, and on Opus 5 thinking tokens are billed as output tokens, so a model that thinks more costs more at the same list price. Measure input, output, and cache tokens per accepted task at your effort level. Consumer-plan quotas in the Claude apps are a separate matter from API billing.

Should I wait for Opus 5.2 before starting a project?

No. Use Claude Opus 5 for committed delivery, keep model selection in configuration, and collect the traces that will become your upgrade evaluation.

Can I use the model ID claude-opus-5-2 now?

No. We did not find that identifier in any Anthropic documentation. A guessed ID will fail or, worse, be mapped by a third-party proxy to an unrelated model.

Will Opus 5 still be available if a new Opus ships?

Anthropic lists claude-opus-5 as active with retirement not sooner than July 24, 2027 on the platforms it operates; Bedrock and Google Cloud set their own dates. That does not guarantee any particular gateway route, so test the fallback route you plan to use.

How should I compare the two after a release?

Use matched prompts, tools, timeouts, effort levels, context state, retry rules, and reviewers. Fill in one acceptance record per task class, compare cost per accepted task, and move traffic by task class with a rehearsed way back.

Sources

Official sources last checked September 18, 2026. Anthropic facts come from official documentation; community reports come from X posts we read directly, forum threads, and one Reddit thread relayed second-hand, and are labeled as such; the cost example uses invented figures; EvoLink route status is separate and unverified.

All Posts

#Claude Opus 5.2 #Claude Opus 5 #Anthropic #Model Comparison #Model Migration