Claude Sonnet 4.5 Deprecation Audit

If a small script, notebook, or weekend helper still sends prompts to Claude Sonnet 4.5, the next failure is scheduled. Anthropic sent a September 30, 2026 notice to developers that Claude Sonnet 4.5 would leave the Claude API. Claude Sonnet 4.5 is scheduled to retire on the Claude API on November 30, 2026, with claude-sonnet-5-5 named as the replacement. After the retirement date, requests to Claude Sonnet 4.5 on Anthropic-operated platforms will fail.

Most weekend jobs will stay weekend jobs, and that is fine. The audit exists because a pinned model can keep a small script alive for months, then stop it on a date you did not set. Treat the deprecation as a short audit, not a single edit: find the pin, move the job to the replacement, and prove the request still works before the date passes.

The replacement changes the request, not just the name. Sonnet 5.5 tokenizes the same text into roughly 30% more tokens, with the exact increase varying by content. It also turns on adaptive thinking by default, and the tokens generated by thinking are counted as output tokens. A request to Sonnet 5.5 that uses budget_tokens thinking fails with HTTP 400; the supported path is adaptive thinking and output_config.effort.

Anthropic's deprecation schedule covers the Claude API, Claude Platform on AWS, and Microsoft Foundry, while Amazon Bedrock and Google Cloud use separate retirement schedules. If your job runs through a partner platform, check that platform before you trust the main date.

The audit is the part you can finish in a short block

Keep the list below. Each item is small enough to finish quickly, and each one removes a different failure mode.

Export recent usage and filter for the model ID you are retiring.
Find the pinned model string in the script, notebook, or config file.
Swap it for the replacement model name.
Re-check the output limit and any chunk sizes that assumed the old token count.
Estimate the token increase for your actual prompts.
Remove any rejected thinking parameter and replace it with the supported control.
Send a real request and confirm the response is still useful.

The first item matters because a small job can have more pins than you remember. The model string often lives in a place you do not check: an environment variable, a helper default, a copied prompt template, or a scheduled job that calls a wrapper.

The swap is boring, and that is the good part. The trouble starts after the model name changes, because the request may still carry assumptions from the old model. Fix those before the deadline.

Token math is the budget change

Even if the job runs the same number of times, the same prompt can consume more of the output budget and change the monthly spend. Re-check the limit and estimate the increase for your actual prompts, not just rename the model.

Thinking changes the shape of the response too. If the job was tuned for a fixed output budget, the new default can make the same task longer and more expensive. If the old code sets a thinking budget, expect the error before the deadline.

The last test is the real one

Do not stop at a successful status code. A small job can return a response that is technically valid and still useless for the task. Read the output the way your user would, then decide whether it needs a shorter prompt, a larger output limit, or a different chunk size.

If the job is a personal helper, the test is whether it still saves you time. If it is a small product, the test is whether the output is still good enough to keep a user. The audit is done when the new request works, the old pin is gone, and you know what the token change will do to your budget. Save the new config before you close the laptop.