AI model deprecation: your AI agent has an expiry date

The AI agent you shipped last year runs on a component with an expiry date. It is also the only part of your stack that somebody else can switch off. Not quietly deprecate in a changelog, but switch off, on a date they picked, with as little as 60 days of warning. That is AI model deprecation, and it is the one maintenance cost almost nobody puts in the proposal.

This article is written for founders, CTOs, and operations leaders who already have an AI agent in production, or who are about to approve the budget for one. If you are still working out whether agents are useful at all, this is not the right read yet. The problem described here only appears once something real is running and people depend on it.

In this article you will learn what AI model deprecation is, the two very different ways a model change hurts you, what the published 2026 retirement calendar actually says, how long a model realistically lasts, the 5 questions to ask before you sign off on an agent build, what a migration costs, and who should be paying for it.

Here is the short version. You did not buy a finished system. You bought a dependency on somebody else's product roadmap. Teams that understand this treat model changes as a scheduled maintenance line: budgeted, rehearsed, boring. Teams that do not meet it as an emergency, usually in the same week as something else going wrong.

‍

Key takeaways

• AI model deprecation is when a provider retires a model version, after which requests to it fail. It is a normal part of the lifecycle, not a rare event.

• Anthropic commits to at least 60 days of notice for publicly released models. OpenAI commits to at least 6 months for generally available models, 3 months for specialised variants, and as little as 2 weeks for preview models.

• In practice, a frontier model version stays available for roughly 12 to 18 months. Plan on replacing it at least once during the life of your agent.

• The shutdown is the cheap failure. It is loud, and your error logs catch it.

• The upgrade you choose is the expensive one. The API keeps returning success, and the behaviour drifts quietly instead.

• The single biggest cost driver is how many places the model version is written down in your codebase.

• Without a saved set of real test cases and an agreed pass mark, you cannot prove a replacement model is safe, so every migration becomes a negotiation about opinions.

• A well built agent absorbs a retirement in 1 to 3 planned days. A badly built one loses 2 to 6 unplanned engineer weeks.

‍

What is AI model deprecation?

AI model deprecation is the process by which an AI provider marks a specific model version as no longer recommended, assigns it a retirement date, and then withdraws it. After the retirement date, requests to that model fail rather than degrade. The model does not get worse. It stops existing.

Providers use a fairly consistent set of lifecycle labels. A model is active while it is fully supported. It becomes legacy when it stops receiving updates. It is deprecated once a replacement is recommended and a retirement date is published. It is retired when the endpoint stops answering.

None of this is hostile. Providers retire old models to free up capacity for new ones, and they publish the dates openly. Anthropic maintains a public model deprecations page listing every retirement it has announced, and OpenAI does the same in its deprecations documentation. The information has never been hidden. What surprises people is that nobody on their side of the table was assigned to read it.

That is the real gap. Model deprecation is not a technical problem that engineering forgot to solve. It is a supplier lifecycle problem that never got an owner, because when the agent was scoped, everyone was focused on whether it would work at all.

‍

The two ways a model change hurts you

Most articles on this subject treat deprecation as one event. It is actually two, and they behave so differently that lumping them together is what gets teams caught out.

The loud failure, which is the cheap one

A model reaches its retirement date and your calls start failing. You get errors. Somebody gets paged. It is embarrassing if it happens during business hours, and it is genuinely disruptive if the agent sits in a customer-facing path.

But notice what is good about this failure. It is unambiguous, it shows up in monitoring you already have, and nobody argues about whether it happened. You lose hours or a day, you swap the model reference, you ship. Painful, visible, bounded.

The quiet drift, which is the expensive one

Now consider the other case, the one nobody schedules for. The old model is going away, so you move to the recommended replacement ahead of the deadline. Everything returns success. Latency looks fine. The dashboards are green.

And the agent starts behaving slightly differently. It formats a tool call in a way your parser handles less cleanly. It becomes more cautious about a category of request it used to handle, so a small share of cases now get refused and quietly bounce to a human queue. It writes longer answers, which changes your token spend. It interprets an ambiguous instruction the other way.

None of that raises an error. Your logs are clean because from the API's point of view, nothing failed. The signal arrives weeks later through the side door: a support lead mentions the queue feels heavier, finance asks why inference cost moved, a customer says the tone changed. By then you have lost the ability to connect the effect to the cause, because a dozen other things also changed in those weeks.

