LLMSwaps

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

Finishing a season on the engine it started on

A season generated partly under one model and partly under another reads as two productions, regardless of how good both halves are. Audiences notice without being able to say why. So the decision is which side of a change to finish on, and it is better made than discovered. As of 2026-09-12.

The three ways a series meets a model change. Recorded 2026-09-12.
SituationThe decision it forces
A date is published, before the block startsStart on the successor, or finish early
A date lands mid-blockFinish the block, or regenerate the earlier episodes
No date, and output driftsEstablish what changed before touching prompts
An older generation is still on saleFinish where you started, deliberately

Inclusion rule. Situations a serial production actually meets when the model underneath changes. Order. From the most planned situation to the least.

1The cost is continuity, not the rate

People expect a migration to cost the difference in price per second. The real cost is that faces sit differently, the grade shifts and motion has a different character, and none of that is fixed by prompt work.

So a mid-series change is usually a choice between finishing on the old engine before it goes, or regenerating earlier episodes to match the new one. Both are expensive and the first is only available with warning.

2Unit discipline is the cheapest protection

Deciding in advance that a block of episodes is a unit, and that a unit does not straddle an engine change, removes most of the pain. It costs a little flexibility and it converts an emergency into a scheduling question.

Where a previous generation is still purchasable, that discipline is easy to keep. Where one model serves every plan, there may be nothing to finish on.

Three ways a series meets a change of engineWith warning before a block starts, the choice is which engine to begin on. With a date landing mid-block, the choice is a visible seam or regenerating earlier episodes. With no date at all, the first job is establishing that anything changed.The engine under your season is changing. When did you find out?Before the block startedA scheduling questionStart on the successor, orfinish the block early anddeliberately.Mid-blockA seam, or aregenerationBoth expensive. The firstis only available withwarning.From the outputA diagnosis firstEstablish what movedbefore touching anyprompts.Deciding a block is a unit, and that a unit does not straddle a change, removes most of the pain
Fig. 1 The cost is continuity rather than the rate, and no amount of prompt work fixes a seam cleanly.

3Check whether the old engine is still reachable

A change in a default is not always a retirement. Some products keep the previous model selectable, which turns an emergency into a scheduled migration and lets a unit in progress finish as it started.

This is worth checking before any recovery work, because it changes the deadline from today to whenever the older option goes. Nothing in this register says how long that is.

4Decide, then tell people

Whichever side the season finishes on, the people reviewing it will notice a difference and read it as a mistake unless told otherwise. A one-line note dated to the change prevents a round of corrections nobody can make.

That note also becomes part of the record. A production that can date its own engine changes can answer questions about its own back catalogue.

5Where each vendor's own wording lives

None of the above is a date. Announced end dates, and the apps still carrying the models they apply to, are kept on the calendar with the announcement each one came from.

Guidance rather than a dated entry. No line here is a vendor statement, and none should be read as an announcement. The sourced material is on the calendar. Related: Telling people downstream, Budgeting a migration.