LLMSwaps

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

How a date gets onto this site

An end date is recorded only when the vendor that makes the model announces it in public. Model menus are recorded from the app's own pages. The two are kept on separate pages and linked, because they go out of step and the gap is the useful part. As of 2026-09-12.

Two kinds of page, read separately and kept on separate recordsA side-by-side comparison of the app's own model menu and the model vendor's announcement. The menu says what you can pick today and moves whenever the app changes it. The announcement says when a model ends and only the company that makes the model can publish one. The two go out of step, and the gap is the useful part.The app's menuThe vendor's announcementWhat it tells youWhat you can pick in the product todayWhen a model stops being servedWho can publish itThe app, at any timeOnly the company that makes the modelHow it is read hereFrom the app's own pagesFrom the maker's own pagesRecorded separately, then linked
Fig. 1 Menus and end dates come from different companies and move at different speeds. Merging them into one table would hide the only thing worth looking at.

1Vendor announcements only

A date counts when the company that makes the model publishes it: a help-centre article, a deprecation page, a changelog entry with an end date attached. Press coverage does not count, and neither does a model quietly disappearing from a reseller's list. Both can be accurate; neither is something a production can hold anyone to.

The same applies in reverse. A model with no announced date is recorded as having no announced date, not as supported, ongoing or safe. The blank means nobody has said. Where a date does exist, the register keeps what the page claims for it: one platform calls its dates non-extendable and another calls its dates the earliest a model might go, and those are two different promises wearing the same format.

2Menus come from the seller, dates come from whoever runs the model

An app page lists what that app says it carries. A model page lists what the model's vendor says about its life. When an app still names a model whose vendor has announced its end, both entries stay as they are and each links to the other.

Resolving that tension would mean guessing: whether the app will pull the model, swap it silently, or keep serving it through another route. None of that is published, so none of it is written down here. The reader gets both statements and the dates they were read.

3Where each menu was read

One page per entry, named below so a reader can open the same page and see whether the list has moved since it was copied. Where a seller keeps its model names on a priced page, that is the page used, because a marketing page names models the buyer cannot necessarily reach.

  • scenemixer.com — price list, model and version beside each per-second rate.
  • ltx.io — pricing page, house generations and licensed models on one table.
  • kling.ai — membership plans, two generations listed as benefits.
  • pika.art — pricing page, one model named across every plan.
  • invideo.io — model list, six makers aggregated under one subscription.

The eleven entries added in September 2026 were read the same way, and they fall into three groups. Seven are applications with a menu on a priced or promotional page. Three are cloud platforms whose lifecycle documentation carries dates and notice periods, which is where every published figure in this register now comes from. One is a publisher that puts the weights themselves on a repository page rather than selling access to an endpoint.

  • runway.com — pricing page, model names inside the credit conversions.
  • lumalabs.ai — plans page, house generations and a long licensed half.
  • adobe.com — plan comparison, partner models named against tiers.
  • hailuoai.video — home page, a single generation announced as live.
  • pixverse.ai — home page, models listed by the job each one does.
  • vidu.com — home page, a current generation priced per five seconds.
  • fal.ai — pricing page, each model priced on its own line.
  • learn.microsoft.com — retirement schedule, two dated sora-2 rows.
  • docs.aws.amazon.com — lifecycle page, three states and a notice period.
  • ai.google.dev — deprecations page, five Veo identifiers with dates.
  • huggingface.co — repository listing, published weights and a licence.

Reading a priced page has a second effect worth stating: it excludes models an app demonstrates but does not sell. A model in a launch post and not in a plan is not something a production can schedule around, so it does not enter the register until it appears beside a price.

4What is deliberately not tracked

Quality changes are out of scope. A model that is replaced by a newer version of itself may produce different output on the same prompt, and no vendor publishes a diff, so a register built on published facts has nothing to record. This site tracks whether the thing you built on still exists, not whether it still behaves the same.

One model family gets no page of its own, because the sellers that carry it do not use the same public names for the same thing, and giving it a page would mean deciding which seller's label is correct. Where a seller prints one of those labels on its own menu, the label is copied onto that seller's row exactly as printed, because what a page says is a fact even when the naming across pages cannot be reconciled.

5Dates and corrections

Every entry carries the day it was written and the day it was last confirmed against the announcement. Confirming an unchanged date still advances the second, which on a site about retirements matters more than usual: the interesting state is an announcement nobody has re-read since it was made.

Page dates follow content, not builds. If a vendor revises an announcement, the revision is the record and the entry here is rewritten to match it.