When the model you build on stops answering

When the model you build on stops answering

We publish 122 AI models on our board. Yesterday, two of them became the first entries in the whole catalogue to record a date on which the model stops being served — and they only did so because the vendor happened to print that date on the same page as its prices, where we could not miss it.

That is an embarrassing number, and it is also the interesting one. A model listing that tells you the context window, the price per million tokens and the licence, and says nothing about how long the thing will exist, is describing a product as though it were permanent. None of them are. Every model on that board will stop answering, most of them within two years, and for anyone who has written code against one, the date that happens is worth more than any benchmark on the page.

So we went and looked. For the nine providers with the most models on our board — between them, 38 of the 65 listings that carry a structured provider name — we read the vendor's own developer documentation on 23 September 2026 and asked one question: does this company publish, on its own domain, a page that tells you when a model will be switched off?

Four of the nine do, properly. Two publish the date, but on the price list rather than anywhere a developer would look for it. Three publish nothing on their own site that you could plan against.

What we counted, and how

The board holds 122 published model listings, none archived. Sixty-five of them carry the structured specification we attach to a model listing — provider, family, parameter count where stated, context window, modalities, licence, release date and pricing — and those 65 name 40 distinct providers between them. The remaining 57 are older entries that predate the structured spec and carry a description only; they are a separate piece of work.

We ranked those 40 providers by how many listings they account for and took the top nine, treating a company's naming variants as one provider. Those nine cover 38 of the 65 listings. For each one we opened its own developer documentation — not a reseller's catalogue, not a model-hosting site, not a news report — and looked for a lifecycle, deprecation or retirement page.

Two things we did not do. We did not count a mention of a retirement inside an individual model's page as a lifecycle policy: a note attached to one model tells you nothing about the next one. And we did not count a third party's record of a deprecation, however accurate, because a buyer cannot plan against a page the vendor does not control and can contradict.

None of the 122 listings on this board are our own products, so there is no version of these counts with our own entries removed; they are the same numbers either way.

The three shapes of a good answer

Four of the nine publish something you could put in front of a risk committee, and they do it in three different ways.

The most complete is a table that gives every current model a date, not just the retired ones. One provider's deprecations page lists each model with its state — active, legacy, deprecated, retired — and a tentative retirement date expressed as a floor: not sooner than a named day. Its newest model, released on 22 September 2026, carries a floor of 22 September 2027, a year to the day. Alongside it sits a commitment to give at least 60 days' notice before retiring any publicly released model, and an explicit warning that the partner clouds which resell the same model set their own dates and are not bound by this table. That last sentence is the one most buyers need and least often get: if you bought your capacity through a cloud marketplace, the vendor's own schedule is not the schedule you are on.

The second shape is a ledger of announcements. Another provider publishes a deprecations page organised by the date the notice went out, each entry naming what is being removed, the shutdown date and the recommended replacement. It is less tidy than a per-model table — you cannot look up a model and see its date; you look at the queue and find out whether yours is in it — but it has a quality the table lacks, which is that you can see how much notice the company actually gives in practice rather than how much it promises. On the day we read it, the queue held seven dated shutdowns between 24 September and 11 December 2026.

The third shape is an honest partial. A third provider's page gives shutdown dates for a long list of models and, for many of the newest ones, says plainly: no shutdown date announced. It also states that the dates it does give are the earliest possible dates rather than the actual ones, with the real date to be communicated later. That is less useful for planning than it looks, but it is not evasion — it is a floor, published, in public, and a floor you can read is better than a date somebody knows internally.

The fourth of the four does something different again: rather than dates, it publishes the rule. Snapshot models get 30 days' notice before being taken offline, mainline models get three months, and — the detail worth reading twice — the throughput limits on a retiring model start falling from the day the notice goes out. That is a written commitment about how the ending happens, not just when, and it tells you something the date alone does not: the model does not work normally until the last minute and then stop. It degrades. If your capacity planning assumes otherwise, you will find out during the notice period rather than after it.

When the date is on the price list

Two of the nine publish the date, but not where you would go looking for it.

One prints, on the same page as its per-token prices, that the previous generation of two named models is deprecated at ten o'clock Beijing time on 21 October 2026, and recommends switching as soon as possible. The other carries a line on its pricing and models page saying that two legacy model names stopped resolving at a specific minute, expressed in UTC, on a named day — and they did.

There is an argument that this is the best of the lot. The price page is the page a buyer actually reads, more often than any documentation page, and putting the end date beside the cost is an honest juxtaposition: here is what it costs, and here is how long you have. A team comparing two models on price sees the expiry without having to think of the question.

