Vercel announced that Claude Opus 5.5 is now available on AI Gateway, the same day GitHub enabled it in Copilot and Anthropic shipped the model. Anthropic says it performs at Fable 5.1 level, with ~30% more speed and ~40% lower cost per task than Opus 5. That's what everyone is going to put in the headline.
What almost nobody is going to read is the paragraph in the middle: there are two API changes that turn requests that work today into HTTP 400.
Why it matters
The signal here isn't the benchmark. It's that Anthropic removed two control levers a lot of people used to tame the model, and removed them in the same release that promises more autonomy. According to Vercel's changelog, Opus 5.5 rejects requests that disable thinking or pin a budget for it, and rejects the ones that require a tool call or force a specific tool.
Translation: the model decides how much to think, and you can't force it to call a function. For two years the integration pattern was the exact opposite — force a tool to get structured JSON, cap thinking to bound latency and cost. That pattern is over. This isn't a release-notes detail, it's a change in the contract between your harness and the model.
And it fits with the rest of the announcement. Vercel's note highlights that Opus 5.5 reports in plain language what it did, what it found and what it needs next. GitHub, for its part, says that in early testing it solved tasks comparably to Opus 5 using considerably fewer steps and tokens, and that it recovered quickly from errors in multi-step tasks. The model is positioning itself as something you supervise, not something you control request by request.
What changes in practice
If you have an agent in production on Opus 5, switching models isn't a line in an environment variable. It's an audit of your call layer.
| Before (Opus 5) | Now (Opus 5.5) |
|---|---|
| Thinking could be disabled or given a fixed budget | Thinking is always adaptive; the model decides |
| Force a tool call to get JSON | Structured outputs; forced tool use removed |
| Force a specific tool | Prompt toward it and retry in the harness |
| Fine-grained per-request latency control | Effort and prompting as the only levers |
The migration flow I'd follow is short and boring, which is exactly how migrations should be:
┌────────────────────────────┐
│ grep the thinking field │
│ and forced tool_choice │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ JSON via forced tool? │
│ yes ─► structured outputs │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ retry in the harness for │
│ tool calls that don't come │
└─────────────┬──────────────┘
▼
┌────────────────────────────┐
│ canary with real traffic │
└────────────────────────────┘
Point three is the one people underestimate the most. If you used to force the tool, your code never had to handle the case where "the model answered with text instead of calling the function". Now that case always exists, and the changelog is explicit: prompt toward the tool, then catch and retry failures in your harness. That's new logic, with its own tests.
Two more things from the material that change architecture decisions. First, the window is 1M tokens of context with up to 128K output and a knowledge cutoff in June 2026 — if you had a chunking strategy built for small windows, half of it may be dead weight now. Second, there are optional regional inference and Zero Data Retention controls in the gateway, which is exactly what enterprise clients ask for in a compliance review. Vercel also clarifies that it mirrors provider pricing with no markup or platform fee on inference, even with BYOK.
And one detail that only shows up in GitHub's changelog: Opus 5.5 watermarks its text outputs. It doesn't change meaning, quality or readability, and it doesn't add tokens or cost. If you work with clients who have policies about AI-generated content, this is a conversation you want to have before they do.
When NOT to use it
There are three scenarios where I'd stay on Opus 5 today, guilt-free.
- Latency with a hard SLA. If your product promises a response in X milliseconds and you got there by turning thinking off, you just lost the lever. "~30% faster on average" is not the same as "predictable": with adaptive thinking, per-request variance now lives on the model's side. Before migrating, measure p95 and p99 with your real traffic, not with anyone's benchmark.
- Pipelines that depend on deterministic tool calls. If your system assumes every turn produces a function call no matter what, harness-side retry isn't an afternoon patch: it's rewriting the state machine. Migrate when you have time to do it properly.
- Costs already optimized with thinking budgets. "40% cheaper per task" is Anthropic's number comparing against Opus 5 in its own configuration. If you were already trimming thinking by hand, your baseline is different and that 40% doesn't apply the same way to you. The material gives no numbers for that case, so the only honest answer is to measure it yourself.
One nuance I'll add that came up in Latent Space's coverage: alongside the efficiency gains, they also mention compensatory inefficiency in token usage on some frontier tasks. In other words, the improvement isn't uniform. If your workload lives at the edge of what the model can do, the savings may evaporate.
What I'd do today
I'd try it first where the risk is mine and not the client's: in my own development flow. It's in Copilot for Pro+, Max, Business and Enterprise, with a gradual rollout, and on AI Gateway it connects to coding agents via Vercel's CLI. There, the cost of it going wrong is an annoying session, not an incident.
In parallel, I'd grep for thinking and forced tool choice across every service that touches the API. That takes twenty minutes and tells you whether the migration is a string change or two weeks of work. Finding out from a 400 in production is the worst possible way to learn it.