AI model lifecycle and deprecation: plan the exit before it is urgent

What happens when a provider retires a model you depend on?

This is the one section that carries hard numbers, and it carries them because deprecation policies are published, dated and far more durable than the models they govern.

The three major managed inference planes each publish a lifecycle, and the three are not the same. On Amazon Bedrock a model moves through Active, Legacy and End-of-Life; it stays available for at least twelve months before its end-of-life date and spends at least six months in Legacy first, and the state is returned as a field on the model listing and retrieval API calls. On Microsoft Foundry, Foundry Models sit in exactly one of five stages, Preview, Generally Available, Legacy, Deprecated and Retired, where Legacy is optional and a model may go straight from GA to Deprecated, Deprecated blocks new customers while existing deployments keep serving, and Retired returns 410 Gone on every request. The commitments Microsoft attaches to those stages are stated against the release date rather than as a minimum time in each stage: a GA model carries a retirement date eighteen months out, set programmatically at launch, becomes Deprecated at twelve months, and its owner gets at least sixty days notice before retirement. On Google Cloud's Gemini Enterprise Agent Platform, generally available models are available for at least twelve months from initial release, while a model on short-term availability retires forty-five days after its replacement ships. Each of those is dated in the references below.

Three details on the Bedrock policy are worth pulling out, because they are the ones that turn a calendar into a cost and none of them is intuitive. A Legacy model does not simply persist quietly at the price you agreed: for models with end-of-life dates after 1 February 2026, after a minimum of three months in Legacy a model enters a public extended access period during which, in the documentation's words, you should expect higher pricing, set by the model provider. New customers cannot start using a Legacy model at all, and existing customers may lose access after fifteen days of inactivity. And migration, the page states plainly, will not happen automatically.

There is also a calendar problem hiding in the note at the top of that page, which says lifecycle dates published there are specific to Amazon Bedrock and may differ from dates published by the model providers themselves. Two calendars for the same model is a reasonable thing for a platform to do and an unreasonable thing to discover late. Track the one belonging to the plane you actually call.

As at 28 July 2026 the Bedrock legacy table listed models from five providers, AI21 Labs, Amazon, Anthropic, Cohere and TwelveLabs, with end-of-life dates falling inside the following six months. That is not a criticism of the platform, which documents its lifecycle unusually well. It is the point: this is the normal operating tempo rather than an exceptional event, and a portfolio has to be built for it rather than surprised by it.

One caution about reading those pages: the platform brands in this market are being renamed faster than the policies attached to them are being changed. Two of the three names above are recent. Navigate to the vendor's current lifecycle page rather than trusting a product name you remember, including the ones in this paragraph.

Put the three side by side and the engineering position falls out of them. The floor is measured in months rather than years, and the shortest of those windows is short enough that finding out by email is finding out late.

Four things follow. First, deprecation exposure is a property you can query rather than a newsletter you subscribe to. At least one of the three planes returns lifecycle state on an ordinary API call, so query it on a schedule, hold the answer beside your own register of which model serves which class of work, and alert on state change. The register is the load-bearing half of that sentence: most organisations cannot answer "what breaks when this model retires" because nothing anywhere maps models to workloads.

Second, pin versions, and know exactly what you pinned. A floating alias that silently upgrades does not solve your deprecation problem, it exchanges it for a worse one, where the system changes underneath you with no before-and-after run to compare against and no date on which it happened.

Third, budget the migration as work rather than as an interrupt. A twelve-month floor is enough time and it is not spare time, because a migration is an evaluation run, a prompt revision, a routing test and a staged rollout, and it competes with everything else in the quarter it lands in.

Fourth, and this is the one that catches people, the judge has a retirement schedule too. If your evaluation judge is a hosted model, it will be retired on the provider's calendar rather than yours, and a retired judge means your accumulated result history stops being comparable at precisely the moment you need a comparison to justify the migration. Pin the judge apart from the system under test, with its own version and its own change window, and treat its migration as its own piece of work with its own held-out sample.