The argument against is about durability rather than intent. A pricing page is rewritten whenever the prices change, and the notice goes with it. There is no archive, no feed, no changelog entry to subscribe to, and nothing that survives the product being withdrawn. A date you can only learn by re-reading a commercial page every week is not a commitment anyone can be held to; it is a courtesy that happens to be accurate today.

The three that publish nothing you can plan against

The remaining three of the nine had, on their own domains and on the day we looked, no lifecycle page at all.

One publishes extensive model documentation — prices, context windows, reasoning settings, regional endpoints, the lot — with no page covering deprecation, retirement or notice periods anywhere in it. The information is not hidden; it appears not to exist.

For the second, the only deprecation notice we could find for a model of theirs was published by a third-party host that serves their models, telling its own customers that a given version would stop being supported. That may well be accurate. It is also a statement by somebody else about somebody else's product, and it is not something you can put in a contract.

The third announced the retirement of a model family on a social-media account, with the offline date a week away; the models now return a not-found error when called. Anyone who was not following that account learned about it from the error.

None of this is unusual, and none of it is malicious. Publishing a lifecycle page is a commitment, and a young company shipping a model every six weeks has good reasons not to make one. But the absence is information. A vendor that has not published a retirement policy has not decided what its retirement policy is, and the first time it retires something you will find out what it decided at the same moment you find out you need to act.

What it actually costs you when there is no date

The reason this matters more than it sounds is that migrating off a model is almost never the one-line change people budget for.

Changing a model identifier is trivial. What is not trivial: a fine-tuned model does not survive the retirement of the base it was trained on, so the training run has to be repeated, which means the data has to still exist and the approval to use it has to still be valid. Evaluation results do not transfer, so whatever you measured to decide the first model was good enough has to be measured again. Prompts that were tuned against one model's habits behave differently on another. In a regulated setting, all of that is documentation as well as engineering.

And the tooling around the model has a lifecycle of its own. One of the dated shutdowns in the ledger we read is not a model at all: it is a reusable-prompts API, an evaluations dashboard and an agent builder, all going on 30 November 2026. Replacing a model id is a code change. Replacing the harness you use to decide whether the replacement works is a change to how the team makes decisions, and it lands in the same quarter.

There is a useful example this week from outside the model market entirely. A large code host published a schedule for removing an old SSH signature algorithm: a size requirement from 14 October, brownouts on 4 November and 9 December, and removal on — as printed in its own schedule — 13 January 2026, a date eight months in the past. The only reading consistent with the rest of the schedule is January 2027. It is a typo, and it will be fixed. But notice what having a published schedule made possible: an outsider could read it, check it against itself and find the error. Nobody can proofread a date that was never published.

What to ask before you build on a model

Five questions, in the order they are worth asking. They take about ten minutes and they are the whole of the diligence that matters here.

Where is the lifecycle page, and what is its URL? Not "does the vendor deprecate responsibly" — the URL. If a salesperson cannot produce one, that is the answer.

Does it give a date for the model I am about to use, or only for the ones already gone? A retirement history is evidence of behaviour. A forward-looking floor for the current model is a commitment. They are not the same and the first is much more common.

How much notice, and where is that written? Sixty days on a documentation page is a policy the vendor can change by editing the page. Sixty days in the agreement is a term. For anything you cannot rebuild in a quarter, ask for the second.

Who sets the date if I buy through a cloud marketplace? Several of the largest vendors say explicitly that the partner clouds reselling their models run their own schedules. If your procurement went through a marketplace because that was the easy path for the paperwork, the retirement schedule you are on may not be the one on the vendor's site.

What happens to my fine-tunes and my cached context? Ask the question even if the answer is obvious, because the answer is usually "they go too" and it is usually not in anyone's migration estimate.

What our own board records, and what we are changing

We should hold ourselves to the same standard, so here is where we fall short.

Our model listings carry a structured spec with a release date and no field for an end date. Sixty-five of the 122 published listings have that spec at all. Two of the 122 — the two added on 22 September — contain a sentence in the description giving a date on which a model stops being served, and they contain it because the vendor printed it beside the price and it would have been strange to leave out.

From today, a model listing we write records the vendor's published end-of-service date where one exists, and says explicitly where it does not. We will also go back over the four providers above that publish dates and add what they say to the listings we already hold for their models. That is a change to what we write, not to the schema; a proper field for it is a separate decision and we would rather record the sentence accurately first and design the column afterwards.

The 57 older listings with no structured spec are a larger job and we are not going to pretend otherwise. They are on the list.

None of this changes what a model is worth. It changes what you are buying: not a capability, but a capability with a shelf life that somebody else controls, and the vendors worth trusting are the ones willing to tell you when it ends.

Counts in this article were taken from our own published catalogue on 23 September 2026. Vendor lifecycle practices were read the same day on each company's own developer documentation. None of the 122 model listings on our board are our own products.