LLMSwaps

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

A menu of one against a menu gated by plan

Both entries answer the default question without stating a default. On one, every plan names the same house model, so there is nothing to choose. On the other, partner models are named tier by tier, so what a project can reach is decided at the checkout rather than in a setting. As of 2026-09-22.

How each entry settles which engine a project runs on. Recorded 2026-09-22.
On this pointPikaAdobe Firefly
How the answer is settledOne model on every planThe tier the subscription bought
What distinguishes the plansResolution and feature accessWhich partner models are named
Can the answer changeOnly if the single line movesBy a tier change, with nothing retired
Is the mapping publishedNot needed; there is one modelYes, tier by tier
Whose models are involvedOne house lineA house line plus several partners

Inclusion rule. Both cells on a row come from the entry's own priced pages. Models available in other products from the same company are not counted. Order. How the answer is settled first, then what can change it.

1Two stable arrangements, stable for different reasons

A single line is stable because there is nothing to switch. A tier gate is stable because the subscription fixes the answer until somebody changes plan. Both remove the unstated setting that most entries here leave unexplained.

The difference is who can move it. One answer moves when the maker ships a new version; the other moves when a pricing team restructures a plan.

2A tier gate creates a second way to lose a model

Everywhere else in the register a model becomes unreachable because it was retired. On a tier-gated menu it can also become unreachable because the tier moved, and the model continues to exist one plan above.

Identical effect for a production, and no lifecycle document is involved. The ending early reading covers which document would announce it, and the answer is a pricing page.

Two stable answers, moved by different peopleA single line is stable because there is nothing to switch. A tier gate is stable because the subscription fixes the answer until somebody changes plan. One moves when a maker ships a version; the other when a pricing team restructures.One line everywhereNamed per tierWho choosesNobody, there is oneThe buyer, at checkoutMoved byThe maker shipping a versionA pricing restructureMapping publishedNot neededYes, tier by tierLosing a model needsA retirementOnly a plan changeBoth are readable before paying, unlike an unstated default
Fig. 1 Both remove the unstated setting that most entries in this column leave unexplained.

3Publishing the mapping is what makes either legible

One entry publishes which partner model sits in which plan, which is more detail than most entries give. The other needs no mapping, because a one-line menu is self-describing.

Both are therefore readable before paying, which separates them from the entries where the starting engine is simply unstated. The default tier column records which entries manage that.

  • Models carried
    Pika 2.5 onlyin house onlyPika, pricing / recorded 2026-09-12
  • Which tier reaches which model
    Veo 3.1 Fast and Kling 3.0 are named in the Premium tier, Kling 2.5 Turbo in Pro PlusAdobe, Firefly plan comparison / recorded 2026-09-22

4Sources

Both readings come from the pages the entries publish themselves: Pika and Adobe Firefly, read 2026-09-22. The column being compared is Default tier. Other pairs: Kling AI and Hailuo AI, Luma and Vidu.