Pin the id, or ride the alias

If your code calls a floating alias, you have chosen to accept model changes on the provider's schedule instead of yours. Google says a Gemini "latest" alias points to the most recent release of a model variation and is hot-swapped with every new release of that variation.[Google] That is a provider documenting the behaviour in its own words, and it is the cleanest reason to pin an explicit id in anything you care about.

The alias does what it says

On 21 January 2026 Google changed the latest aliases to point to Gemini 3 models. We recorded it in the Google change log as a weight-refresh entry with a re-pin (moving your code from a floating model alias to a fixed, dated model id) action, because for anyone calling an alias there was no deploy, no code review and no diff. The configuration file said the same thing on both days and the model behind it did not.

That is the property to hold on to. An alias is not a version, it is a pointer, and the provider has told you in advance that the pointer moves.

OpenAI's aliases behave the same way by design. When OpenAI released GPT-5.1 on 13 November 2025, the action we attached was to pin the exact id you intend to serve rather than a family alias. Five days later OpenAI announced the deprecation of the chatgpt-4o-latest snapshot with a shutdown date of 17 February 2026 and gpt-5.1-chat-latest as the replacement, which is an alias-shaped id going away and being replaced with another alias-shaped id.

What a pin buys, stated narrowly

re-pin removes exactly one thing: the silent repoint. It is worth saying what it does not remove, because the overclaim here is common.

A pin does not make a model stable, reproducible or its outputs guaranteed. We do not say that anywhere on this site, including on how it works. A pin also does not last forever. Anthropic notified developers using Claude Sonnet 3.7 on 28 October 2025 that the model would retire, and it retired on 19 February 2026 with claude-sonnet-4-6 listed as the replacement. A pinned id has an end date like any other, and Anthropic describes its model lifecycle in four states, active, legacy, deprecated and retired, saying that requests to retired models will fail.[Anthropic]

So a pin converts an unscheduled change into a scheduled one. That is the whole benefit, and it is a large one, because a scheduled change can be run against a golden dataset (the fixed set of labelled inputs and expected outputs agreed at baseline, versioned so two runs can be compared) before it reaches anyone.

What the provider says about stable ids

Google's Gemini documentation says stable models usually don't change and that most production apps should use a specific stable model.[Google] Keep the hedge. Google wrote "usually don't change", and upgrading that to "never change" is the sort of small edit that turns a source into a claim we would have to defend.

Preview ids sit at the other end. Google launched gemini-3-flash-preview on 17 December 2025, and our note on that entry was to add it to a comparison run while keeping the preview id out of production pins. The reason is the notice period behind it: Google says Gemini preview models may be used in production but will be deprecated with at least 2 weeks[src] notice.[Google] Two weeks is enough to migrate. It is not enough to discover the problem, agree a fix and ship it, if nothing is watching.

The change you are not told about at all

Pinning handles announced changes. There is a claim in circulation about unannounced ones, and it is worth naming precisely who makes it. Future AGI writes that OpenAI, Anthropic, Google and most frontier providers update model weights without a major version bump.[Future AGI] That is a vendor's characterisation of the market, not a provider statement, and we never restate it as one.

The provider-own evidence we do have is Google's alias sentence above. It is narrower and it is enough. Both together are why our rerun protocol includes a weekly scheduled run that goes ahead whether or not anything was announced, and why production sampling scores live traffic rather than only the dataset. A change with no announcement has no trigger to react to, so the only things that reach it are a clock and a sample.

How to decide, per feature

Do this per feature, not per company. The question is how expensive a surprise is on that surface.

For a feature with a contract behind it, an approval step, or a regulator in the room, pin an explicit dated id, record it where your team can see it, and treat any change to that line as a release. For an internal summariser where a bad day costs somebody five minutes, an alias is a reasonable way to avoid maintenance, as long as somebody wrote down that it was a choice.

Then, whichever you picked, put a baseline behind it. A repoint you can measure is an incident that lasts an afternoon. A repoint you cannot measure is a month of support tickets with no cause attached. The eval baseline is where that first run gets made, the plans page says how often it gets repeated, and the change log is where we record the repoints themselves with the provider's own source on each one.