Let’s talk about the message thousands of developers got this year, telling them the AI their product runs on is about to be switched off.
And why “just upgrade” is never the small thing it sounds like.
There’s a specific email you learn to dread when you build software. It lands on a Tuesday, it reads friendly, and it’s titled something like “upcoming model deprecations.” Nine times out of ten nobody reads past the first table.
Here’s what that table says this month. On the twenty-third of October — eleven days from now — OpenAI switches off gpt-4o, gpt-4, o1, o1-pro, o3-mini, o4-mini and gpt-3.5-turbo. On the twentieth, Google retires gemini-2.5-pro, flash and flash-lite off Vertex. Anthropic retired Claude Opus 4 and Sonnet 4 back in June, and Opus 4.1 in August. Count them across 2026 — OpenAI, Anthropic and Google between them published somewhere near forty model retirements this year. Forty. In one year. And that’s just the closed ones.
Now think about what a model actually is inside your product. It isn’t a library you installed and then forgot. It’s a subscription to somebody else’s behaviour.
Your prompts are tuned to its quirks. Your evals were written against its specific failures. Your cost per request, your latency budget, the way it formats a date, the things it quietly refuses to say — all of that is a personality, and you built around the personality. So when the vendor retires the model, they haven’t switched off a feature. They’ve changed your product, without asking, on a date they picked.
Which is why “just move to the newer model” is the most expensive small sentence in software. Migration isn’t an update. It’s a rebuild with a questionnaire attached.
And here’s the part people keep missing. Pinning the version looks like control. You wrote the exact snapshot string into your config, you froze it, nobody can touch it. That isn’t control. That’s a delay. The model has an expiry date the way a person has a birthday, and the date was never yours to set. Pinning buys you time and nothing else. What it doesn’t buy is a plan — and most teams didn’t write one, so they get the notice and treat it like a house fire.
That’s the real pattern, and it’s worth saying before we get to the fix. This is not a quirk of AI. It’s the oldest dependency risk there is, wearing new clothes. Every layer of the stack that somebody else owns, they eventually move on their own schedule, for their own reasons, and you find out by email. Mainframe vendors did it. Cloud providers do it. App stores do it. The interface changed. The incentive didn’t.
The version that bites hardest is this one, though, because you can’t read the weights and you can’t self-host the flagship. With almost any other dependency, worst case you fork it. With a closed frontier model, there is no fork. There’s a migration guide and a deadline.
So if you build things — and plenty of you do — the moves aren’t clever. They’re just discipline.
Treat the model as a commodity, not a foundation. Put one thin layer between your product and whoever’s API you’re calling today, so swapping the brain is a config change and not a quarter of engineering. Keep a set of golden test cases — real inputs, real expected behaviour — that can run against any candidate model, so “does the new one hold up” is a number instead of a vibe. Keep at least one open-weight fallback you could actually spin up, even if you never touch it, because the option is the asset. And put migration on the books as a recurring cost, the way you budget for servers, because that’s exactly what it is.
The teams that got hurt this year were the ones who’d written a model name into the architecture like a load-bearing wall.
Step back from the engineering for a second, though, because there’s something bigger sitting under all of this. We spent twenty years learning not to build your house on land you don’t own. We’re now building the thinking layer of thousands of businesses on weights we can’t see, can’t copy, and can’t keep. That dependency is fine right up until it isn’t — and the day it isn’t, it isn’t your decision.
The principle worth holding onto is plain. Your product should not fall over because a company you have never met decided to change its roadmap. You should be able to keep working the way it worked yesterday — not forever, but on your terms, with your own tests, your own fallback, and your own clock.
Model deprecation is going to become as ordinary as a phone OS update. The only question is whether it’s a Tuesday fire drill or a line in your plan.
Build the layer. Keep the fallback. You’ve got this.