LLMSwaps

Which model each app runs today, and when it last changed

Legacy period: the window between warning and removal

A legacy period is a named window between a warning and a removal: existing customers keep using a model, new ones cannot adopt it, and a date is set for the end. One platform in this register publishes one, in months or in days depending on the model, on the model card itself. As of 2026-09-22.

What a window like this settles, and where the sharp edges are. Recorded 2026-09-22.
What the window providesWhere it can fail a production
A stated length, before anything is scheduledLength can vary per model with no rule published
Continued access for existing customersAccess can end after a stated period of disuse
A date for the endRemoval is then global, with no fallback region
A middle condition, rather than on or offNew adoption stops immediately, so tests get harder

Inclusion rule. Read from the lifecycle documentation of the one platform in this register that publishes such a window. Order. What the window provides first, then its sharp edges.

1A middle condition is what makes a removal plannable

Available and gone are the only two conditions a model has from outside unless somebody names a third. A legacy window is that third, and everything a production can usefully do happens inside it.

It also concentrates the sharp clauses. The one window published in this register contains a sentence allowing access to end after a fortnight of disuse, which is shorter than the window by an order of magnitude.

Where the sharp clauses liveAvailable and gone are the only two conditions a model has unless somebody names a third. A legacy window is that third, and everything a production can usefully do happens inside it, including the clause that can close it early.One window, and the clauses inside itLegacy beginsWindow opensExistingcustomers keepaccess; newadoption stopshere.Disuse clauseDay 15Access can endif the modelwent uncalledfor afortnight.End-of-lifeWindow closesRemoval fromevery region.Requests failfrom thispoint.Most useful to teams already on the model, least useful to teams deciding
Fig. 1 New adoption stops immediately, which makes a clean comparison against the successor harder to set up.

2Closing the door to new adoption has a cost

Once a model is in a legacy window, a team cannot start using it, which sounds obviously right and complicates testing. A production comparing the legacy model against its successor may find it cannot set up a clean comparison.

So the window is most useful to teams already on the model and least useful to teams deciding whether to move. That asymmetry is worth knowing before a window opens.

3A length with no rule behind it

Where the published figure is six months for some models and forty-five days for others, with the choice made on the model card, a reader cannot compute their runway from the policy alone.

The policy is then a promise to state a figure rather than a promise about its size. Both readings are honest and only the second one lets a production plan before choosing a model.

A definition rather than a dated entry: no line above is a vendor statement. Where this word turns up in a real notice, the wording and the date are on the inactivity clause reading. Nearby terms: Sunset, Advance notice, General availability.