Anthropic says Opus 5.5 costs 40% less than Opus 5 "at default settings." On Opus 5, a request without an effort value ran at high. On Opus 5.5 it runs at medium.

Your code didn't change and neither did your prompts, but every call that never set effort now thinks less. Some of the savings come from the new default, not the new model.

Set effort explicitly in every call and log it next to the model ID. Then run your own eval at two levels before you believe any vendor's cost number, theirs included.

Two launches, one afternoon

On 22 September, Anthropic shipped Claude Opus 5.5 and OpenAI shipped GPT-6 Sol and GPT-6 Luna within hours of each other. Both launches were about price.

Opus 5.5 lists at $4 per million input tokens and $20 per million output, down from $5 and $25. Cache reads fell from $0.50 to $0.20, which matters more than the headline rate if you run agents, because agent loops reread the same context all day. Anthropic's announcement says the model "will cost 40% less than Opus 5 on typical workloads" at default settings.

GPT-6 Sol went to $2 input and $10 output, half of what GPT-5.6 Sol cost. Luna is $0.10 and $0.50. OpenAI told VentureBeat these are permanent prices, not an introductory offer.

So both labs are saying the same thing: better model, lower bill. Before I move a production workload on either claim, I read the footnotes. This time the footnotes are all about one parameter.

The line in the migration notes

Anthropic's "What's new in Claude Opus 5.5" page lists four breaking changes, the ones that return a 400 error. Thinking can't be disabled anymore, forced tool use is gone, thinking blocks are tied to the model that wrote them, and the old computer use tool is rejected on the Claude API and Google Cloud. You'll find those in your logs within minutes.

The next section is called "Behavior differences," and its first bullet reads: "A request that omits effort runs at medium; on Claude Opus 5 it ran at high."

That one doesn't show up in your logs. The request succeeds and the answer comes back a bit faster and a bit cheaper. If your eval set is thin, it also comes back a bit different, and the first person to spot it is a user a week later.

The same bullet list has a second change that cuts the other way: "At the same effort setting the model tends to think more per turn than Claude Opus 5, most of all at xhigh and max." If you did pin effort to high on Opus 5 and you carry that value over, you're now paying for more thinking per turn than before.

So there are two ways to migrate without touching effort, and they go in opposite directions. Code that never set effort drops a level. Code that set it explicitly gets deeper thinking at the same label. Neither is wrong, but neither is the 40% number unless your workload happens to look like Anthropic's "typical."

The benchmarks tell you the same thing

Look at how both launch posts report their numbers.

Anthropic reports Opus 5.5 at 54.6% on FrontierCode v1.1 at medium effort and 54.4% at max. On that benchmark, the extra thinking bought nothing, or slightly less than nothing. On CursorBench 4.0 it went the other way, 52.5% at medium and 57.8% at max. More than five points, from one parameter.

Terminal-Bench 4.0 is reported at 66.4% at xhigh. Artificial Analysis ran it independently at max and got 59.6%. Different harness, different trial counts, different effort, and a seven-point gap.

OpenAI's post has the same pattern with different labels. GPT-6 Sol has six effort levels, none through max, with medium as the default. The OSWorld 2.0 chart puts Sol at xhigh (60.5%) next to Opus 5 at medium (60.3%) and calls it a match at a fraction of the cost. That's a real result. It's also a comparison between one model's second-highest setting and another model's middle one, against the previous Opus, not the one that shipped the same day.

Sol at max reaches 64.4% on OSWorld. The older GPT-5.6 Sol still scores 66.2% on the same chart, at more than twice the cost per task. The new model wins on price, not on peak score.

I don't read any of this as dishonest. Effort is a real control, and each lab reports the setting that tells its story best. The problem is that "effort: high" on one model and "effort: high" on another are two different amounts of compute with the same name. They aren't even the same amount between two versions of the same model, as Anthropic's own docs now say.

What I'd do this week

If you run Claude or OpenAI models in production, this is the checklist I'm running on client systems.

Grep for calls that don't set effort. Every one of them changed behavior on 22 September if the model ID moved to claude-opus-5-5. Some teams float an alias, some pin versions, some let a gateway pick. Find out which you have before your finance team does.

Set effort explicitly everywhere. Treat it like the model ID, a value you choose, commit, and review. A default is the vendor's opinion about your workload, and they just changed their opinion.

Log effort in your traces. If your observability stack records model and token counts but not effort, you can't explain a cost shift or a quality dip after the fact. It's one field. Add it next to the model name.

Sweep two levels, not one. Run your own eval set at medium and at whatever you used before. Anthropic's docs say it directly: "Set effort explicitly and re-run your sweep." The FrontierCode result shows medium can match max on some work, so you may find real savings. CursorBench shows it can cost you five points on other work. Only your tasks tell you which one you have.

Compare vendors at matched cost per task, not matched labels. Sol at $2 and $10 is half the list price of Opus 5.5, but list price per token says little about cost per solved task. If you're choosing between them, fix a budget per task and see which one solves more of your cases inside it. The effort names don't translate across labs, so stop trying to line them up.

The quiet change

Opus 5.5 is probably a better and cheaper model for most agent work. The early-access numbers from Optiver, Kiro and Box all point that way, and the lower cache price alone helps any long-running loop.

But "cheaper at default settings" now depends on a default that moved in the same release. The breaking changes got their own section with error messages. The effort change is a bullet under "Behavior differences" and fails nothing.

That's where the risk sits in model upgrades now. Renamed parameters and removed tools fail loudly and get fixed. A different amount of thinking returns a valid answer. Pin the value, log it, test it at two levels, and you'll know which 40% you're actually getting.