Switching an Opus 5 agent to claude-opus-5-5 looks like a price change. According to CometAPI’s review of Claude Opus 5.5, published September 22, 2026, it also changes the default reasoning effort. Inherited settings then no longer mean what they did, so cost and latency baselines have to be measured again.
What the review lists
- Default effort: Medium for Opus 5.5; High for Opus 5 and Fable 5.1.
- Adaptive thinking: always on for Opus 5.5, with no “off” mode.
- Unchanged limits: 1M-token context and 128K max output for all three models.
- Prices per million tokens (as of the review date): Opus 5.5 at $4 input, $20 output, $0.20 cache reads and $5 cache writes. Opus 5 is $5, $25, $0.50 and $6.25.
Four claims, four measurement conditions
The review’s efficiency and quality numbers come from different settings:
- About 40% lower cost than Opus 5 on typical workloads. This is a vendor figure stated “at default settings” and attributed to both lower rates and reduced token consumption. The same paragraph says output generation is more than 30% faster. The review’s summary repeats the 40% without the “default settings” qualifier.
- Headline coding scores (Terminal-Bench 4.0 66.4%, FrontierCode v1.1 Main 54.4%, CursorBench 4.0 57.8%). These are stated as measured at high or max adaptive thinking effort.
- Code review. A customer report says Opus 5.5 at its lowest effort caught 72% of known bugs, versus 56% for Opus 5 at high effort, with fewer false positives and far less output.
- “Half the turns, time and output tokens” on agentic coding (a 40–50% cost reduction), reported by teams. No effort level is stated.
Inference: these numbers cannot be combined into one expectation. Opus 5.5’s default is medium, so the 40% figure compares Opus 5.5 at medium with Opus 5 at its high default. The benchmark scores were measured at high or max. The review gives no cost or speed figure for Opus 5.5 held at high effort, so “benchmark-level quality at 40% less cost” is not reported for any single configuration. The review also relays the caveat that benchmark margins can understate or overstate real-world differences.
The part that does not move with effort
The listed per-token prices do not vary by effort. Input, output and cache writes are each 20% cheaper, and cache reads are 60% cheaper. Arithmetic, assuming unchanged token counts per line: a task’s bill would fall by 20% to 60%, depending on the cache-read share of its spend. For illustration only, a task whose spend was half cache reads would come out 40% cheaper from rates alone. That is not a measured workload. It shows that a 40% headline says little about how many tokens a migrated agent will actually use at the effort it runs.
What a bare model-ID swap inherits
Inference: an Opus 5 agent that never set effort ran at high. After only a model-ID change it would run at medium, if its route applies the listed default. The review does not explain how effort is set in the API or through aggregator endpoints, so confirm that on your own route. Part of any saving after a bare swap may therefore come from the lower effort level.
The review does report medium-effort benchmark results, but against competitors rather than Opus 5. At default (medium) effort, it says Opus 5.5 “often beats higher-effort settings of competitors at a fraction of the cost”: roughly 20% of GPT-6 Astra’s cost per task on FrontierCode, and about one-third the cost on CursorBench while outperforming GPT-5.6 Sol by 11 points. It reports no medium-effort quality result against Opus 5, the baseline a migrated agent is judged against.
Adaptive thinking cannot be switched off. The only control the review ties to it is the effort level, so reasoning stays part of every request’s cost and latency. The review does not say whether the output-speed figure includes thinking time. Its task-level timings state no effort level, and none compares with Opus 5 at a matched effort. In one example it relays, Opus 5.5 finished a C-to-Rust translation of HAProxy in 9.5 hours versus 12 hours for Fable 5.1. The team-reported figure in item 4 gives roughly half the time of Opus 5, but only as a ratio.
A re-baseline plan
- Pin effort explicitly for each workload. Log it next to the model ID on every eval and production run.
- Run your own acceptance set in three arms: Opus 5 at its current setting, Opus 5.5 at medium, and Opus 5.5 at high. Compare cost per accepted task, including retries, and wall-clock time per task, not per-token price.
- Keep existing timeouts and latency budgets until those arms give you end-to-end times.
- Treat the lowest-effort code-review result as a hypothesis for review lanes. The report gives no sample size or bug set, so test it against your own known-bug set and false-positive rate before lowering effort there.
For anyone planning this migration: will you pin Opus 5.5 to high so your Opus 5 baselines stay comparable, or start from the medium default and re-validate quality? And which metric decides it for each workload type?