Your AI agent has an expiry date

The model your agent runs on will be retired, most likely within twelve to eighteen months, and you will be told two months ahead. This is not an incident to dread, it is a maintenance operation to put in the calendar, in the same way as a database version upgrade. What separates the teams who get through it in half a day from those who lose three weeks comes down to one thing, prepared long before the announcement lands.

The dates are public and recent. Claude Sonnet 4 and Claude Opus 4 were retired on 15 June 2026 with 62 days’ notice; Claude Opus 4.1, released in August 2025, was retired on 5 August 2026 after 61 days, which is exactly twelve months of life. On the OpenAI side, GPT-4, GPT-3.5 Turbo, o1 and o1-pro shut down on 23 October 2026, and the Assistants API closed on 26 August. A system written in 2024 and untouched since points today at model names, several of which will stop answering this autumn.

What notice does a provider actually give?

Enough to migrate, never enough to discover the problem on the day of the announcement. Anthropic commits to at least 60 days for a publicly released model, and both 2026 retirements landed within a day or two of that commitment. OpenAI states six months for a generally available model, three for a specialised variant, and only two weeks for a preview.

That last line deserves a pause, because it catches people out regularly. A preview is what you try when a model has just shipped and you want to see what it does better; it is also, very often, what ends up in production because the trial went well and nobody revisited the configuration line. Two weeks’ notice on a central component is a Friday evening.

The practical corollary is short: pin a named version, never an alias that follows the latest. An alias switches your model overnight, with no deployment, no announcement and nobody on the team able to say what moved. Sixty days’ notice only protects those who wrote the full name.

What exactly breaks when the model changes?

Not the model call, which is fixed by changing one string. What breaks are the instructions you wrote to compensate for the previous model’s flaws.

Every agent in production carries a layer of patches, accumulated over months: the sentence that stops the model concluding too early, the example added because it confused two date formats, the instruction in capitals forcing it to check before asserting. Each of those sentences answered a real, dated behaviour. On a model that no longer has the flaw they are not neutral: they are still instructions, they consume context, and some of them produce the opposite excess. The line that stopped premature conclusions now makes a model hesitate when it was right.

The second area, less visible, is economics. An agent is billed mostly for context re-read at every step, and an agent’s cost comes from replaying that context rather than from the length of its answers. A new model changes the price per token, the window size, sometimes the behaviour of the prompt cache, and a migration that succeeds on quality can multiply the bill without anyone changing how they work. That is an hour’s check, provided you know it is a check to run.

The third is the quietest and the slowest to diagnose. An agent that keeps notes from one session to the next wrote those notes with the old model, in a style and level of detail the new one would not have produced. They remain readable, they are not wrong, and they still steer. This is the migration version of the problem we describe about what an agent’s memory has to forget.

Why the test set is the only real migration plan

Because it turns a matter of opinion into reading a table. We have argued for a long time that a trial is judged on thirty cases drawn from your own history, replayed three times, with the right answer written down before the first run. The argument was about buying: not letting a demonstration convince you.

The use that really pays that work back comes later, and nobody mentions it while you are doing it. Those thirty cases are what you replay on the day the retirement is announced. In half a day you get the exact list of places where the new model behaves differently, and the nature of each difference. Without the set, migration means replacing a model you knew poorly with one you do not know at all, then waiting for a user to report something. That is not a migration, it is a bet with a three-week reveal.

Variance matters as much as the result. A case that passes three times out of three on the old model and two out of three on the new one has not regressed by 33%, it has become unstable, and instability costs more than a clean error because it slips past the next round of tests.

What we learned migrating, and the rule we took from it

We have changed model several times since Balt started, and the first time went badly for a reason I now find obvious.

We had scattered the fixes. Some lived in the prompt, some in the code that prepares the calls, some in checks bolted on around the responses. Each had been written for a specific flaw in a specific model, and none of them said which. When migration came we could neither keep them all, having no idea what they cost, nor remove them all, having no idea what they protected.

The rule we have applied since fits in one sentence, and it lives in our engineering documentation rather than in a memo: a fix written for a given model lives in a section of the prompt reserved for that model, never in the code around it. The question that settles each addition is easy to ask: will this still be useful for a model two generations better? If the answer is no, the thing has a known expiry date and belongs somewhere you empty. If the answer is yes, it can live in the product.

The benefit did not show at the next migration, it showed at the one after. Emptying a labelled section takes an hour; dismantling a patch layer spread across three files takes a week and still leaves you unsure.

What to ask a vendor before signing

Not which model it uses, which is the question everyone asks and whose answer teaches you nothing. The model name is a snapshot; what concerns you is the vendor’s ability to change it without you.

Three questions do better, and they come in this order. How long have you been running on this model, how many times have you switched, and on what dates? What did the last migration cost, in working days and in regressions found? A vendor who answers precisely has a test set and uses it. A vendor who has never migrated is not at fault, it is young, and you now know the first migration will happen on your deployment.

These questions have a secondary merit, which is that they survive a demonstration. They are about what has happened rather than about what the product can do, and that is exactly the ground where a real agent separates itself from a wrapper.

What this calendar changes for your own deployment

It moves a category of spending. An agent is not software you install and leave running for five years; it is a component whose foundation is replaced by a third party every twelve to eighteen months, with two months’ warning. The operating budget needs that line, and the contract needs to say who carries it.

Datadog also reports that nearly seven companies in ten now run at least three different models, and that the share running more than six has almost doubled in a year. The retirement calendar therefore applies not once every eighteen months but three times, on different dates, decided by providers who do not coordinate with each other.

That is one more reason not to multiply the places where this choice gets made, and it meets a question that arises well before the model one: how many agents hold context about your company, and which of them will be migrated by somebody whose job it is not.