Free reference · updated …
Each platform publishes its own dates for the models it serves, and those dates are the field most likely to be stale in a catalogue and the only one whose staleness breaks a caller’s code rather than merely misinforming them. These are read from the platform’s own documentation and stored exactly as written. The table shows them in year-month-day form, because one of these publishers writes 6/7/2025 and a column mixing that with September 10, 2026 has to be decoded before it can be read; hover any date for the publisher’s own wording, which is what the JSON carries.
A lifecycle date belongs to a model on a platform, not to a model. The same weights are retired on one platform months before another stops serving them, and neither publisher is wrong. So a model running in three places is three rows here, nothing is reconciled between them, and a date from one platform can never settle a question about another.
| Model | Platform | State | End date | Deprecated | Where | Source |
|---|---|---|---|---|---|---|
| Loading… | ||||||
Machine readable: lifecycle.json. Context windows and output limits are on the model limits reference.
Things about these dates that will bite you
One model on this page was retired on its own lab’s API in June and runs on another platform until October. Another is retired at the lab and available elsewhere into 2027. A catalogue that carries a model its lab has retired is therefore not necessarily wrong, and a check built on “the lab retired this” produces a false result every time. What makes a record wrong is a date on the platform that record actually routes through.
One platform gives every active model a retirement date phrased as a promise not to retire it before a certain day. That is a commitment about the earliest possible date and nothing else. Those rows are shown as the sentence rather than as a countdown, because parsing that sentence into a date asserts a precision the publisher deliberately declined to give.
One platform here publishes nothing but bare dates and then says, in a sentence above its tables, that the dates listed are the earliest possible days a model might be retired. Read a cell at a time, every one of those rows looks like a firm date; read the page, and none of them is one. They are carried here as floors for that reason, and the qualifier is checked on the page each time it is read — if that sentence ever goes, the harvest stops rather than quietly falling back to reading the cells on their own.
This is worth knowing if you are consuming anyone’s copy of this data, including mine. Two other public datasets of model deprecations were compared against this one in September, and each lost the claim type at the boundary in a different direction: one dropped a “not sooner than” and published the floor as a date, the other marked a provider’s plain dates as approximate. The dates themselves agreed almost everywhere. Whether a date is a commitment or a floor is the part that does not survive being copied.
Every row here carries end_kind, which says which of three things the
publisher actually wrote. exact is a date. floor is the promise
above. unstated is a row with no date in it at all, and that includes a model
already marked as deprecated whose retirement cell reads “To be announced”. The
distinction matters to anyone planning against these rows: a floor tells you the model has
at least that long, while a deprecated model with no date tells you it is on its way out and
you will not be told when. On one platform here every published retirement date is already
in the past, so the forward-looking cell on a deprecated model is empty by convention rather
than by omission.
A retirement or end-of-life date is the day from which the platform may close the route. It is not a measurement that the route closed, and the two come apart often enough to matter. On 22 September 2026, one model on this page was twelve days past its platform’s published end-of-life and answering at full uptime on that platform’s own status view; another was forty-eight days past its lab’s retirement of it and still listed, by that same lab, with a live endpoint. Neither publisher had said anything further.
So every phrase in the date column here is about the date and not about the service. A row whose date has passed reads end date passed 12 days ago, never ended 12 days ago, because this page reads what publishers write down and does not test whether anything still answers. If you need to know whether a route is live, the date is not that answer, and neither is a catalogue still listing the model — an id can keep returning 200 with nothing behind it.
One platform lists the regions each pair of dates applies in, and the lists differ from model to model: one row here covers twenty-three regions and another covers one. A schema with a single end-of-life field per model has nowhere to put that, and a model still serving in a region you do not use is not the same fact as a model still serving in yours.
Between the sources here the earlier date is called a deprecation date or a legacy date, and the later one a retirement date, an end-of-life date, or a shutdown date. The earlier date usually means no new usage; the later one is the day from which it may stop answering — see the note below on why that is not the same as the day it does. This page keeps each publisher’s own label rather than inventing a common vocabulary, because the words are not exact synonyms and flattening them loses which one you were told.
On one of these pages a single row omits the cell naming who made the model, with nothing in the markup to account for it, so that row renders shifted in a browser as well as in a parser. It appears here with the publisher blank rather than filled in from the model identifier, because filling it in would be inventing a fact the source does not state.
Worth knowing if you parse that table yourself: it also uses row spans, so reading it by position rather than by span puts an end-of-life date in the column before it and produces dates that look like the publisher’s mistake and are yours.
One of these pages is a log of announcements rather than a table, and it writes dates three ways in the same document: Feb 26, 2027, October 23, 2026, and 2026-09-24. Four of its dates use a non-breaking hyphen instead of an ordinary one, which looks identical in a browser and in a diff and stops an otherwise ordinary ISO date from parsing at all. A handful of its older entries also say “at earliest” before the date, which is a floor and not a date, the same as the “not sooner than” rows above.
One publisher here retires a version at a time, so a single model name carries several different dates. One of its models has three, and the earliest and the latest are ten months apart. The identifier on those rows is therefore the model and the version together; taking the name alone would leave you holding whichever of the three you happened to read.
Two of that platform’s rows are also listed twice, at the same name and the same version, with retirement dates seven months apart. Nothing here picks between them. There is no basis on the page for preferring either, both are marked, and both dates are on the marker.
Every other platform here is publishing about models it operates. One is a reseller, publishing a schedule for models somebody else trained, and that is a different kind of claim sitting in the same table. It is still first party, because it is that company’s own statement about its own service, and it is the only source that can tell you when a route through that company closes. What it cannot do is speak for the model. A lab retiring something says nothing about the reseller, and the reseller retiring something says nothing about the lab or about any other reseller.
It is also the only publisher here that announces in a dated changelog rather than maintaining a table, which makes its citations better than everyone else’s: those rows link the individual notice that named the model, not the page the notice lives on.
One notice on this page retires several models and then adds, against three of them, that they remain available on dedicated endpoints. Read the date alone and those three look like models that outlived their own retirement by months. Read the note and they are models that moved, exactly as announced.
Eight rows carry a note the publisher attached to that model inside the notice. Three are that caveat. The other five are release dates, one of them adding that the model was a time-limited trial, which is a plain answer to why it ended. They are marked and kept verbatim rather than sorted into the ones I think matter, because the reason a date needs reading in context is not something a schema can decide in advance.
These pages cover the models their publishers have dated. A model that appears on none of them has no announced end date that I have read, which is not the same as having no end date, and it is certainly not a statement that it will keep running. There are no rows on this page for models with nothing published, because an empty row would say something the sources do not.
Read from each publisher's own page on the date shown at the top, and rendered here from the same file the table is built from.