LLMSwaps

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

Credits converted into seconds against seconds priced directly

Both entries name the models behind their prices and neither publishes a notice period. The difference is the unit: one sells credits and explains how far they go on each model, the other prices seconds per named tier. That changes what a change to the page looks like. As of 2026-09-22.

What each pricing arrangement makes visible when something moves. Recorded 2026-09-22.
On this pointRunwaySceneMixer
Unit soldCredits, converted per modelSeconds, priced per tier
Models namedYes, each with a conversionYes, each with a version
A price change appears asA different conversion rateA different rate per second
A model leaving appears asA name gone from the tableA tier gone from the list
Notice publishedNothing about the table changingNothing about a tier changing

Inclusion rule. Both cells on a row come from the entry's own public price list. A rate quoted in coverage of either product is not used. Order. The unit first, then what each kind of change looks like.

1An abstraction layer changes what a reader can see

A credit is a unit the seller defines, so a change to what it buys and a change to which models exist look similar on the page. Pricing seconds directly removes that ambiguity at the cost of a less flexible product.

Neither is better commercially. For a register of changes the second is easier to read, because one number moving means one thing.

What an abstraction layer does to a changeA credit is a unit the seller defines, so a change to what it buys and a change to which models exist look similar on the page. Pricing seconds directly removes the ambiguity at the cost of a less flexible product.The page changesA conversion moves,or a model name is nolonger listed.Two readingsWith creditsA price change and aretirement look alikeon the table.AmbiguousWith secondsA rate change and amissing tier aredifferent events.Both make a swap provable and neither makes it foreseeableOnly the entry naming versions supports matching a maker's dated announcement to a purchasedline.
Fig. 1 Neither is better commercially; for a register of changes, one number moving should mean one thing.

2Both make a swap provable and neither makes it foreseeable

Because both name models, two dated readings settle whether a line moved. Because neither publishes a period, the reading always happens after the fact.

That is the position eleven applications in this register share, and these two are among the few where the reading yields a specific answer rather than a suspicion.

3Version granularity is where they part

One page names models with version numbers beside every tier. The other names models and variants against conversions, with version detail varying by row. Only the first supports matching a maker's dated announcement to a purchased line.

The version question sets out why that distinction decides whether anybody notices a retirement at all.

  • Notice before the credit table changes
    No date announced (as of 2026-09-12)nothing publishedRunway, pricing page / recorded 2026-09-22
  • Notice before a tier changes
    No date announced (as of 2026-09-12)nothing publishedSceneMixer, price list / recorded 2026-09-12

4Sources

Both readings come from the pages the entries publish themselves: Runway and SceneMixer, read 2026-09-22. The column being compared is Notice period. Other pairs: Runway and Luma, Firefly and Kling AI.