Claude Opus 5.5 Is Cheaper, and Four of Your Requests Now Return 400

Anthropic released Claude Opus 5.5 on 22 September 2026 under the model identifier claude-opus-5-5, available on the Claude API, Amazon Bedrock, Google Cloud and Microsoft Foundry. The price is 4 dollars per million input tokens and 20 dollars per million output tokens, down from 5 and 25 on Opus 5. Cache reads fall to 20 cents per million, five minute cache writes cost 5 dollars, one hour writes cost 8, and the Batch API halves everything again to 2 and 10. Independent coverage reports Terminal-Bench 4.0 at 66.4 percent against 55.8 for Fable 5.1 and 52.3 for Opus 5, which means the cheaper model is also, on that benchmark, the stronger one. When we wrote about Claude Opus 5 in July, the lesson was that capability had moved down a price tier. Two months later it has moved again, and the routing table you rebuilt then is already stale.

The part that deserves more attention than the price is the official What is new page, which lists four breaking changes for code already running on Opus 5. First, thinking can no longer be switched off. A request that sends thinking type disabled, or a manual token budget, now returns a 400 invalid request error, and effort becomes the only dial for depth, latency and cost. Second, forced tool use is gone. Setting tool choice to any, or naming a specific tool, returns a 400, and the same validation applies to the token counting endpoint, so even your cost estimator can start failing. Third, thinking blocks are now bound to the model that produced them and to the conversation around them, and for accounts created on or after 31 August 2026 the API rejects a replayed block if the system prompt, the tools or an earlier message changed since it was generated. Fourth, on the Claude API and Google Cloud the older computer_20251124 computer use tool is rejected in favour of the newer toolset, while Bedrock keeps accepting it.

Loud failures are the easy ones, because a 400 shows up in your error dashboard on the first request. Within a day of release, issues were already open against LangChain, LlamaIndex and the ax framework for sending exactly the forced tool choice and disabled thinking settings the new model refuses. If you build on a framework rather than the raw API, the question is not whether your code sets these flags but whether a library you depend on sets them for you. Structured extraction helpers are the usual culprit, since forcing a single named tool was for a long time the standard way to guarantee JSON back. The documented replacement is tool choice auto with strict tool use, or moving the schema into structured outputs, and that is a code change with its own test cycle, not a configuration toggle.

The silent changes are the ones that will cost you. The default effort on Opus 5.5 is medium, where Opus 5 defaulted to high, so any request that never set effort explicitly is now doing a different amount of reasoning than it did last week, without an error and without a changelog entry in your own repository. The documentation also notes that at the same effort setting the new model tends to think more per turn, most of all at the top levels, so an effort value carried over unchanged does not mean the same cost or latency either. And the short notes the model writes between tool calls now arrive as thinking blocks, which come back empty at the default display setting. A product that streams those notes to users as progress updates simply goes quiet between tool calls. Nothing fails. The user just watches a spinner and wonders whether the agent has stalled.

There is a safety change in the same category. Opus 5.5 adds a biology safety classifier alongside the existing cybersecurity one, plus a reasoning extraction refusal category for prompts that push the model to reproduce its internal reasoning in the answer. A declined request comes back as HTTP 200 with a stop reason of refusal and a details object naming the policy area. That matters for monitoring, because any alerting that counts non 2xx responses will not see refusals at all. Anthropic offers server side fallback that retries on the model it recommends for that category, which is convenient and also means the model that actually answered a given request may not be the one you configured. If your AI inventory or ISO 42001 impact assessment names one model per feature, you now need to log the responding model on every call to keep that record true.

This is why a model upgrade is a change management event and not a find and replace on a string. ISO 27001 Annex A 8.32 expects changes to information processing facilities to follow a controlled process, and SOC 2 CC8.1 asks for authorised, tested and approved changes with evidence. An auditor sampling your change tickets will reasonably ask how you validated that a new default reasoning level, a new refusal category and a new streaming shape did not alter the outcomes of a feature customers rely on. If the answer is that someone bumped the model name on a Friday because the price went down, that is a finding. Platforms such as Vanta and Drata can track that the ticket exists, but they cannot tell you whether the regression suite behind it actually ran against the new model.

For teams in scope of the EU AI Act, the point sharpens further. Article 12 record keeping and the technical documentation in Annex IV both assume you can say which model version produced a given output and under what configuration. A floating alias that silently resolves to a new model, combined with a fallback that can hand a request to a different model again, makes that statement harder to support. Pinning the explicit identifier, recording the effort level you set rather than the default you inherited, and storing the responding model and stop reason with each output is a small amount of engineering that turns an awkward audit question into a query.

The practical checklist is short. Search your code and your dependencies for thinking disabled, thinking budgets, tool choice any and named forced tools, and the old computer use tool version, before you move any traffic. Set effort explicitly on every call and rerun your cost and latency sweep instead of copying the Opus 5 value. Select response content by block type rather than position, and set the thinking display option if your interface shows progress between tool calls. Add refusal to your monitoring as a first class outcome and log which model answered. Run your graded regression cases against claude-opus-5-5 and attach the results to the change ticket. Then, and only then, enjoy the lower invoice.

Our take: Opus 5.5 is a genuinely good release, cheaper and stronger on agentic work at the same time, and most teams should plan to adopt it. But the price cut is what gets people to switch in a hurry, and the release notes are explicit that a hurried switch will break forced tool calls, drop your default reasoning depth, mute your progress updates and introduce refusals your monitoring cannot see. Treat the upgrade the way your ISO 42001 and SOC 2 programmes already say you should treat any change to a production system, with a ticket, a test run and a record of what model is actually answering. The savings will still be there next week, and so will your evidence.