LLMSwaps

Announced end dates for video models, and which apps still carry them

Two ways a published window turns out to be wrong

Both entries publish something a reader would treat as a runway, and both are unreliable in opposite directions. One can close a window measured in months after a fortnight of inactivity. The other publishes dates described as the earliest a model might go, so the window can silently extend. From 2 source pages, read 2026-09-22; no maker pays to be listed.

What each page says, point by pointFilled where the entry's own page addresses that point, hollow where the page is silent on it.What each page says, point by pointAmazon BedrockGemini APIDirection of the errorDirection of the error — Amazon Bedrock: Shorter than publishedDirection of the error — Gemini API: Longer than publishedThe triggerThe trigger — Amazon Bedrock: Fifteen days without calling the modelThe trigger — Gemini API: Nothing; the date simply passesIs the trigger definedIs the trigger defined — Amazon Bedrock: Inactivity is not defined in callsIs the trigger defined — Gemini API: Not applicableIs a correction publishedIs a correction published — Amazon Bedrock: No notice is describedIs a correction published — Gemini API: None, the row may simply remainWho it catchesWho it catches — Amazon Bedrock: Productions that pause between blocksWho it catches — Gemini API: Teams that migrated early
Fig. 1 Filled where the entry's own page addresses that point, hollow where the page is silent on it.
How each entry's published window can turn out to be wrong. Recorded 2026-09-22.
On this pointAmazon BedrockGemini API
Direction of the errorShorter than publishedLonger than published
The triggerFifteen days without calling the modelNothing; the date simply passes
Is the trigger definedInactivity is not defined in callsNot applicable
Is a correction publishedNo notice is describedNone, the row may simply remain
Who it catchesProductions that pause between blocksTeams that migrated early

Inclusion rule. Both cells on a row come from the entry's own lifecycle documentation. A reader's estimate of how quickly a menu could change does not fill a cell. Order. The direction of the error first, then what causes it.

1Short and long are not equally expensive

A window that closes early strands work in progress. A window that extends wastes a migration done under pressure. The first is a production emergency and the second is a budget line, so these two failures are not symmetrical.

A reader with both pages in front of them can at least pick which error to plan for. Neither page presents its own behaviour as an error, and both are honest about the mechanism.

A window that closes early and one that drifts lateA window closing early strands work in progress. A window extending wastes a migration done under pressure. The first is a production emergency and the second is a budget line, so these two failures are not symmetrical.Your published window turned out to be wrong. Which way?Fifteen days without callsShorterAccess ends inside a window measured inmonths.The date simply passesLongerIt was published as the earliest, sonothing is corrected.One error strands work; the other wastes a migration
Fig. 2 Neither page publishes a correction, so both windows have to be verified by observation.

2An undefined trigger cannot be engineered around

The inactivity clause does not say what counts as activity, so a team cannot design a keep-alive with any confidence that it qualifies. That is a separate problem from the length of the window.

A defined minimum would be a mild inconvenience. An undefined one converts a published period into a risk that cannot be quantified, which is why the register records the two facts on separate rows.

3Nothing marks the day either window turns out to be wrong

Access ending early arrives as a failed request. A date passing without effect arrives as nothing at all. In both cases the page a reader was relying on stays exactly as it was.

That is the shared finding: neither entry publishes a correction, so both windows have to be verified by observation. The ending early column keeps every sentence of this kind in one place.

4The same question, put to a third entry

What SceneMixer publishes on this column, beside Amazon Bedrock and Gemini API. Recorded 2026-10-13.
On this pointSceneMixerSource
Work already madeSheets and segments already made keep their pixels and their record of which tier made them; versions are kept, and nothing is regenerated or charged by a fallbackSceneMixer, withdrawn tier guide
A tier that has been retiredA segment submitted on a retired tier is refused with a message before anything is held, and the selector no longer lists that tierSceneMixer, tier no longer exists guide

Inclusion rule. SceneMixer's own statements that bear on the column this pair was chosen for. Order. The statement closest to the column first.

All of its readings are on the SceneMixer entry.

  • How access can end before the date
    Once the Legacy period begins, existing customers may lose access after 15 days of inactivityAmazon Bedrock, model lifecycle / recorded 2026-09-22
  • What a date in that table commits to
    The shutdown dates listed indicate the earliest possible dates on which a model might be retiredGoogle, Gemini deprecations / recorded 2026-09-22

5Sources

Both readings come from the pages the entries publish themselves: Amazon Bedrock and Gemini API, read 2026-09-22. The column being compared is Ending early. Other pairs: Foundry and Sora, LTX Studio and SceneMixer.