Claude Opus 5 Testing Guide

Bottom line

Opus 5 is a practical upgrade candidate for long coding, research, and agent tasks. Its 1M context, effort controls, and Opus 4.8 pricing are useful features, but switch only after it improves cost per accepted result on your own work.

Claude Opus 5 launched on July 24, one day after the rumored date in the original version of this article. The leak was useful as a signal, but it was not enough to make a buying decision. Now there is an official model, price, context window, and API name to test.

Opus 5 is designed for long coding, research, and agent work. It has a 1 million token context window, supports up to 128,000 output tokens, enables thinking by default, and lets users move through low, medium, high, xhigh, and max effort settings. The API model name is claude-opus-5.

Anthropic priced it at $5 per million input tokens and $25 per million output tokens, the same base price as Opus 4.8. Fast mode runs at about 2.5 times the default speed and costs twice the base price.

Learners and small teams can now test whether a stronger model finishes enough difficult work with fewer retries and less review to justify its cost.

The features worth learning

Effort is now part of model routing

Do not run every task at max. A model that exposes several effort levels gives you another routing decision alongside model choice.

Use lower effort for work with a clear pattern and cheap verification. Raise it for a difficult bug, an ambiguous research problem, or a long task where a weak first plan creates expensive rework. The skill is not finding one perfect setting. It is matching effort to the cost of failure.

Long context still needs a good job definition

A 1M context window can hold a large repository or research pack, but capacity does not create structure. Tell the model which result you need, which files or sources have authority, what it may change, and how the result will be checked.

For coding, that may mean a passing test, a tight diff, and a browser check. For research, it may mean a cited answer with unsupported claims marked. Large context is most useful when the acceptance rule is small and clear.

Measure self-checking, not benchmark rank

Anthropic emphasizes that Opus 5 checks its work and persists through longer tasks. Its launch examples include root-cause debugging, building a test harness when no live feed was available, and checking browser layouts before handoff.

Those are vendor examples, not guarantees. They do point to a better evaluation target than a single benchmark score: does the model notice its own mistake before you do, and does that reduce the time needed to accept the result?

Run a ten-task switch test

Choose ten tasks from work you have already completed. Include a mix of easy and difficult jobs, but keep the expected result and acceptance check known.

For each task, record:

the prompt, source files, tools, and permissions;
the model and effort setting;
elapsed time, token cost, retries, and tool failures;
manual review and correction time;
whether the result passed the original acceptance check.

Run the same set with your current model. Then calculate cost per accepted result, not cost per request. A more expensive run can still be cheaper work if it finishes a difficult task cleanly. A strong benchmark model can still be the wrong choice if review and correction eat the gain.

Publish the test as proof

A model comparison becomes portfolio evidence when another person can inspect it. Publish the task definitions, acceptance rules, settings, and a short failure log. Remove private code or client data, but do not hide unsuccessful runs.

This proof can support paid work without turning the article into an income promise. A developer can show a faster, checked migration workflow. A researcher can show a cited brief with lower correction time. An operator can show that a repeated automation completes within a defined cost and review budget.

The commercial value comes from the accepted deliverable. Access to Opus 5 is available to everyone on the same platform, so the model name alone is not an advantage.

When not to switch

Stay with the current model if your tasks already pass cheaply, if your toolchain does not support Opus 5 reliably, or if the new model produces larger answers that take longer to review. Keep a fallback for production work and test sampling or thinking changes before migrating saved prompts.

Also separate Anthropic’s benchmarks from your evidence. The company reports strong coding, knowledge-work, computer-use, and scientific results, but your provider, harness, tools, prompts, and acceptance rules make up the system you actually use.

Continue with the Anthropic model family guide and the model decision framework.

Official sources

Put this to work

Compare models by accepted results, review effort, elapsed time, and cost rather than launch benchmarks alone.

Try

Run ten representative tasks on Opus 5 and your current model with the same acceptance rules and a fixed budget.

Prove it worked

Keep the prompts, effort setting, tool permissions, failures, manual corrections, elapsed time, and cost for every accepted result.

Keep in view

The model has a 1M token context window, up to 128k output tokens, and thinking enabled by default.
Effort settings range from low to max, so buyers can test capability against token use instead of using one fixed reasoning level.
Base API pricing matches Opus 4.8 at $5 per million input tokens and $25 per million output tokens.

Learn the workflow: choosing between Anthropic models