This is the reframe worth holding on to. Loud failures cost you a day. Quiet drift costs you a quarter of slow confusion, and it is the one your current monitoring is not built to catch.

‍

What the 2026 model retirement calendar actually says

This is not theoretical, and it is not far off. Both major providers have published dates that land inside the next few months.

‍

‍

A few things in that calendar deserve attention. The OpenAI Assistants API retires on 26 August 2026, replaced by the Responses API. That is an interface change, not a model change, which means agents built directly against it need code work rather than a configuration swap.

On 23 October 2026, GPT-4, GPT-3.5 Turbo, o1 and o1-pro shut down. A large number of production systems built between 2023 and 2025 still point at exactly those names. And on 11 December 2026, the August 2025 snapshots of GPT-5 and o3 go too, which is worth sitting with: a model that shipped in the middle of 2025 is switched off before the end of 2026.

On the Anthropic side, Claude Sonnet 4 and Claude Opus 4 retired on 15 June 2026 after 62 days of notice, and Claude Opus 4.1 retired on 5 August 2026 after 61 days. Both were inside the published policy of at least 60 days. Both were also, if you were not watching for them, about 2 months from email to dead endpoint.

‍

So how long does a model actually last?

Roughly 12 to 18 months. That is the number to plan around, and you can derive it from the dates above rather than taking anyone's word for it.

Claude Opus 4.1 was released in August 2025 and retired in August 2026, which is 12 months almost exactly. The GPT-5 snapshot dated August 2025 retires in December 2026, which is about 16 months. Claude Sonnet 4, released in May 2025, retired in June 2026, so 13 months. The pattern is consistent enough to budget against.

So if you are commissioning an AI agent today and expect it to run for 3 years, you are not buying one model. You are buying 2 or 3 model migrations, whether or not anyone put them in the proposal. That is the sentence most agent proposals leave out.

It is worth being fair to the providers here. Notice periods are published, replacements are recommended, and the newer model is usually better and often cheaper per token. This is not a trap. It is simply a maintenance cycle that the people approving the budget have not been told about, because it is invisible during the phase when everyone is excited about the demo.

If you are working out the wider economics of running agents in production, our SaaS AI Blueprint covers how to budget for AI systems past the launch, including the running costs most first proposals leave out. It is free and takes about 20 minutes to read.

‍

5 questions to ask before you sign off on an AI agent

You do not need to become technical to manage this risk. You need to ask 5 questions at proposal stage, while the answers are still cheap to change, and listen for whether the answers are specific or vague.

‍

‍

The first question sounds trivial and is not. If the answer names a model family rather than a dated version, the agent is pointed at a moving target: the provider can change what sits behind that name without telling you, and your behaviour changes with it. You want a specific dated version, pinned deliberately.

The second question is the one that actually predicts your cost. A model version written in one configuration file is a 10 minute change. The same version pasted into 40 places across services, scripts, and notebooks is a scavenger hunt, and it is the difference between a calm afternoon and a bad fortnight.

The fourth question, about who does the migration and on whose budget, is the one buyers skip most often and regret most reliably. If the build contract ends at launch and says nothing about model changes, then the first retirement arrives as a fresh negotiation with a partner who now has all the leverage, because they are the only ones who know how the thing works.

Ask these 5 questions and you will learn a great deal about how the agent is going to be built, long before you see any code.

‍

What changes when an agent is built for model change

The gap between an agent built for one model and an agent built to survive model change is not a difference in sophistication. It is a handful of unglamorous decisions taken early, none of which are expensive at build time.

‍

‍

Here is what that difference looks like in practice. Two companies get the same retirement email on a Monday morning for a model their invoice-processing agent depends on.

The first company has the model version in one place and a saved set of 300 real invoices with the answers a human already agreed were correct. They point a copy of the agent at the replacement model and run those 300 cases. It scores 292 correct against a previous 294, and the 2 new misses are both an unusual credit note format. They adjust the instructions, run it again, get 295. They route 10 percent of live traffic to the new model for 2 days, watch the numbers hold, then move the rest. Total elapsed effort: about 2 days, done a month before the deadline, by one person.

The second company does not know how many places reference the model. There is no saved test set, so proof of correctness means an analyst manually spot-checking whatever comes through this week. They find references in the main service, then in a nightly reconciliation job nobody had thought about, then in a reporting script owned by a person who has left. They switch everything over on the final weekend because the deadline forced it. Three weeks later, finance notices that a category of supplier credits stopped being flagged. Nobody can say for certain when it started.

