The Model You Built On Has an End-of-Life Date Now

When a team builds a feature on top of a hosted AI model, it is easy to treat that model as a fixed part of the landscape, like electricity or the operating system. It is not. Providers publish new versions, mark older ones as deprecated, and eventually switch them off, on timetables the provider sets. An application that calls a specific version by name will, on the retirement date, either stop working or be silently redirected to a successor that does not behave identically. The dependency was always there; the deprecation notice is just when the organisation finds out. The blunt failure — the version is gone, the calls error — is the easy case, because it is loud. The insidious one is behaviour drift. Prompts are tuned, often unknowingly, to the quirks of a particular version: the phrasing that reliably produced valid output, the format the model happened to favour, the edge cases it handled. A newer version can be better on every published benchmark and still break a production workflow because it now formats a date differently, refuses a request the old one allowed, or is more verbose in a place where the downstream parser expected terseness. Nothing errors; the outputs are just subtly wrong, and the first sign is a customer complaint rather than a failed request. The remedy is to treat the model exactly as software engineering already treats every other external dependency, because that is what it is. Pin to explicit versions rather than a floating alias, so an upgrade is a decision and not a surprise. Keep a suite of representative examples with known-good outputs and run it against any candidate version, so drift is detected by a test rather than by a user. Put a thin abstraction between the application and the provider so that swapping a model is a contained change. And keep a migration runbook, because the retirement date is not negotiable and the scramble to move at the last minute is where the real breakages happen. None of this is novel; it is the ordinary hygiene of depending on something you do not control, applied to a category that has been treated as an exception because it is new and impressive. The teams that get caught out are the ones that wired a single version deep into a product and assumed it would always be there. The ones that do not are the ones that decided, early, that a model is a dependency with a lifecycle — and planned for the day it ends.