LLMSwaps

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

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.

Deprecated and withdrawn are two different eventsDeprecated usually means no new features and no guarantees, while the endpoint keeps answering. Withdrawn means it stops. Teams that schedule against the first date discover the difference when nothing breaks for months, and teams that ignore it discover the difference all at once.DeprecatedWithdrawnDoes it still answerYes, usually for monthsNoNew featuresNoneNoneSupportBest effort at mostEndedIs a date publishedSometimesRarely, and latePlan against the right one
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.