LLMSwaps

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

Succession decided by six companies at once

This entry aggregates models from six makers, so succession is not one question but six, and none of them belongs to the company selling the subscription. Nothing on the page says how a maker's retirement would be passed on, and one listed model already has a published end date. As of 2026-09-22.

What an aggregated menu settles about who chooses the successor. Recorded 2026-09-22.
What the page is askedWhat invideo AI publishesWhat that leaves open
Is a successor namedNothing on the page names oneFor any of the six makers represented
Who decides successionEach maker, on its own scheduleSix schedules, none of them this company's
Is a dated line still listedOne listed model has a published end dateRecorded from the maker's own announcement
How would a retirement arriveNot described anywhere on the pagePresumably as a line leaving the menu

Inclusion rule. Read from the app's own published model list. Dates beside those models come from whoever makes them and are recorded on the calendar, not invented here. Order. The absence first, then who actually holds the decision.

1Aggregation multiplies the question, not the answer

A single-model entry has one unannounced future. This one has six, and the company a customer pays has authority over none of them. That is the structural point, and it holds regardless of how well the app is run.

It also cuts the other way. When one maker retires a line, five others remain on the menu, so the customer keeps a working product and loses a particular look. Whether that is a consolation depends entirely on whether a series was built on the line that went.

Six makers, and a menu that lags all of themA model list is a marketing page, so it changes when somebody updates it rather than when a maker publishes a date. One model on this list already carries an announced ending, and both statements are current at once.The makerPublishes a shutdown date forthe modelNot repeated downstreamA date that never reachesthe subscriberThe menuStill names the model to buyersEdited when somebody editsitA page that lags theannouncementThe subscriberPays one company, depends on sixNo notice describedSix changelogs to watch,in six formatsOne aggregated subscriptionWhere each fact stops travelling
Fig. 1 Resolving the tension would mean predicting what the app does next, which is the inference this register declines to make.

2A listed model with a published ending

One model on this list carries a date published by its maker. Both statements are current: the app names the model, and the maker says the interface behind it closes. The register keeps them side by side without resolving the tension.

Resolving it would mean predicting what the app does next, which is exactly the kind of inference this register refuses. A menu page is a marketing document and menus lag; the useful habit is checking the maker.

3What a subscriber can actually watch

Not this page. A menu can change without a notice, so the informative surface is each maker's own changelog, and there are six of them with no shared format.

That is the cost of aggregation stated plainly, and it is why the register keeps model pages apart from entry pages. The entry says what is purchasable; the maker says what is ending, and only one of those two ever carries a date.

  • Models carried
    Google Veo 3.1, Sora 2, Kling AI, Wan AI, Pixverse AI and Hailuo AIaggregatedinvideo AI, model list / recorded 2026-09-12
  • Sora API
    24 September 2026discontinuedOpenAI Help Center / recorded 2026-09-12
  • Named replacement model
    No date announced (as of 2026-09-12)none in the announcementOpenAI Help Center / recorded 2026-09-12

4Sources

Read from the model list on invideo.io, 2026-09-22. The whole entry is on invideo AI, and the column it sits in is on Named replacement. Same column, other entries: Adobe Firefly, Microsoft Foundry.