LLMSwaps

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

Finding the model strings you already send

A retirement schedule is only actionable if somebody can say which of their own systems uses the retiring version. Most teams send a string written months ago and never revisited, which makes the schedule a list of unfamiliar names rather than a plan. As of 2026-09-12.

What has been announced, entry by entryFilled where the vendor has announced something in that column, hollow where it has not.What has been announced, entry by entryWhy it hides thereScripts and pipeline configurati…Scripts and pipeline configurationScripts and pipeline configuration — Why it hides there: Written once, during setup, by somebody who leftSaved presets inside a productSaved presets inside a product — Why it hides there: Chosen in a hurry and never reopenedA tier or plan selectionA tier or plan selection — Why it hides there: No string at all, so nothing to grep forA convenience aliasA convenience alias — Why it hides there: Deliberately not a version, and it movesA third tool in the chainA third tool in the chain — Why it hides there: It calls a model and does not say which
Fig. 1 Filled where the vendor has announced something in that column, hollow where it has not.
Where a forgotten model name tends to live. Recorded 2026-09-12.
Where to lookWhy it hides there
Scripts and pipeline configurationWritten once, during setup, by somebody who left
Saved presets inside a productChosen in a hurry and never reopened
A tier or plan selectionNo string at all, so nothing to grep for
A convenience aliasDeliberately not a version, and it moves
A third tool in the chainIt calls a model and does not say which

Inclusion rule. Places a model name ends up in a production pipeline, with the reason each one is easy to miss. Order. From the easiest place to search to the hardest.

1An old string is the real default

Where a platform lets a caller name a version, the platform chooses nothing and almost every caller has a string it uses without thinking. That is a default in every practical sense and it belongs to the customer.

It is better than an unnamed tier, because nothing changes underneath without an edit. It is also a liability nobody is reminded to audit.

Where a forgotten model name ends upA retirement schedule is only actionable if somebody can say which of their systems uses the retiring version. Most teams send a string written months ago during setup and never revisited.From easiest to hardest to findScripts and configurationWritten once during setup. Greppable, and the easiest win.Saved presetsChosen in a hurry inside a product, and never reopened since.A tier or planNo string at all, so nothing to search for and nothing to match.A tool further down thechainIt calls a model and does not say which. The audit stops here.Run the audit while the model still answers; afterwards it is incident response
Fig. 2 Some layers cannot be audited at all: an application holds the string and often does not publish it.

2An alias is worse than an old string

A convenience name resolves to whatever the vendor currently points it at, and its whole purpose is to change. It appears on no deprecations table, so there is nothing to watch and nothing to match.

For exploration that is convenient. For a run of episodes it is the invisible version of exactly the event a retirement schedule exists to warn about.

3Some layers cannot be audited at all

Where a production reaches a model through an application, the version string belongs to the application and is often not published. The audit then stops at a tier name, which cannot be matched to any dated row.

What is left is the record kept per delivered file, plus two dated readings of the application's own page. That is weaker and it is what most of this market offers.

4Do it while the model still answers

An audit run after a retirement is an incident response. Run before one, it is an afternoon: list the strings, note where each is sent from, and check each against whatever lifecycle page the vendor publishes.

The output is a short list somebody can act on, which is the point. Most teams have never produced it and would find something surprising on the first pass.

5Where 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.

  • Model identifier — why schedules are written about strings rather than products
  • Version alias — a name that moves on purpose, and appears on no table

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: Finishing a season, Telling people downstream.