What a deprecation notice does and does not promise

These pages cover the mechanics behind the notices. A deprecation announcement is a commercial document, and reading it as an engineering schedule is how teams get caught. As of 2026-09-12.

Fig. 1 The gap between the two events is where migration work belongs, and it is rarely given a length.

The core distinction is between deprecated and withdrawn. Deprecated usually means no new features and no guarantees; withdrawn means the endpoint stops answering. Vendors frequently announce the first and leave the second undated, and a team that plans against the announcement rather than the shutdown has planned against nothing.

The vocabulary pages sit apart, under terms, because a word is not a notice. These pages are about what to do with the notices: how to read a lifecycle page in the order that settles a plan, and what to have in place before one arrives.

The rest are practical. What to record per delivered file, how to keep a test set that catches an update no page announces, where the money in a migration actually goes, and the four questions worth answering before a season depends on one engine.

1The explainers

Pinning a version — Pinning looks like the answer to models changing underneath a product.
After a swap — When the model under a product is replaced, prompts that worked stop working.
Surviving a retirement — Every model is eventually retired.
Deprecation words — The vocabulary around retiring a model differs by vendor.
Reading a lifecycle page — A lifecycle page answers four questions and usually buries two of them.
Recording per file — Model, version and date, recorded once per delivered file.
A frozen test set — A handful of prompts with known output, never improved, re-run after any suspected change.
Hosted or downloaded — A hosted model ends on a date you do not control.
Auditing your own strings — Most teams send a model name written months ago and forgotten.
Finishing a season — A series generated half on one model and half on another reads as two productions.
Telling people downstream — Editors and clients read a change in look as a mistake unless told otherwise.
Budgeting a migration — A migration is mostly not the difference in rate.
Watching a page — Most sellers here publish no dates, so two dated readings of the same page are the whole evidence that a model ever left.
Before committing a season — Is the model named on the page you pay from, is a period published, is there an older generation, and could you finish if it went in ninety days.

These pages add no dates to the calendar. They exist so the dates already there can be acted on.

Other notices: Apps, Models, Fields, Side by side, Questions, Terms, Data. Where each line comes from is set out on the sourcing page.

2A pipeline across model versions

Model end dates touch “Learn”; SceneMixer's guides describe how its pipeline treats the models it runs:

Recommended is a badge on the tier the site suggests for most finished segments. You stay on the default, 480P, until you pick another tier.
SceneMixer, Wan 3.0 · 720P: the recommended tier — “Does Recommended mean 720P is the default?” (read 2026-10-13)

The Seedance 2.0 tiers render segments up to 15 seconds; use a Seedance 2.5 or Wan tier for 30-second takes.
SceneMixer, Seedance 2.0 Fast — “Does Fast render 30-second takes?” (read 2026-10-13)