LLMSwaps

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

Aggregating at the application layer or the maker layer

Both entries sell other companies' models and only one of them makes any. That changes who a customer can hold responsible: an application aggregating six makers has no schedule of its own, while a maker reselling others has its own generations on the same table as theirs. 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 entryinvideo AILumaOwn models on the menuOwn models on the menu — invideo AI: None; every line is another maker'sOwn models on the menu — Luma: Two house generationsSchedules the entry contro…Schedules the entry controlsSchedules the entry controls — invideo AI: NoneSchedules the entry controls — Luma: Its own two linesSchedules it inheritsSchedules it inherits — invideo AI: SixSchedules it inherits — Luma: Several, from other makersVersions givenVersions given — invideo AI: Makers named, versions mostly notVersions given — Luma: Versions named on the plan tableIs the mixture acknowledgedIs the mixture acknowledged — invideo AI: The list names six makersIs the mixture acknowledged — Luma: The plan wording names other makers
Fig. 1 Filled where the vendor has announced something in that column, hollow where it has not.
What aggregating at each layer changes about responsibility. Recorded 2026-09-22.
On this pointinvideo AILuma
Own models on the menuNone; every line is another maker'sTwo house generations
Schedules the entry controlsNoneIts own two lines
Schedules it inheritsSixSeveral, from other makers
Versions givenMakers named, versions mostly notVersions named on the plan table
Is the mixture acknowledgedThe list names six makersThe plan wording names other makers

Inclusion rule. Both cells on a row come from the entry's own published pages. A maker counted here is one the entry itself names. Order. Own models first, then schedules, then version detail.

1A maker that resells has a floor under it

If every licensed line were withdrawn, one of these entries would still have two house generations to sell and the other would have nothing. That is a difference in the worst case rather than in the ordinary one.

It also means one entry can be asked about part of its menu and the other can only pass questions upward. Neither publishes a route for doing so.

2Version detail is where they really differ

One names makers and mostly not versions, so a dated announcement about a specific version cannot be matched to anything purchased. The other names versions on the plan table, so it can.

That is a bigger practical difference than the layer question. A menu of makers is a marketing list; a menu of versions is something a production can audit against.

A maker that resells has a floor under itIf every licensed line were withdrawn, one of these entries would still have two house generations to sell and the other would have nothing. That is a difference in the worst case rather than in the ordinary one.Two places aggregation can happenAggregating at theapplication layerSix makers named, versions mostly not. No house line, and noschedule of its own.Aggregating at the makerlayerTwo house generations plus licensed rows, with versions on theplan table.What both lackAny published route for passing a maker's retirement on to asubscriber.One entry can answer for part of its menu; the other can only pass questions upward
Fig. 2 The bigger practical difference is version detail: a menu of makers cannot be matched to a dated announcement.

3One listed line already carries a date

The aggregated menu still names a model whose maker has announced that its interface closes. Both statements are current, and the register keeps them side by side without predicting what the application does next.

The habit that works at either layer is checking the maker rather than the reseller, which is the whole reason model pages and entry pages are kept separate here.

  • Models carried
    Google Veo 3.1, Sora 2, Kling AI, Wan AI, Pixverse AI and Hailuo AIaggregatedinvideo AI, model list / recorded 2026-09-12
  • Models carried
    Ray3.2 and Ray3.14 in house, plus Veo 3.1, three Kling entries, MiniMax H3 and three Seedance variantshouse and licensed on one tableLuma, plans and pricing / recorded 2026-09-22

4Sources

Both readings come from the pages the entries publish themselves: invideo AI and Luma, read 2026-09-22. The column being compared is Named replacement. Other pairs: PixVerse and Vidu, Bedrock and Wan-AI.