AI Model Release Cycles - Versioning, Deprecation and Support

Software release cycles are built on the assumption that an old version keeps working. Large language models break that assumption: providers retire model versions on published schedules, and an application pinned to a retired model simply stops working. This article looks at how AI providers version and deprecate models, how that differs from the release cycles the rest of this blog tracks, and what it takes to build an application that survives the next retirement notice.

A different kind of release cycle

Most of the software covered on this blog follows a familiar pattern: a version ships, it is supported for a stated period, and when support ends the software keeps running - you simply stop getting fixes. An end-of-life Java 8 installation still executes.

Hosted AI models do not work this way. The model runs on the provider’s infrastructure, so when a version is retired it stops responding. There is no equivalent of continuing to run an unpatched version, and the retirement date is a hard cut-off rather than the end of a support commitment.

That single difference changes how applications built on them need to be designed.

How models are versioned

Providers generally offer two kinds of identifier:

An alias gives you improvements automatically at the cost of reproducibility: the same prompt can produce different output after a silent update. A pinned version gives stability until its retirement date, at which point you must move.

For anything where output is evaluated, logged, or forms part of a regulated process, pinning is the only defensible choice. Aliases are convenient for prototypes and for paths where variation is harmless.

Deprecation and retirement

Providers typically publish deprecation schedules with two dates: a deprecation date, after which a model is discouraged and often unavailable to new projects, and a retirement or shutdown date, after which requests fail.

The gap between those dates varies and has historically been measured in months rather than years. That is considerably shorter than the support windows for languages and databases, and it is the reason model choice deserves an owner and a review cadence rather than being set once at project start.

Practical habits that help:

• Subscribe to the provider’s deprecation feed or changelog. Retirement notices are published; missing them is an operational failure, not a surprise.
• Record the model identifier with every stored output. When behaviour changes, knowing which version produced which result is the difference between a quick diagnosis and an investigation.
• Track model identifiers in configuration, not in code. Changing a model should be a deployment, not a code change and release.

Designing for replacement

Because replacement is certain, the architecture question is how cheaply you can do it.

Keep the model behind an interface. A thin abstraction over the provider call lets you swap models, providers, or route different requests to different models without touching business logic.

Build an evaluation set before you need it. A few hundred representative inputs with expected characteristics turns a model swap from a subjective judgement into a measurement. Without one, every migration becomes an argument about whether the new model is worse.

Expect prompts to need adjustment. Prompts tuned against one model rarely transfer perfectly. Budget for tuning rather than assuming a drop-in replacement.

Watch structural changes, not just quality. Output format adherence, tool-calling behaviour, token limits, and pricing all change between versions and affect systems as much as raw capability does.

# Pin explicitly and keep the identifier in configuration
MODEL = os.environ["LLM_MODEL"]        # e.g. a dated, pinned version
response = client.messages.create(model=MODEL, max_tokens=1024, messages=messages)
log.info("generated", extra={"model": MODEL, "request_id": response.id})

Open weights change the calculation

Models distributed as open weights behave more like conventional software: once downloaded, they keep working indefinitely because you control the infrastructure. That removes retirement risk entirely, at the cost of operating the serving stack yourself.

For systems where a forced migration is unacceptable - long-lived archival processing, air-gapped environments, strict reproducibility requirements - that trade can be worth making.

Conclusion

AI model release cycles invert the usual assumption: the old version does not keep working. Retirement dates are published, gaps are measured in months, and an application that has not planned for replacement will eventually be forced into an unplanned one. Pin versions explicitly, keep identifiers in configuration, maintain an evaluation set, and treat model migration as a recurring operational task rather than a one-off.