LLMSwaps

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

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. 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 entryAmazon 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 vendor has announced something in that column, hollow where it has not.
Entries with an announcementHow many entries carry an announcement in each column. Silence is the common case and is recorded as such.Entries with an announcementAmazon Bedrock4 of 5Gemini API4 of 5
Fig. 2 How many entries carry an announcement in each column. Silence is the common case and is recorded as such.
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. 3 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.

  • 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

4Sources

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.