LLMSwaps

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

Region availability: the escape route that is closed

Multi-region platforms train customers to solve availability problems by moving. One platform in this register states that at end-of-life a model is removed from all regions and requests fail, which closes that route explicitly and leaves migrating to another model as the only path. As of 2026-09-22.

What has been announced, entry by entryFilled where the vendor has announced something in that column, hollow where it has not.What has been announced, entry by entryWhat the page statesWhat the pagestatesMoving to another regionMoving to another region — What the page states: Removal is from all regionsFinding an older deployment somewhe…Finding an older deployment somewhereFinding an older deployment somewhere — What the page states: Requests to the model failWaiting for a staged rolloutWaiting for a staged rollout — What the page states: No staging is describedMigrating to another modelMigrating to another model — What the page states: The route left, and not performed for you
Fig. 1 Filled where the vendor has announced something in that column, hollow where it has not.
What a global removal rules out. Recorded 2026-09-22.
A reader might tryWhat the page states
Moving to another regionRemoval is from all regions
Finding an older deployment somewhereRequests to the model fail
Waiting for a staged rolloutNo staging is described
Migrating to another modelThe route left, and not performed for you

Inclusion rule. Read from the model lifecycle page of the one platform in this register that addresses regional coverage at end-of-life. Order. From the routes ruled out to the one that remains.

1Explicit is better than silent here

Stating that removal is global removes an option customers would otherwise spend time exploring. It reads as unhelpful and it saves a week of investigation at exactly the moment a team has no week to spare.

Most entries in this register publish nothing about regions at all, so a reader cannot even tell whether the question applies to them.

Routes a reader tries, and the one that remainsMulti-region platforms train customers to solve availability problems by moving. Stating that removal happens in every region closes that route explicitly and leaves migrating to another model as the only path.Another regionRuled out; the pagestates removal isfrom all regions.So tryAn older deploymentRuled out; requeststo the model faileverywhere.So tryAnother modelThe route thatremains, and it isnot performed foryou.Most entries publish nothing about regions at allRegional coverage before a retirement changes for capacity and compliance reasons and is outof scope here.
Fig. 2 It reads as unhelpful and it saves a week of investigation at the moment a team has no week to spare.

2Regional differences still exist before a date

Nothing about a global removal implies uniform availability beforehand. A model can be offered in some regions and not others throughout its life, which is a capacity and compliance matter rather than a lifecycle one.

This register does not track regional coverage, because it changes for reasons unrelated to retirement and is rarely published as a dated statement.

3For a production, the region question is about latency and law

Where output has to be generated within a jurisdiction, or where a cross-border round trip is too slow, region matters continuously rather than at retirement. Those are real constraints and they are outside the scope here.

What the column does record is that one entry has closed the door on regional fallback as a retirement strategy. The sourcing page sets out what else is out of scope.

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 global removal reading. Nearby terms: Inactivity clause, Active deployment, Export window.