A Version-Pinning Strategy for Production LLM Calls

Pin the dated snapshot in production, resolve it in exactly one place, and run the floating alias in staging so that the change arrives where it can only embarrass you. The interesting part of the argument is the cost of doing that, which is real.

The position

Providers publish model identifiers in two shapes. Some carry a date: Anthropic’s model status table lists identifiers such as claude-sonnet-4-5-20250929, where the suffix names one frozen set of weights. Others do not, and resolve to whatever the provider currently considers that model to be. The first kind is a pin. The second is an alias, and an alias is a promise that the thing under your production traffic may change without your involvement.

The argument for pinning is not that models get worse. It is that an alias makes a change to your system that your change-management process never sees. Every other dependency in your stack is version-controlled; a library does not upgrade itself between Tuesday and Wednesday because somebody else shipped. The model is the single largest behavioural dependency in an LLM application and, under an alias, it is the only one exempt from the process you apply to everything else. That asymmetry is the whole case, and it does not require believing that any particular update is bad.

What an alias actually buys, and what it costs

Take the alias case seriously, because it has two genuine advantages and both are worth naming. It fails soft: when the underlying snapshot retires, the alias keeps resolving to something and your service keeps answering. And it gets you improvements for free, which for many applications is exactly what you want — a summarisation feature in an internal tool that quietly gets better is a good outcome and nobody needs to run an evaluation for it.

The cost is that you lose the ability to attribute anything. When quality changes on a Tuesday and no deploy went out, you have no bisection: the axis along which the system changed is not one you control or can enumerate. The library already covers what that looks like from the inside — silent model updates and the regression that follows one — and the pattern is consistent: the investigation is expensive precisely because the change is invisible in your own history.

Three concrete things a pin buys that are easy to overlook. An evaluation baseline that means something a month later, because the thing you measured still exists. A prompt cache that is not invalidated by somebody else’s release, since cache identity is per model. And the ability to run a deliberate comparison — old snapshot against new snapshot, same prompts, same day — which is only possible while both identifiers still resolve.

Pinning converts a quality risk into an availability risk

Here is the cost of the position, stated as strongly as its opponents would state it. Under an alias, the worst case is that answers get subtly different. Under a pin, the worst case is that on retirement day every request to that identifier fails and the service returns errors rather than degraded output. Pinning does not remove risk; it moves it from a gradual, recoverable failure mode to an abrupt one, and it moves it onto a specific calendar date.

That trade is only favourable under one condition: somebody owns the date. A pin plus an owned deprecation calendar is strictly better than an alias, because the abrupt failure is scheduled months in advance and therefore never happens. A pin with nobody watching the date is strictly worse than an alias, because you have taken on the hard failure and kept none of the benefit. There is no middle position. If your organisation is not going to maintain a list of the model strings you call and when they die, the honest recommendation is the alias, and this essay is arguing for the calendar at least as much as for the pin.

Two mitigations make the hard failure survivable even when the date slips. Keep a configured fallback identifier so that a failure on the pinned model routes to a current one rather than to a 500 — degraded is better than down, and the alias camp is right about that much. And alert on the error rather than on the calendar: a spike of model-not-found responses should page someone, which is the one signal that catches a retirement your process missed. See what a model-not-found error actually means.

The cadence that makes a pin safe

Pinning is only defensible if the pin moves on a schedule, because a pin that never moves is just a slower way of arriving at the same deadline with less notice. The cadence has four parts and none of them is elaborate.

• A standing slot. A recurring block — monthly or quarterly — in which the current candidate is evaluated. Not “when we have time”, because that is never, and not “when a deprecation forces it”, because that is the worst possible moment.
• A named candidate. At any point there is a “next” identifier configured in staging. When a deprecation notice arrives, the candidate has already been through evaluation once and the work is a rollout rather than a project.
• One place the string lives. A model identifier spread across twelve services is twelve pins that will drift, and drift means your evaluation covers a configuration that production does not run. One config source, one resolver, one place to change.
• The resolved identifier in your logs. Record what the response says the model was, not only what you sent. That is what makes the inventory in the calendar page trustworthy.

Where an alias is the right answer

The position is not that aliases are wrong everywhere, and a strategy that cannot say where the other choice wins is not a strategy. Use the alias in staging, deliberately and permanently: you want the change to arrive there first, and an alias in a pre-production environment is a free early-warning system for exactly the behavioural difference a deprecation notice never describes. Use it in internal tools where a human reads every output and a subtle change costs nothing. Use it in prototypes, where being current matters more than being reproducible. Use it in batch jobs whose output is reviewed before it is acted on.

Reserve the pin for the paths where a change in output is a change in product behaviour: anything customer-facing, anything whose output is stored and later treated as fact, anything with a structured contract that downstream code parses, and anything under a compliance regime that requires you to say which model produced a given decision. That last category is not negotiable in some industries, and it is worth knowing which of your paths fall into it before the question is asked.

The summary is short. Pin where reproducibility is part of the product; alias where currency is. Resolve the string in one place either way. And accept that pinning is a commitment to a calendar — the day you stop maintaining that calendar is the day the alias would have served you better.