Planning for the model you use to be switched off
A retirement announcement gives you months at best. What determines whether that is enough is work done long before: knowing which model made which file, keeping the outputs rather than the ability to regenerate them, and never depending on a version nobody names. As of 2026-09-12.
| With a date | Without one |
|---|---|
| Migrate deliberately, before the deadline | Discover the change when output shifts |
| Schedule the test against the successor | Test under time pressure |
| Tell clients in advance | Explain afterwards |
Inclusion rule. What changes for a production depending on whether an end date is announced. Order. Paired, with a date first.
1The asymmetry that makes this urgent
A vendor retires a model on their schedule and you find out when they publish. In the one retirement with announced dates that this register has watched, the consumer surface closed about five months before the developer one. That is a comfortable runway for a single project and a short one for a series in production.
Everything else in this field is running on no announced schedule at all. That is not a promise of stability; it is an absence of information.
2Know which model made which file
This is the whole foundation and it is trivially cheap at the time and impossible afterwards. For every clip you keep, record the model and version that produced it, alongside the date.
When a retirement is announced, the question that arrives immediately is how much of the delivered work is affected. With that column it is a filter. Without it, somebody watches hours of footage trying to guess.
3Keep outputs, not the ability to regenerate
The instinct is to preserve prompts and settings so anything can be remade. That instinct is wrong here, because the thing that will not exist later is the model, and a prompt without its model reproduces nothing.
Archive the delivered files, at the highest quality you hold, somewhere that is not the vendor's account. Material stored only inside a product is subject to whatever that product does at retirement, and in the one documented case the answer was deletion after a final download window.
4Prefer a named version over an unnamed tier
A service selling fast and pro tiers without naming the model behind them cannot be matched against any announcement. When a maker retires something, you have no way to tell whether your tier was affected until the output changes.
Among the apps tracked here, SceneMixer is the one that prints the model and version next to each per-second rate, which makes the connection between an announcement and a bill checkable rather than inferred. LTX Studio publishes a clause reserving the right to change models, which is a different kind of usefulness: it tells you the right exists. Neither publishes a notice period, and neither does any other application here; the hosting platforms in this register do.
5Aggregators multiply the schedules you are exposed to
An app carrying models from six makers has six retirement calendars and controls none of them. That is not worse than a single-model app, it is differently shaped: when one model goes, five remain, whereas a single-model app has nothing to fall back to.
The planning consequence is that an aggregator needs the per-file model record even more, because the same account can produce work under several makers' schedules in the same week.
6What a migration actually costs
Not the rate difference. The cost is that a series generated on one model and continued on another looks like two shows: faces sit differently, the grade shifts, the motion has a different character. Audiences notice without being able to say why.
So a mid-series migration is usually a choice between finishing on the old model before it goes, or regenerating earlier episodes to match the new one. Both are expensive and the first is only available if you knew the date in time.
7Version pinning, where it is offered
Some services let a caller name an exact model version rather than an alias that moves. Where that exists, use it for anything in production: an alias silently upgrading mid-series is the cheapest way to get two shows out of one.
Where it does not exist, the substitute is a record of what was in force when each file was made, plus a habit of re-checking sample output after any vendor announcement. That is weaker and it is what most of this market currently offers.
8A short checklist to run once
Is the model named on the page you pay from. Do your records say which model made each delivered file. Are the delivered files archived outside the vendor. Is there anything in production that could not be finished if the model disappeared in ninety days.
Four questions, one afternoon. The last one is the one that changes decisions, and most teams have never asked it.
9Where 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.
- SceneMixer — prints the model name and version beside each per-second rate, so a retirement is visible in advance
- LTX Studio — publishes a clause reserving the right to change the models it offers
- invideo AI — aggregates several makers, and so carries several schedules it does not control
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: Deprecation words, Reading a lifecycle page.