Sonnet 4.5 Retires November 30: What Sonnet 5.5 Breaks, and How Vendor Clocks Compare

Two vendors, two clocks, one week

On September 28, Anthropic launched Claude Sonnet 5.5 (claude-sonnet-5-5). On September 30 it announced the retirement of Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) on the Claude API for November 30, 2026, with Sonnet 5.5 as the recommended replacement. That is 61 days of notice against a published minimum of 60. On the day this post goes out, 56 remain.

On October 1, OpenAI's deprecations page added its own batch: gpt-5.3-codex, gpt-5.1 and gpt-5.4-nano leave the API on April 1, 2027, six months out. Four text-to-speech models follow on January 6, 2027.

This post sticks to what both vendors publish: notice periods, breaking changes and prices. We have not run our own evals on Sonnet 5.5, so we make no quality claim. What a team can plan around is the calendar, and on this week's announcements the two calendars differ by a factor of three.

What Sonnet 5.5 changes in your code

Price first, because it is the easy part. Sonnet 5.5 costs $2 input and $10 output per million tokens, the same as Sonnet 5, with cache reads at $0.20. Sonnet 4.5 sits at $3 / $15 with cache reads at $0.30, so a Sonnet 4.5 workload pays a third less on input, output, cache writes and cache reads alike. The model overview lists a 1M-token context window, 128K max output, adaptive thinking with a default effort of high, and a retirement date of "not sooner than September 28, 2027."

The release notes are unusually direct: code written for Sonnet 5 "can break on Claude Sonnet 5.5 in five ways."

That list is written for Sonnet 5 code. A team leaving Sonnet 4.5, the one with the deadline, has more to do. The Sonnet 5.5 migration guide stacks two more groups of changes for Sonnet 4.6-or-earlier and 4.5-or-earlier code: thinking budgets give way to an effort level, non-default temperature, top_p and top_k values have to go, assistant prefills need replacing, and output_format moves to output_config.format. Read down to your starting model's group instead of stopping at five.

Forced tool use returns a 400

Many production chatbots pin tool_choice to guarantee structured output; we covered why forced tool calling matters in production. On Sonnet 5.5 every request that sets it fails with an explicit message: tool_choice: type "tool" and "any" are not supported for this model.

The documented replacement is tool_choice: {"type": "auto"} with strict: true on the tool, so its input matches the schema. The catch is behavioral: under auto, the model can answer in text without calling the tool, so the prompt has to say when the tool applies. Strict tool use supports a subset of JSON Schema and needs additionalProperties: false on every object. On Amazon Bedrock, structured outputs (strict tools included) are not available for Sonnet 5.5, and the guide says to send auto without strict and validate the tool input in your own code.

A pipeline that relied on forcing therefore gains two failure modes to measure: the turn where no tool gets called, and, on Bedrock, the turn where the input does not validate. We have not measured how often either happens. Your eval set should, before you switch traffic.

Thinking blocks are bound, and the drop is silent by default

Every thinking block records which model produced it. Blocks from Sonnet 5.5 "work only in the account that produced them, or in an account linked to it," and among other models only Opus 5.5 reads them, on the Claude API and Google Cloud. When a request carries a block the target model cannot read, the API drops it before the model sees it. The request succeeds, and dropped blocks are not billed.

Three common setups are exposed: proxies that replay transcripts under a different key, multi-tenant gateways that share conversation stores, and fallback chains that route a failed Sonnet 5.5 turn to another model, which then continues without the reasoning (we wrote about model fallback earlier this year). The drop stays invisible unless you send the thinking-binding-controls-2026-08-01 beta header, which reports it in a top-level input_transformations array. We would turn that on in staging and log it.

There is a stricter half. The API also checks whether the system prompt, the tools or an earlier message changed since a Sonnet 5.5 block was produced. For accounts created on or after August 31, 2026, that check is enforced by default on the Claude API, Bedrock and Google Cloud, and a replay after such a change returns a 400. Code that edits history (rewriting earlier turns, swapping a system prompt mid-session, adding tools late) needs a test. The migration checklist puts it in three words: keep conversations append-only.

