LLMSwaps

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

Model version: the part that has to be recorded

A model version is the specific release behind a family name. It is the part that has to be recorded per delivered file, because a family name cannot be matched to a dated announcement and cannot explain why output from March looks different from output in September. As of 2026-09-22.

What a family name settles, and what only a version can. Recorded 2026-09-22.
A family name gives youA version gives you as well
Who made the modelWhich release produced a given file
Roughly what capability to expectA row on a deprecations page to match
A vendor to askEvidence that output changed under you
A line to watch on a menuA pin, where the product offers one

Inclusion rule. Distinctions drawn from how the entries in this register name their models. Several name a family only. Order. What a family name gives first, then what a version adds.

1One family in this register spans four versions

Four entries here carry the same family and no two carry the same version: a third generation at three resolutions, a 2.5 line, an unversioned mention, and downloadable second-generation weights.

A production that recorded only the family would be unable to reproduce anything. That spread is the strongest argument in the register for keeping the version alongside every delivered file.

One family name covering four different releasesFour entries in this register carry the same family and no two carry the same version. A production that recorded only the family would be unable to reproduce anything, and could not match a dated row to a purchase.A dated rowNames an identifier,on the maker's ownlifecycle page.Needs a matchYour recordModel, version ifgiven, and the date,per delivered file.Which yieldsAn answerWhether the dateapplies to work youhave alreadydelivered.Deprecations pages list identifiers, not familiesOn one entry the record falls out of the billing arrangement; everywhere else it is a habit.
Fig. 1 Recording it costs one field at the time and cannot be reconstructed afterwards.

2Versions are what dated rows are written about

Deprecations pages list identifiers, not families. So a maker's published date can only be matched to a purchase if the purchase named a version, which several entries here do not do.

That is the mechanism by which a published date fails to reach the person it concerns. The date exists, the customer exists, and nothing connects them.

3Recording it costs one field

Model, version if given, and the date, per delivered file. It is trivially cheap at the time and impossible to reconstruct afterwards, which is the whole of the advice this register keeps repeating.

On one entry the record falls out of the billing arrangement, because each model is priced separately. Everywhere else it has to be a habit.

A definition rather than a dated entry: no line above is a vendor statement. Where this word turns up in a real notice, the wording and the date are on why naming the version matters. Nearby terms: Version alias, Version pinning, Model identifier.