The Catalog Moves: Living With Model Versions and Deprecations

The mental model most teams import from cloud services — pick a thing, it stays picked — does not survive contact with the model market. New versions arrive on the order of weeks, not years. Prices move. Providers retire old ids on schedules measured in months. A model that was the obvious choice at integration time may be two generations back by the first anniversary, and the integration that felt permanent in the sprint is, in fact, a subscription to a moving catalog.

None of this is a reason for despair; it is the price of operating inside the fastest-improving technology market anyone has run in. But it does mean the lifecycle question — what happens when the pinned model changes, reprices, or disappears — belongs in the design doc, not the incident retro.

The same was said about prices in how to read a price list: a comparison without an as-of date is a rumour. Versions are the same discipline applied to capability.

Pinning means the code names an exact version, and nothing changes until you change it. Reproducibility — the same prompt, the same behaviour, next quarter — plus the full weight of maintenance: watching deprecation notices, evaluating successors, scheduling migrations. Pinning is the right default for anything customer-facing, anything evaluated, anything regulated.

Floating means naming a family — an alias the provider points at the current generation — inheriting improvements and behaviour changes alike, unannounced. Convenient for internal tools and prototypes; a quiet liability everywhere else. The day the alias moves, prompts meet a model they were never tested against, and “the AI got weird this week” is a genuinely hard bug to trace.

The mistake is the accidental float: pinning nothing, recording nothing, and discovering the exposure during an incident. Whichever policy, choose it in writing, per workload — “which model served this answer” should be answerable from your own logs, and the routing post’s advice stands: if reproducibility is contractual, pin and log.

Every provider gets evaluated on this eventually, so the checklist before it is needed. Notice period: how far in advance a retirement is announced, and whether the notice reaches engineers or just a billing contact. Overlap: do old and new versions run side by side long enough to evaluate and migrate, or is the switch a cliff? Clarity: is there a changelog to subscribe to, or do versions change silently?

Price movement deserves the same scrutiny as retirement. A model whose price changes underneath you is a quieter failure than a retired id, but the invoice notices either way — the dated-snapshot habit from the price-list post applies here too.

The platform’s own bias shows in how the catalog is run: every price change lands in a dated, public history (one is shown in the GLM 5.2 post), and the model library always reflects the current state of what can actually be called.

Teams that handle deprecations smoothly share one property: a warm migration path. The model id is configuration, not code — one string, in one place, owned by someone. The eval suite from the eval-before-purchase post exists and runs against candidates in an afternoon. And a rollback is a config flip, not a redeploy.

With that in place, a deprecation notice becomes a scheduled chore: run the successor through the eval, shadow it on a slice of traffic, flip, keep the old config around for a week. Without it, the same notice is a fire drill conducted against a deadline someone else set.

The OpenAI-compatible surface matters here concretely: if swapping providers is a two-line change, as walked through in the migration post, then a deprecation inside one provider is never an existential event. Optionality is the real deprecation policy.

Teams never surprised by a deprecation share a cadence, and it is lighter than it sounds. Subscribe to the providers’ changelogs — one feed, one owner, five minutes a week. Re-run the eval on current candidates once a quarter, or whenever a successor ships, so “should we move” is never more than an afternoon away. And put the pinned versions in a document a new hire would find: which workload, which version, when chosen, what would trigger a move.

That document is the deliverable. It converts the lifecycle from folklore — one engineer’s memory of why a model id is what it is — into an asset the organisation owns. When the notice arrives, the question shifts from “what are we exposed to?” to “we know exactly what moves and when”.

The quarterly re-eval has a second payoff: it collects the dividend. Prices drift down and quality drifts up, and teams with a standing evaluation habit are the ones who actually capture that instead of reading about it.

When the model sits inside a validated system — a regulated pipeline, a certified workflow, an audit trail — change itself is the risk, and the newest version is a liability until someone re-validates it. Freeze, and budget for the re-validation cycle.

Freezing is also honest for workloads that are done. An internal tool that works, that nobody is improving, and whose failure would be annoying rather than dangerous earns stability over freshness; migrate when the calendar forces it, not before.

What freezing is not is a strategy for the product core. The catalog’s improvement is the closest thing this industry has to a dividend — quality up, prices down, year after year. A core workload frozen in place is declining that dividend on your behalf. Pin, by all means. But run the drill often enough that unpinning is always cheap.