Same email, same provider, same 60 days. The difference was decided at build time, by people who were not in the room when the budget was signed.

‍

Why the test set is the asset you are really buying

If you take one operational thing from this article, make it this: the most valuable artefact in your AI agent is not the prompt and not the code. It is the saved set of real cases with agreed correct answers, and the pass mark you decided was good enough.

Prompts get rewritten. Model versions get retired. Frameworks get replaced. The test set outlives all of it, because it encodes something none of your suppliers can give you: what your business considers a correct answer. That judgement came from your people, your policies, and your edge cases, and it is genuinely yours.

It is also what converts a migration from an argument into a measurement. Without it, "is the new model good enough?" is a matter of opinion, and opinions cannot be settled before a deadline. With it, the question has a number attached, and the decision takes an afternoon.

A useful test set does not need to be elaborate. A few hundred real cases drawn from actual traffic, deliberately weighted toward the awkward ones, with the correct answer recorded and a pass mark you have agreed in advance. The awkward cases matter more than the volume, because the easy ones pass on every model and tell you nothing.

Build it during the first project, while the people who know what correct looks like are already paying attention. Retrofitting it 14 months later, under deadline, is how it ends up never being built at all.

‍

What a model migration costs, and who pays for it

For an agent built the first way, with a pinned version, a single reference point, and a real test set, a migration is 1 to 3 days of one engineer's time. Most of that is waiting for evaluation runs and watching the canary. It fits inside normal maintenance and rarely needs its own approval.

For an agent built the second way, budget 2 to 6 engineer weeks, and expect the cost to land in four places rather than one:

• Finding every place the model is referenced, which is unbounded work because you cannot know when you are finished.

• Manually establishing whether the new model is acceptable, because no saved test set exists.

• Fixing whatever the new model does differently, which is real engineering, not configuration.

• The tail of quiet drift you did not catch, which surfaces weeks later as support load, cost changes, or a bad customer conversation.

The commercial question matters as much as the technical one. If an outside partner built your agent, look at what your contract says about model changes, because most say nothing at all. Silence in a contract is not neutral here. It means the first retirement becomes a new quote, priced at a moment when you have no leverage and a fixed deadline.

Two contract terms are worth pushing for before you sign. First, a defined response for provider-driven changes: who acts, how quickly, and at what rate, so a retirement email triggers a known process instead of a negotiation. Second, ownership of the evaluation set in writing, so the test cases and agreed answers are your property and can move to another partner or in-house team. Neither is expensive to agree at the start. Both are close to impossible to get later.

‍

How we handle model changes at Codelevate

We run agents in production for clients, so we live with this cycle rather than describing it from a distance. Our approach is deliberately unexciting.

Every agent we build references its model version in exactly one place, and that version is always a specific dated string rather than a family name. Before launch we build the evaluation set with the client's own team, using their real cases and their definition of correct, and we agree the pass mark together so nobody is deciding it under pressure later. The client owns that set outright.

We keep an inventory of which model each client system runs on and check it against the published deprecation pages, so a retirement date reaches us as a calendar item months ahead rather than as an email on the morning it matters. When a change comes, we run the evaluation against the replacement first, compare against the previous score, move a small share of traffic, and keep the ability to switch back within a minute until we are confident.

None of this is clever. It is the difference between planned maintenance and an incident, and it is a large part of what separating a working demo from a system you can depend on actually involves. If you want a second opinion on an agent already running, our AI development team can review how yours is wired and tell you plainly whether it is exposed. It is also worth reading our piece on who owns your AI agent after launch, because model deprecation is one symptom of a larger question about ownership that most projects never answer.

‍

The bottom line

AI model deprecation is not a risk you can remove, because you do not control the supplier's roadmap. It is a risk you can make boring. The teams that do this well pin their versions, keep the reference in one place, own a real test set, agree who acts when the email arrives, and rehearse the swap before the deadline forces it.

The transformation on offer here is modest and worth a lot: moving from an agent that quietly becomes a liability every 12 to 18 months to one that absorbs a model change in a planned afternoon. That is the difference between an experiment and infrastructure.

‍

If you are budgeting for AI systems that have to keep running past launch day, the SaaS AI Blueprint is the most useful free thing we publish on the subject, and it covers the running costs that first proposals tend to leave out.

And if you already have an agent in production and cannot answer the first of those 5 questions, that is worth an hour. You can book a free call with our team and we will tell you where you stand, whether or not you end up working with us.

‍