The Claude 5.5 Upgrade Looks Free. For Agents in Production, It Isn't.

The upgrade that looked free

Anthropic shipped Claude Opus 5.5 on September 22, 2026, and Sonnet 5.5 six days later. The headline numbers are the kind vendors like to lead with: Opus 5.5 dropped from $5/$25 per million input/output tokens to $4/$20. Sonnet 5.5 held at $2/$10 but runs over 30% faster and, per Anthropic, costs up to 30% less for typical work. Both kept the 1M-token context window. On a pricing page, that reads like a free upgrade — same model ID family, lower bill, faster responses.

For a team calling the API from a script, it basically is free. For a team with agents in production — forced tool calls, manual thinking budgets, specific reasoning-effort tuning baked into prompts or orchestration code — it isn't. Anthropic's own docs for both models list behavior changes that return hard 400 errors on request patterns that worked fine on the previous version. That gap between "the pricing page" and "the migration notes" is the part worth paying attention to, because it's not unique to this release — it's the shape of how frontier models will keep shipping.

What actually broke

Four things, documented by Anthropic itself:

• Thinking can no longer be disabled. On Opus 5.5, thinking is always on. A request sending thinking: {"type": "disabled"} — or a manual token budget via thinking: {"type": "enabled", "budget_tokens": N} — returns a 400 invalid_request_error. The fix is to omit the field or send adaptive, but any code that explicitly disabled reasoning to save latency on simple calls needs to change.
• Forced tool use is gone on both models. Opus 5.5 rejects tool_choice set to {"type": "any"} or a named-tool force. Sonnet 5.5 goes further: only auto and none are supported at all. If your agent pipeline relied on forcing a specific tool call deterministically — a common pattern for structured extraction — that call now fails, and the documented workaround is strict: true with structured outputs, or just asking for it in the prompt and hoping the model complies.
• Reasoning effort replaces manual budgets as the only dial. You tune how hard the model thinks via an effort level, not a token count, and Sonnet 5.5 adds a between_tools thinking mode that's accepted at low/medium/high effort but rejected outright at xhigh or max — where you're pushed back to adaptive.
• Older tool versions get rejected outright. computer_20251124 no longer works against the Claude API or Vertex/Google Cloud routes for these models.

None of these are capability regressions. They're interface changes — the kind that pass every unit test you didn't think to write and show up as a wall of 400s in production logs the morning after a routing config auto-upgrades the model string.

The pattern, not the model

This isn't an argument against upgrading, and it isn't specific to Anthropic — every frontier lab is now shipping on a cadence that looks more like a SaaS release train than the old "wait a year, ship a numbered model" pattern. GPT and Gemini have both been on a similar cycle of point releases through 2025 and into 2026. The pattern that matters for anyone building on these APIs is this: a ".5" or a patch-looking version bump now routinely changes default behavior, not just benchmark scores. Thinking defaults, tool-choice semantics, max output headroom, even which legacy tool-definition versions are accepted — all of that is now part of the surface area that moves between releases, and none of it shows up if you're only watching capability benchmarks.

That has a direct cost for anyone who pinned their agent's reliability to "whichever model the API alias points to this week." If your evals only check output quality — did the agent get the right answer — and not request-level compatibility, a silent provider-side upgrade can take your pipeline from "working" to "returning structured errors" with zero code changes on your end.

What this means if you're the one buying or building

If you're a business with an agent or AI feature in production — not a chatbot wrapper, something that calls tools, enforces structured output, or runs multi-step workflows — treat model version as a dependency, not a setting:

• Pin the model string, not a "latest" alias, for anything running unattended. Decide upgrades on your schedule, after testing, not on the vendor's release schedule.
• Have a regression suite that exercises your actual request shapes — forced tool calls, thinking configuration, tool-definition versions — not just a handful of "does it give a good answer" evals. The breaking changes above are exactly the kind that a capability eval will never catch, because the model would answer the question fine if the request hadn't been rejected first.
• Read the model's migration notes before you upgrade, not after something breaks. Every major lab now publishes these; they're short, and they're the first place a breaking change shows up, usually weeks before the error reports do.
• Ask your vendor, if you're buying rather than building, how they handle this. "We're on the latest model" is not reassuring on its own — ask whether they pin versions, test before upgrading, and have caught a breaking change like this before it hit your account.

None of this requires an AI engineering team. It requires treating "which model version" with the same discipline you'd apply to a library version in a package.json — because functionally, that's what it now is.

Takeaway

The interesting number in the Claude 5.5 release isn't the price drop — it's that Anthropic's own docs needed a "what's new" page just to list which previously-valid API requests now return errors. If you have an agent in production, go read that page for whichever model you're on before you auto-upgrade, and pin your version until you have.