When do self-hosted open weights earn their keep?

The usual argument for open weights is cost and the usual argument against them is quality. Both are weak, and both age badly, because both are claims about a snapshot. The durable arguments are about control, and there are three cases where running weights inside your own boundary is the right engineering answer rather than a preference.

The data genuinely cannot leave. Not "we would rather it did not", but a residency, contractual or regulatory constraint that survives contact with a security review. This case is narrower than it was, because the managed planes have moved a long way on regional endpoints, private networking and explicit commitments about training on customer data. That narrowing makes the remaining case stronger, not weaker: what is left is the set of constraints that a commercial commitment does not satisfy.

You need a pin nobody else can move. A model you can still run in three years to reproduce a decision, on hardware you control, is worth real operational cost in a regulated setting. Reproducibility is a compliance property rather than an engineering nicety, and it is the one property a managed endpoint cannot sell you, because its lifecycle policy is the whole point of the section above.

The work is narrow, high volume and tightly specified. Classification, extraction, routing, redaction and normalisation, where a small model doing one thing well, at volume, with a validator on its output, is a better fit than a general model doing it as an aside.

What that costs, stated honestly, because the case for open weights usually leaves this part out. You take on serving, which means batching, cache management, quantisation and the quality cost that comes with it. Capacity planning for spiky traffic against accelerators that are not elastic. Patching and supply chain for the model artefacts themselves. And the entire evaluation apparatus you needed anyway, plus the share of it the provider was quietly doing on your behalf, because a hosted model arrives with a great deal of alignment work already done and often a separate guardrail service beside it, whereas weights arrive as weights.

There is also a licence question that belongs before the benchmark rather than after it. Open weights are not the same thing as open source, and the difference is contractual rather than philosophical. Several of the most widely used weight releases ship under bespoke community licences with acceptable-use policies and commercial conditions attached, not under OSI-approved terms. The Llama community licence is the clearest example: a licensee whose products exceeded seven hundred million monthly active users in the preceding calendar month at the point of a release must request a separate licence from Meta, granted at Meta's discretion. That particular threshold will not bind most organisations. The general point will, because a licence with a scale trigger, a field-of-use restriction or a clause about training competing models is a procurement question, and procurement questions found late are expensive.

Where does model lock-in actually live?

The version of this argument that arrives in vendor material is that using one provider's model locks you in and adopting an abstraction layer sets you free. Both halves are wrong, and they are wrong in the same direction, which is that they both locate the lock-in in the model.

The model is close to the most portable part of the system. Weights sit behind an API that looks broadly like every other provider's API. What actually holds you is everything wrapped around it.

• The prompts for the reason given in the substitution section above. Portable in form and not in behaviour.
• The tool and function-call schemas and the retry and repair logic built around one provider's format and one provider's failure modes.
• The evaluation corpus and the judge portable in principle and expensive to re-baseline.
• The retrieval index and its embedding model where a change means re-embedding the whole corpus and re-tuning retrieval afterwards.
• Any fine-tune or adaptation which is not portable at all.
• The guardrail policies and the acceptance tests written against them.
• The identity, network and data-residency arrangements which in a large organisation usually took longest to get approved and will take longest to get approved again.

Which is why the generic abstraction layer, the one that promises a provider swap in one line, is the wrong answer to a correct observation. It gives you the lowest common denominator of every provider's capability, it breaks on precisely the features you chose a model for, and it puts a dependency you now have to operate directly in the request path. What it does not do is make a swap safe, because safety comes from the evaluation run and not from the interface.

The boundary worth building is narrower than that and it is yours. One internal interface per class of work, expressing what your system needs rather than what every provider offers: this input shape, this output schema, this latency budget, this tier, this guardrail policy. Provider-specific handling gets absorbed behind it, at the edge, where it is allowed to be ugly. That is the same move as putting one governed toolset in front of several assistants rather than letting each one carry its own copy of the decisions that matter: absorb the differences at the edge, keep one shape in the middle.

Who owns the model lifecycle decision?

