Your AI Model Has a Shorter Support Window Than Your Database

On 3 August we published end-of-life dates for 19 AI models and named three that would retire within the month. All three landed on the day we said. gpt-5.2-chat-latest and gpt-5.3-chat-latest went on 10 August. imagen-4.0-generate-001 went on 17 August. Claude Opus 4.1 went on 5 August.

Being right about a date is not interesting on its own. What a second month of data makes possible is the question the first month could not answer: not which models retire, but how long a model lives in the first place, and how that compares with everything else in your stack.

Between 4 August and 4 September 2026 we ingested 1,759 published items - 1,569 releases published by vendors, plus 190 entries generated by our end-of-life tracker from vendor deprecation pages. The answer is in the second half, and it is worse than we expected.

The median model lives 365 days

Across the six model catalogues on the EOL tracker, 103 model cycles publish both a release date and a retirement date. Their median support window is 365 days.

One caveat belongs here rather than in a footnote, because it bounds everything below. Measuring a support window needs both dates, and only three of the six catalogues publish a machine-readable release date per cycle. OpenAI and Azure AI Foundry contribute nothing to the 365-day figure, and they are the two largest catalogues we track by volume. What follows describes Gemini, Claude and Vertex AI. Whether OpenAI and Azure are better or worse is not something this data can tell you, and we are not going to guess.

Model catalogue	Cycles measured	Median window	Mean window
Gemini models	40	249 days	298 days
Anthropic Claude	30	389 days	473 days
Vertex AI models	33	431 days	527 days

Claude Opus 4.1 is the tidy illustration: released 5 August 2025, retired 5 August 2026. Exactly one year, to the day. Gemini's embedding-2-preview had a shorter run than that - released 10 March 2026, retired 10 August 2026, a window of 153 days.

Now set that against the rest of the software estate, using the same tracker across every non-model product:

Product category	Cycles measured	Median window
Hosted service	287	1,127 days
Operating system	1,035	697 days
Database	390	550 days
Framework	790	398 days
Server application	2,593	329 days

A hosted model endpoint is, architecturally, a hosted service. You do not run it, patch it or size it. You call it over HTTP and pay per token. Every other hosted service we track carries a median support window of 1,127 days. Model endpoints carry 365.

Be precise about what that does and does not say. Model endpoints are not the fastest-moving thing in the table - server applications turn over faster, at 329 days, and frameworks are close behind at 398. Models sit mid-pack across software generally.

The mismatch is narrower and more specific than "everything retires faster now". A model endpoint is consumed like a managed service and retired like a self-hosted server application. You do not run it, patch it, size it or upgrade it in place. You call it over HTTP, pay per token, and carry none of the operational surface - which is exactly the deal that normally buys you a 1,127-day support window. On the retirement side you get 365.

Every instinct the managed-service model trains is therefore wrong here. Nobody schedules a migration for a SaaS API. That is the whole reason you bought a SaaS API.

Retirement is now mostly an AI problem

The imbalance is not only in duration. It is in volume, and it has become lopsided enough to change where a platform team should point its attention.

Twenty-three tracked products or model cycles crossed their end-of-life date during the window. Eighteen were AI models. Five were conventional infrastructure: GitLab 19.0 on 20 August, Databricks Runtime 13.3 on 22 August, Amazon RDS for MariaDB 10.5 on 31 August, Amazon MSK 3.7 on 1 September, and the Cloud Run functions Go 1.24 runtime on 2 September.

Azure AI Foundry alone accounted for nine of the eighteen models. AWS retired the Bedrock hosting of cohere.command-r-plus-v1:0 on 19 August.

The same skew shows in notice volume rather than crossings. Of the 190 lifecycle entries our tracker generated in the window, 157 - 82.6% - concerned model retirement. Two catalogues, Azure AI Foundry and OpenAI, produced 112 of them between them.

One month of crossings is a thin base for a trend claim, so treat the 18-of-23 split as a snapshot rather than a slope. The notice volume is the sturdier number: across 190 lifecycle entries, model retirement is not a category on the calendar any more, it is most of the calendar.

The dates themselves are not stable

We noted in passing last month that vendors move these dates. A month of data puts a number on it: ten tracked end-of-life dates changed during the window. Eight moved later. Two moved earlier.

The moves later were generous. OpenAI pushed o1 and o1-pro-2025-03-19 out by 92 days, from 23 July to 23 October 2026. Google pushed gemini-embedding-001 out by nearly two years, from 14 July 2026 to 14 May 2028. Azure moved gpt-4.1-nano from 14 October 2026 to 14 April 2027.

The two that moved closer are the ones that matter. GitLab 19.2 came in five days, from 20 October to 15 October 2026. Amazon RDS for MariaDB 11.8 came in by two years, from 30 June 2030 to 30 June 2028.

