Between September 22 and October 7, Anthropic released three new Claude models: Opus 5.5, Sonnet 5.5 and Haiku 5.5. Then, on October 31, a single line appeared in the release notes for its coding tool. A faster mode on one of the older models would be switched off on November 30. After that date, requests using it would not quietly fall back to the normal speed. They would return an error.
None of that is a scandal. A month of notice, a clear date, and a named replacement is what a vendor doing this properly looks like. That is exactly why it makes a good example. If this is the well behaved version, it is worth asking what your organisation does with it.
Those two pieces of news are different kinds of event. A new model is an option. Nothing in your workflows changes until someone decides to use it, unless a tool is set to follow the newest model on its own. A retirement is a deadline. The option you rely on goes away on a date you did not pick, whether or not anyone is ready. The first calls for testing before adoption. The second calls for a continuity plan.
Banks already know how to do this
Nobody in a bank swaps out a core system on a Tuesday because the supplier sent a newsletter. There is a test environment, a change request, someone who approves it, a record of what was decided, and a way back if it goes wrong. That is the control: the testing, the approval, the evidence and the recovery.
AI tools arrive by a different door. With hosted AI tools, the supplier controls which models remain available. Whether your workflow changes automatically depends on how the tool is configured. The notice comes as a line in a changelog, a banner in an app, or an email to whoever signed up for the account two years ago. If nobody is assigned to read it, nobody does.
The change control process exists. It just has not been told that AI is a system.
“Better” is not the same as “the same”
A new model is usually better on the tests the vendor publishes. That is a different claim from “it will behave the same on your work.”
A newer model can format answers differently, be more or less cautious, write longer or shorter, or interpret an ambiguous instruction another way. Any of those can be an improvement in general and still break the one thing a team built around. If someone checked a workflow carefully against the old model, that check does not transfer to the new one automatically. It has to be done again, even if the new one is better.
What change control for AI actually needs
The starting points are familiar.
Know what you are running. For each workflow that matters, write down which tool, which model and which version, and whether that model can change without anyone choosing it. Important information should live in documentation, not in someone’s memory.
Give the release notes an owner. One named person whose job includes reading the vendor’s changelog and deprecation notices, and saying “this one affects us” when it does.
Keep a small test set. Start with a handful of real cases that represent the work, including ones that have gone wrong before and the unusual ones that trip people up. Use approved or anonymised examples. The more harm a wrong answer can do, the more rigorous the testing and review need to be. When a new model arrives, run them before switching, not after a customer notices.
Put the dates in a calendar. A retirement date is a deadline like a contract renewal. Treat it like one, with someone responsible for being ready before it, not on it.
Decide what happens on the day it fails. If the old option starts returning errors, what does the workflow do? “We will figure it out” is a plan, technically. A better one is chosen in advance: pause the workflow, send the work to a person, or switch to an alternative you have already tested. Once the vendor retires an option, there is no rolling back to it.
Why we look at this first
When we vet a third party AI tool, one of the five things we score is change control: how does this thing change after you have trusted it once? In our published case study on a vector editor with an AI interface, the honest answer was that the version we tested did not update itself, but newer versions add an update check. So the recommendation includes a line most people skip: check it again when you upgrade.
That line is not caution for its own sake. Trust in a tool is trust in a specific version. When the version changes, the trust has to be earned again, a little.
AI vendors will keep shipping fast. That is mostly good news, and fighting it is a waste of energy. The work is on the receiving side: knowing what you run, telling an option from a deadline, and checking before you switch. Banks already have the muscle for this. It just needs to be pointed at a new kind of system.
This post was drafted with an AI model and checked, cut and approved by a human. The dates in it were confirmed against the vendor’s own pages on the day it was written.
Sources
Claude Opus 5.5 announcement, Anthropic, September 22, 2026.
Claude Sonnet 5.5 announcement, Anthropic, September 28, 2026.
Claude Haiku 5.5 announcement, Anthropic, October 7, 2026.
Claude Code release v2.1.316, Anthropic on GitHub, October 31, 2026: the Opus 4.8 fast mode retirement notice.