The pattern we see repeatedly is that model choice is treated as an engineering decision right up until the first time it becomes a governance question, at which point it becomes an urgent one, usually during a procurement or a security review with a date attached.

Part of what makes it a governance question is that obligations now attach to it upstream. Under the EU AI Act, obligations for providers of general-purpose AI models entered into application on 2 August 2025: technical documentation about the model, information passed downstream to providers of AI systems built on it, a policy for complying with Union copyright law, and a published summary of the content used for training, with models placed on the market before that date required to comply by 2 August 2027. That regime binds model providers rather than the organisations buying from them, and it only reaches systems placed on the EU market, so it is an illustration rather than a universal rule. The reason it matters to a buyer anyway is direct. The documentation you need in order to place your own system on a market is documentation you obtain from the model provider, which makes provider documentation a selection criterion at the point of choosing rather than a thing to chase afterwards, and it makes the availability of that documentation a real difference between candidate models rather than a paperwork detail.

The same regime also draws a line that matters when you are comparing candidates. Under Article 51, a general-purpose model is presumed to have high impact capabilities, and therefore to carry the heavier systemic-risk obligations, when the cumulative compute used to train it exceeds ten to the power of twenty-five floating point operations. You are not expected to know a model's training compute. The point is that a bright line exists, that it sorts the market into two regulatory classes, and that the class a model sits in changes what its provider owes you in documentation and what a reviewer will ask you about it.

The other part is simply that somebody has to own the list. The practical answer is a standing decision rather than a project: a named owner for the portfolio, the register described above, a review cadence tied to the shortest deprecation window in the estate rather than to the budget cycle, and a hard rule that no model enters or leaves the serving path without a harness run behind it.

Model Lifecycle References

- Amazon Bedrock model lifecycle, checked 28 July 2026, for the Active, Legacy and End-of-Life states, the minimum twelve-month and six-month windows, and the lifecycle field returned on the foundation model listing and retrieval calls. - Foundry Models lifecycle and support policy, Microsoft Learn, checked 28 July 2026, for the five lifecycle stages, the eighteen month GA retirement date set at launch, the twelve month point at which a model becomes Deprecated, and the minimum sixty days notice before a GA model retires. The page states no minimum time in the Legacy or Deprecated stages, so no such figure is quoted here. - Model versions and lifecycle, Gemini Enterprise Agent Platform, Google Cloud, checked 28 July 2026, for the twelve-month general availability floor and the forty-five-day short-term availability window. - Amazon Bedrock pricing, on-demand text model rates as published on 28 July 2026, for the order-of-magnitude spread described in the tiering section. Only the shape of the range is quoted, not its endpoints: the page mixes per-thousand and per-million units across dozens of models and rates vary by region, so a quoted pair would be both fragile and hard to check. Read the current page rather than this one. - MMLU-CF: a contamination-free multi-task language understanding benchmark, Qihao Zhao and colleagues, arXiv:2412.15194, December 2024, for benchmark contamination as a documented problem rather than a suspicion. - Line Goes Up? Inherent limitations of benchmarks for evaluating large language models, James Fodor, arXiv:2502.14318, February 2025, for the construct-validity argument against reading benchmark performance as generalisable competence. - EU AI Act, Article 51, checked 28 July 2026, for the presumption of high impact capabilities above ten to the power of twenty-five floating point operations of training compute. - FrugalGPT: how to use large language models while reducing cost and improving performance, Lingjiao Chen, Matei Zaharia and James Zou, arXiv:2305.05176, May 2023, for the LLM cascade pattern named in the tiering section. - Llama community licence, checked 28 July 2026, for the seven hundred million monthly active user threshold above which a separate licence must be requested. - Guidelines for providers of general-purpose AI models, European Commission, checked 28 July 2026, for the 2 August 2025 commencement of provider obligations and the 2 August 2027 date for models already on the market. - Evaluation harness infrastructure, the companion engineering piece on comparability, manifests, per-class floors and pinning a judge apart from the system it judges. This piece assumes it rather than repeating it.