LLMSwaps

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

Output that left before the date arrived

Five video identifiers carry shutdown dates and nothing on the deprecations page concerns stored material. Output is returned per call, so a shutdown takes away the capability and reaches no file. The exposure here is reproducibility rather than retention. As of 2026-09-22.

What the deprecations page settles about material already generated. Recorded 2026-09-22.
What the page is askedWhat Gemini API publishesWhat that leaves open
Is disposal of material addressedNot addressed on the deprecations pageResults are delivered to the caller per call
What the shutdown removesThe ability to generate more from that identifierWhich is what a series in progress needs
Are earlier and later dates separatedYes, preview lines carry an earlier dateTwo dates for what looks like one family
Is reproducibility addressedNothing states that output stays reproducibleEven before a date, an update can move it

Inclusion rule. Read from the deprecations page for this interface, restricted to video identifiers. Storage terms for other products from the same company are out of scope. Order. The absence first, then what the dates actually remove.

1Retention and reproducibility are different worries

A library that gets deleted is a retention problem and it is visible. An identifier that stops answering is a reproducibility problem and it is invisible until somebody needs another episode in the same look.

This entry has the second and not the first. That makes its column blank and its risk real, which is the combination a reader scanning for empty cells will misjudge.

2Two dates for one apparent family

The preview identifiers carry an earlier date than the generally available ones, so a team that built during the preview period is on the shorter runway without anything on the page grouping them as one decision.

That is worth recording here because reproducibility is per identifier. A production that pinned a preview string has a different deadline from one that pinned the released string, even where the output looked the same.

Two dates inside what looks like one familyPreview identifiers carry an earlier shutdown date than the released ones, so a team that built during the preview period is on the shorter runway. Nothing on the page groups the two as a single decision.Which string your code containsPreview identifiersShut down 12 November 2025. The earlier date, and the shorterrunway.Released identifiersShut down 30 June 2026, stated as the earliest possible date.A moving aliasNot on the table at all. Nothing to match, and nothing to watch.The same page is a schedule for one caller and background for another
Fig. 1 Reproducibility is per identifier, so the pinned string decides which of the two deadlines applies.

3What to hold instead of a promise

Nothing in this column can be relied on to keep a look available, so the durable asset is the delivered file plus a record of which identifier produced it. Both are cheap while the identifier still answers.

The pinning page sets out what an identifier guarantees and where the guarantee stops, which is the part most teams assume covers more than it does.

  • veo-3.0-generate-001
    30 June 2026veo-3.0-fast-generate-001 and veo-2.0-generate-001, shutdown dateGoogle, Gemini deprecations / recorded 2026-09-22
  • veo-3.0-generate-preview and veo-3.0-fast-generate-preview
    12 November 2025shutdown dateGoogle, Gemini deprecations / recorded 2026-09-22

4Sources

Read from the deprecations page on ai.google.dev, 2026-09-22. The whole entry is on Gemini API, and the column it sits in is on Stored work. Same column, other entries: Wan-AI, fal.