What pinning a version actually buys
A pinned version fixes which weights answer the call. It does not fix the serving stack around them, it does not stop the pin from being retired, and it does nothing at all where the product never named a version to pin. As of 2026-09-12.
| Pinned | Not pinned |
|---|---|
| Which weights answer | Rate limits and presets |
| The model behind the tier | Safety filters around the call |
| Version identifier | How long the version stays available |
Inclusion rule. Properties a version identifier does and does not cover. Order. Paired, pinned first.
1What a pin fixes
Where a service exposes explicit version identifiers, requesting one means the same weights answer today and next month. That is a real guarantee and it is the thing that keeps a look stable across a long production.
It also makes problems diagnosable. When output changes and the version did not, the cause is somewhere else, which is a far better position than wondering which of two things moved.
2What a pin does not fix
Defaults around the call — safety filters, prompt handling, resolution presets, rate limits — usually live outside the version identifier and can change without it. So can the serving infrastructure, which affects latency and occasionally output.
A pin is therefore a guarantee about the model rather than about the result. Output can still move under a pinned version, and when it does the version number is the thing that rules out the largest cause.
3Pins expire
Every pinned version is eventually retired. Pinning buys a known amount of time rather than permanence, and the useful question is how much notice the vendor gives and whether that notice is published somewhere readable.
Treating a pin as permanent is how a production discovers a retirement on the day it takes effect. Treating it as a lease with an unknown end date is closer to right.
4Most consumer products have nothing to pin
An application that presents house tier names rather than model identifiers gives its users no pin at all. The model underneath can be replaced between one session and the next, and the interface will look identical.
This is the common case. It is not a criticism of those products — abstracting the model is often the point — but it does mean version stability is not available there at any price.
5Naming the model is the minimum
Before pinning is even a question, the product has to say what it runs. A named model and version is what lets a user notice a change at all, compare a rate against anything, or read a vendor's own release notes.
Where a product names nothing, a swap is invisible except as output that suddenly looks different, and there is no document anywhere that will explain it.
6Write down what you were running
Whether or not a pin is available, record the model, the version if given, and the date, per delivered piece of work. This is what makes a later difference explainable rather than mysterious.
It costs one field. Without it, a change six months from now is indistinguishable from a change in the prompt, the references or the person operating the tool.
7Plan for the version you will be forced onto
Where a retirement date is published, the useful work is testing the successor before the date rather than after. A production that has already run its prompts against the next version is not disrupted when the old one stops answering.
Where no date is published, the same test is worth doing on whatever schedule the work allows, because the alternative is testing under time pressure.
8A pin is not a licence, and not a guarantee of availability
Pinning says which weights answer; it says nothing about whether the terms around them changed, whether a region still serves them, or whether the price moved. Those are separate announcements on separate pages.
Productions that treat a pin as a contract are usually surprised by one of the three. Reading the pricing page and the terms on the same day as the pin is checked costs nothing and removes the surprise.
9Pinning at the wrong layer
Where work passes through an application that itself calls a model, pinning at the application layer and pinning at the model layer are different things. An application can keep its own version number stable while replacing what it calls underneath.
The layer that matters is the one whose output you deliver. Ask what the application pins, not what its own release notes are numbered.
10Where the dates come from
The calendar here records announced dates and the notices they were announced in. It does not predict retirements and it does not infer one from a product going quiet.
An entry with no announced date says so. That is a fact about what the vendor has published, and it is usually the more useful thing to know.
11Where 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.
- The change calendar — dated entries, each linked to the notice it came from
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: After a swap, Surviving a retirement.