Opus 5 effort belongs in the release configuration

Anthropic’s current Opus 5 documentation makes effort an explicit API configuration. Thinking is enabled by default, and the documented effort levels are low, medium, high, xhigh, and max. Anthropic advises choosing among them with workload-specific evaluations because effort changes quality, token use, and latency. Its migration guidance also calls for reviewing max_tokens and documents a breaking restriction on disabling thinking above high effort. Anthropic documentation

A separate benchmark illustrates why the setting belongs in release evaluation. Artificial Analysis tested all five effort levels on its private AA-Briefcase agentic knowledge-work benchmark and reported different quality, cost, duration, and turn counts. The top three settings averaged more than 25 minutes per task. High effort cost substantially less per task than max while exceeding Claude Fable 5 on that benchmark. These results are bounded to the tested benchmark and do not establish the best setting for another workload. Artificial Analysis benchmark

Axios also reported that Opus 5 launched on July 24 with effort control and that lower settings are intended to reduce token use and operating cost. That report documents the positioning of the control; it does not demonstrate savings for a particular deployment. Axios report

Effort is an experimental treatment

To compare effort levels, freeze the other inputs that could change the result. Represent each treatment as a versioned inference configuration:

release = {
  model_id,
  thinking_state,
  effort,
  max_tokens,
  endpoint,
  fallback_policy
}

This is our proposed engineering frame, not a framework established by the sources. The evidence directly supports treating thinking state, effort, and max_tokens as consequential configuration inputs. We add endpoint and fallback policy because they identify how a deployment is intended to send requests and respond when its preferred path is unavailable. The supplied evidence does not compare endpoints or fallback designs.

The tuple answers a narrower experimental question: which intended configuration produced this measurement? It makes an effort, output-budget, or fallback-policy change explicit. Versioning alone does not prevent untracked changes or establish whether a fallback activated at runtime.

Hold the controls still

Each candidate release can record at least the following fields:

Field	Record	Evaluation question
Model	Exact model ID	Which nominal model was configured for the candidate?
Thinking	Enabled or disabled	Does the state comply with the documented effort restriction?
Effort	Low, medium, high, xhigh, or max	How does the setting affect this workload’s measured result?
Output budget	Exact max_tokens value	Does the budget permit completion without unnecessary output allowance?
Endpoint	Provider and endpoint identifier	Which request path was configured and evaluated?
Fallback	Trigger, destination, and configuration	What configuration is intended to run after fallback activation?
Release ID	Immutable configuration revision	Can an evaluated candidate be attributed to one intended tuple?

The restriction question is material during migration: Anthropic documents that thinking cannot be disabled above high effort. The same guidance identifies max_tokens as an input to review. Anthropic documentation

Endpoint and fallback rows are Super Genius Labs release controls. Changing either one does not necessarily change model quality. These rows document the intended request path and fallback behavior; separate request-level runtime evidence is required to identify which model, endpoint, or fallback path actually served a request.

Measure the response by workload

Anthropic advises workload-specific evaluation, while the Artificial Analysis results show that effort settings separated quality, cost, duration, and turn count on one private benchmark. Together, those bounded findings argue against deriving a universal setting from the benchmark alone. Anthropic documentation Artificial Analysis benchmark

Use an evaluation table for each representative workload slice:

Dimension	Example measurement
Quality	Workload-specific acceptance score with explicit pass criteria
Tool completion	Completed, partially completed, failed, or incorrectly attempted tool sequence
Latency and duration	Time to first response, time per turn, and total task duration
Turn count	Model turns, tool turns, retries, and recovery turns
Token use and cost	Input tokens, output tokens, and measured task cost
Fallback behavior	Trigger rate, destination configuration, and post-fallback result

Quality, tool completion, and cost can conflict. A configuration that scores higher may also take longer or consume more tokens; the documentation says effort affects quality, token use, and latency, while the benchmark reports differences in cost, duration, and turns. Neither source establishes how those trade-offs resolve for a different workload. Anthropic documentation Artificial Analysis benchmark

For tool-using agents, task slices can cover distinct paths rather than averaging every result into one score. Examples include a short read-only lookup, a multi-step tool sequence, recovery from a tool error, and a task that approaches the output budget. These are proposed test categories, not scenarios evaluated by the cited sources.

Run the migration as a controlled comparison

For teams comparing an existing Opus 4.8 configuration with Opus 5, capture the baseline tuple first. Create a separate Opus 5 candidate for every effort and output-budget combination instead of mutating one shared candidate. Apply the documented max_tokens guidance and the restriction on disabling thinking above high effort. Anthropic documentation

Then hold the workload and scoring criteria constant while changing one configuration field at a time where practical. If request-level evidence identifies the serving path, report preferred and fallback results separately. Compare quality, completion, latency, duration, turns, token use, and cost by slice before promoting one immutable tuple with the release decision.

This process does not prove production performance or identify the serving path by itself. It creates a traceable relationship among an intended candidate configuration, a workload sample, and measured results. Attribution to the model and path that actually served a request requires separate request-level runtime evidence.

The supplied evidence does not establish how Opus 5 performs on a particular organization’s prompts, tools, endpoints, fallback paths, or traffic. The private benchmark does not demonstrate production behavior outside its tasks. The documentation identifies configurable inputs and migration constraints but does not select a universal effort level. A versioned configuration also does not establish that the intended model, endpoint, or fallback path handled a particular request.

That uncertainty is why the experiment keeps intended configuration separate from runtime observation. Promote an effort setting only with the workload slices, trade-offs, and serving-path evidence that support it. Broader system evaluation questions can start on Build.