The retirement clock: 61 days against six months

Both vendors publish a minimum. Anthropic's is 60 days for publicly released models. OpenAI's is six months for generally available models and three for specialized variants such as chat, Codex and deep research, with exceptions for preview models ("such as 2 weeks") and for safety or compliance. This batch beat the floor once: gpt-5.3-codex is a Codex variant with a three-month minimum and got six. The floor also has gaps: the same page lists gpt-5.4-cyber, announced September 11 for removal on October 1, twenty days later.

Anthropic offsets its short window with forward visibility: each active model carries a "not sooner than" retirement date. Sonnet 5.5's is a year out. Claude Haiku 4.5's is October 15, 2026, ten days from publication. The deprecations page still lists it as active, so the 60-day policy puts its earliest possible retirement in early December. If Haiku 4.5 runs your classifiers or routers, plan its migration now. The Sonnet 5.5 guide covers that path and tells you to re-baseline cost at the higher per-token price.

The practical reading: on Anthropic you get long visibility but a short execution window once the notice lands. On OpenAI, this week's GA notices give six months to execute. Teams with slow change control, regulated environments or many downstream consumers are better served by the second pattern. Teams that ship a model swap in a sprint can live with the first, provided they treat the "not sooner than" column as a planning input.

The TTS notice carries its own caveat. The page points to the Realtime API guide "to plan your migration," which means moving to a different API surface and rewriting the integration. The three months run regardless.

What to do before November 30

1. Export your usage from the Claude Console. The deprecations page describes the audit: Usage page, Export, then a CSV broken down by API key and model. Start from that list.
2. Inventory every pinned model ID, including background jobs, evals and staging. A retirement hits the forgotten caller first.
3. Grep for tool_choice, thinking, temperature, top_p and computer_20251124, and find any assistant-prefill code. Plan the move to auto plus strict, together with the prompt change that tells the model when to call the tool.
4. Send the thinking-binding-controls-2026-08-01 header in staging, replay stored conversations across accounts and through your fallback path, and check input_transformations.
5. Re-run your own eval set before switching traffic. The price cut is certain; whether quality holds on your prompts is something only your data shows.

If you use Claude Code, the migration guide documents a /claude-api migrate command that applies the ID swap and the breaking parameter changes, then lists what to verify by hand. Review its output like any other diff.

A crowded week for deprecations

AI API Change Radar, an independent tracker built from official documentation, counted six deprecation announcements for September 28 to October 4, its highest weekly count so far. We checked the Anthropic and OpenAI entries against the vendors' pages. The others come from the tracker, so confirm them on the vendor changelog before acting:

• Google's three Veo 3.1 preview models now shut down on October 22, with gemini-omni-1.1-flash as the target.
• Mistral retired OCR 4.0 on September 30, one day after its changelog announced it.
• Z.ai's GLM 5.2 on Mistral retires October 31. Its successor reached GA on September 28 and the deprecation followed the next day.
• OpenAI changed the recommended target for its retiring gpt-image-1 family from gpt-image-2 to gpt-image-2.5-sunburst or gpt-image-2.5-flare, without moving the shutdown dates.

The Mistral OCR case shows the alias trade-off. Callers on mistral-ocr-latest moved to 4.1 without noticing; callers pinned to mistral-ocr-4-0 had one day to switch. A pinned ID breaks on the shutdown date, and an alias changes the model under you without a deploy. Either way, someone has to own the changelog.

What we're watching next week

The OpenAI image entry is the pattern we expect to see more often: a team adopts the published migration target, and the target changes before the old model is gone. For Anthropic users, the date to watch is October 15, when Haiku 4.5 passes its "not sooner than" floor.

The cheap defence is a one-page inventory of every model ID, tool_choice setting and thinking configuration in production, each with a shutdown date and an owner. We are building that inventory for our own stack this week, starting with the forced-tool call paths that still assume Sonnet 5 behavior. If you want a second pair of eyes on yours before November 30, get in touch.