Questions about swaps that published pages can answer
A question is answered here when an app page or a vendor notice settles it. Anything that needs an API key, a probe or an inference from output quality is out of scope. As of 2026-09-12.
Probing is the tempting shortcut and the one this register refuses. Output can suggest which engine produced it, and a suggestion is not a fact a reader can verify by opening a page. The register would also be wrong the moment a vendor changed something quietly, which is precisely the event being tracked.
The questions that survive that rule are about disclosure rather than about engineering: who names an engine, who commits to a date, what a deprecation notice actually promises, and what a team should have in place before one lands.
Answers link to the notices they rest on, and the notices carry the addresses, so a reader can check the original wording rather than this register's summary of it.
1The questions
- How much notice — Applications name no figure at all.
- Your stored work — One vendor published what it would do with stored work when a model shut down.
- Notice clauses — One pricing page says outright that the models it offers may change, and nobody anywhere publishes how much notice would come with it.
- Aggregators — Two apps resell models they did not make, which means their menus can change for reasons entirely outside their own control.
- One or many — One app names a single house model on every plan while another sells two generations at once, and both are stable in different ways.
- Naming versions — An app that prints the model and version beside the rate makes a retirement visible in advance.
- Blank dates — An empty calendar is a finding about announcements, not an assurance about schedules.
- Who names a successor — One dated row here names what follows it, and the successor is a later version of the same model.
- After the date — One platform names the exact response a retired model returns.
- Can a date move — One platform states its dates cannot be pushed back.
- Cut off early — One platform can end access after fifteen days of disuse.
- Who moves you — One platform states migration will not happen automatically.
- Published states — Three on one platform, two stages on another, and none anywhere else.
- Older generations — Three entries list an earlier generation beside the current one.
- Quiet about the last version — Three entries promote a numbered generation and say nothing about the ones it replaced.
- Per-model metering — Three entries attach a price to each named model rather than bundling them, so the invoice records which engine produced what.
- House against licensed — Almost none.
- Downloadable weights — A copy already downloaded cannot be withdrawn, so a retirement date stops applying and hardware, storage and retention start.
- Tier and model — One entry names partner models tier by tier, so the subscription decides.
- Who publishes a date — Five of the sixteen entries carry a date somebody published.
Where nothing has been published, the answer names the absence instead of estimating around it.
Other notices: Apps, Models, Fields, Side by side, Terms, Learn, Data. Where each line comes from is set out on the sourcing page.