Consider what that second one does to a plan. A team that checked the MariaDB 11.8 date in early 2026 wrote down 2030, filed it as a problem for a future colleague, and moved on. That date is now 2028. Nothing notified them, because nothing was watching - the vendor updated a page, and the only signal was the diff.

An end-of-life date copied from a vendor page is a snapshot, not a commitment. Any process that reads a date once and records it will eventually be wrong, and the failure is silent until the API stops answering. This is precisely what change alerts exist to catch: the second notice, the one that says the date moved, is the one no manual process ever sees.

The client floor moved in the same month

Model migration would be manageable if the layer underneath held still. It did not.

Two of the largest AI vendors shipped breaking HTTP client migrations nine days apart, for the same underlying reason. The OpenAI Python SDK v3.0.0 made HTTPX2 the default on 12 August and stopped installing httpx automatically, breaking any application that supplies a custom HTTPX client, transport or configuration object. The Anthropic Python SDK v1.0 did the same on 20 August, and additionally raised the floor to Python 3.10.

This is not the usual story about SDKs drifting under you at 0.x. Both are deliberate, well-documented major versions, and OpenAI ships a temporary legacy escape hatch. The problem is coincidence of timing. A service that calls both vendors now has three migrations queued in one quarter: two HTTP client cutovers and at least one model swap. Each is individually reasonable. Together they are a quarter of platform work that appeared on no roadmap.

The pattern reaches past the API layer too. The GitHub CLI Linux package signing key expires on 5 September 2026. Anyone who installed gh from the official APT or RPM repositories before 8 April 2026, or who bakes it into custom images, needs their system to trust the replacement key or package updates simply stop.

Preview endpoints retire like previews. Teams use them like GA.

Several of the window's retirements were preview endpoints: embedding-2-preview, gemini-robotics-er-1.6-preview, gemini-omni-flash-preview. That is correct vendor behaviour, clearly signposted.

The failure is on the consuming side, and it is structural. A preview model ID is a string that behaves exactly like a GA one at call time. Nothing in the request path distinguishes them, no dependency scanner flags them, and no linter objects. So a prototype that hardcoded a preview model and then quietly graduated into production carries a retirement clock nobody set.

Across all platforms in the window, 275 releases were tagged preview against 830 tagged GA. Previews are a standing quarter of the surface area, not an edge case.

What to do about it

We argued last month that model IDs belong in your dependency inventory, not your configuration. The duration data changes what that inventory has to do.

Size the work from the 365-day median. A service calling three distinct model endpoints should expect roughly three migrations a year, as a scheduled line item rather than a contingency. That is arithmetic from the support windows above, not pessimism. Most teams currently budget zero.

Re-read retirement dates instead of recording them. Ten changed in a single month and two moved closer. Poll the vendor's deprecation page, or subscribe to change notifications on the products you actually run.

Grep for -preview in your model configuration. Ten minutes, with a real chance of finding a production path pinned to an endpoint that was never promised to survive.

Do not triage release notes by headline. Anthropic's 5 August platform update led with inference hooks in beta for Claude Enterprise - routing prompts through an organisation's own security server before inference - and retired Claude Opus 4.1 further down the same note. Classifying that by title files it as a feature and drops the deadline.

The load is increasing

As of 4 September 2026, the model catalogues we track carry 86 retirements scheduled in the next 90 days and 193 in the next 12 months. OpenAI accounts for 41 of the 90-day figure, Azure AI Foundry for 24, Bedrock for 10.

The nearest cluster is every version of OpenAI's Sora 2 - base, pro and dated snapshots - on 24 September 2026. The weekly editions covering 17-23 August and 24-30 August both carried these under "Attention Required", which is where they belong: individually small, collectively relentless, and easy to miss one changelog at a time.

The database team has known for decades that a major version is a dated commitment. The model endpoint is the same kind of commitment on a third of the timeline, and almost nobody is treating it that way yet.

---

Method and limits

Counts cover items with status='published' and published_at between 2026-08-04 and 2026-09-04 inclusive. Release-type figures use multi-label matching, since one release can carry several classifications.

Support-window medians cover only model cycles publishing both a release date and an end-of-life date - 103 of 412 tracked cycles, as flagged above. Sample sizes across the comparison table are uneven by an order of magnitude, from 287 hosted-service cycles to 2,593 server-application ones, so treat the small-n rows as indicative rather than settled.

Deprecation counts separate vendor releases from tracker entries deliberately. Only 40 of the 1,569 vendor-published releases carry a deprecation label - 2.5%. The other 190 deprecation signals come from the tracker reading vendor deprecation pages directly. Reporting the combined 230 as a share of "releases" would overstate how often vendors announce retirements in their release feeds, which is the reason the tracker exists at all.