A model alias is a name the vendor can point at a different model; a pinned snapshot is a fixed release. Calling an alias means accepting the vendor's upgrades on the vendor's schedule. Pinning a snapshot protects you from upgrades, but not from deprecation: on 8 October 2026 Google began routing API requests for gemini-3.7-flash, a stable id, to gemini-3.8-flash, and for gemini-3.5-flash to gemini-3.6-flash1. A team that pinned 3.7 Flash got a different model with no code change.
So the job has two halves: pin as precisely as each vendor allows, and detect the swap when it happens anyway. This guide covers both, vendor by vendor.
How each vendor names models
| Vendor | Moving names | Fixed names | Recent move |
|---|---|---|---|
| OpenAI | Older families: the bare name points at a default dated snapshot (gpt-4o → gpt-4o-2024-08-06); chat-latest follows ChatGPT | Dated snapshots; GPT-6 models have one id that is the only snapshot (gpt-6-luna) | chat-latest updated to the latest ChatGPT model on 7 October 2026 |
| Anthropic | For models before 4.6, the alias resolves to a dated id | Every model id, including the dateless ids from 4.6 on (claude-sonnet-5-5) | None by alias in the current lineup |
| Google (Gemini API) | -latest aliases (gemini-flash-latest), hot-swapped on new releases | Stable ids (gemini-3.8-flash); preview ids | gemini-3.7-flash routed to gemini-3.8-flash on deprecation, 8 October 2026 |
| xAI | <model> (latest stable) and <model>-latest | <model>-<date> | grok-voice-latest now points to grok-voice-3.0 |
OpenAI
OpenAI's model pages describe snapshots as a way to "lock in a specific version of the model so that performance and behavior remain consistent." On the GPT-4o page the default snapshot is gpt-4o-2024-08-06, and every GPT-4o snapshot is now deprecated or shut down2. The GPT-6 generation is simpler: the GPT-6 Luna page lists gpt-6-luna as the "default and only snapshot"3. One name that does move by design is chat-latest: on 7 October 2026 OpenAI updated it to the latest model in ChatGPT and repeated that it recommends the GPT-6 family for production API use4.
OpenAI's own API does not route a shut-down snapshot to a successor: a retired id stops answering, which is loud but honest.
Anthropic
Anthropic's models overview says every Claude model id "is a pinned snapshot, including the dateless IDs used from the 4.6 generation on". For models before the 4.6 generation, the alias "is a convenience pointer that resolves to the dated ID"5. In practice, claude-opus-5-5 will not quietly become something else; when Anthropic ships a new model it ships a new id. The page also notes that partner platforms such as Bedrock and Google Cloud set their own lifecycle dates5, so the same model can retire on different days depending on where you call it.
The Gemini models page defines four kinds of name: stable ids that "usually don't change", preview ids deprecated with at least two weeks' notice, latest aliases such as gemini-flash-latest that are hot-swapped when a new release arrives (with two weeks' email notice for breaking changes), and experimental ids that "are not stable"6.
The October change shows the limit of "stable". Google's release notes say Gemini 3.7 Flash "is deprecated and has been replaced by" gemini-3.8-flash and that requests to the old id "are automatically routed" to the new one; the same entry covers 3.5 Flash and 3.6 Flash. Neither entry gives a shutdown date or mentions price1. On Vertex AI the picture differs: Google Cloud lists Gemini 3.7 Flash with a retirement date of 28 January 2027 and gemini-3.8-flash as the replacement7. The same id therefore meant different things on two Google platforms in the same week.
xAI
xAI's convention is spelled out: <modelname> is aliased to the latest stable version, <modelname>-latest to the latest version, and <modelname>-<date> "refers directly to a specific model release" that "will not be updated"8. In October, grok-voice-latest started pointing to grok-voice-3.0, "so sessions that use the alias are upgraded automatically", at the same price as 2.0. Separately, grok-voice-transcribe-1.0 reached end of life on 2 October 2026 and its requests are sent to grok-voice-transcribe-2.09. That second case is a versioned id, not an alias, being served by a different model.
What a silent swap changes
A new model behind the same name can move four things at once, and only one of them shows up as an error.
- Quality. Different answers, a different refusal profile, a different reading of the same prompt. Structured output that parsed yesterday may not today.
- Cost. A newer model can be priced differently, think more, or write longer answers. Estimated cost per request moves even when the per-token rate does not.
- Latency. Time to first token and total time shift with model size and reasoning.
- Limits and parameters. A successor can accept different parameters or have different rate limits, so a call can start failing for reasons unrelated to the prompt.
None of these is necessarily worse. The problem is that nobody chose the change, nobody evaluated it, and the first signal is often a customer.
How to pin
- Use the most specific id the vendor offers. A dated snapshot at OpenAI for older families, the model id at Anthropic and for OpenAI's GPT-6 models, a stable id rather than
-latestat Google, a dated id at xAI. - Keep a register of pinned ids with each id's documented deprecation or retirement date, per platform. The pin ends on that date whatever you do.
- Put the id behind a name you control. A config key, a wrapper alias or a gateway route, so that moving to a new model is a reviewed change with an evaluation attached.
- Never mix aliases into evaluation baselines. An eval run against
-latestlast month is a run against a different model. - Read the release notes of every vendor you pin. Google's 8 October entry and xAI's October entries were the only advance signal for these swaps.
How to detect a swap
Log the model each response reports. Most APIs return a model identifier in the response body. Record it next to the model you requested, and alert when a requested name starts being answered by an id you have not seen for it before. Check for each provider whether the field reports the resolved version or echoes the name you sent; a field that echoes your request tells you nothing.
Watch the derived signals by model. A swap rarely moves one metric. Compare, per requested model, against the same weekday in previous weeks:
| Signal | What a swap tends to do |
|---|---|
| Model id reported in responses | A new value appears |
| Output tokens per request | Moves, often up for a reasoning-heavy successor |
| Latency p95 and time to first token | Shifts with model size and thinking |
| Refusals and content-filter errors | A new safety profile changes the rate |
| Answers cut off by the length limit | Rises if the successor writes or thinks longer |
| Estimated cost per request | Follows token counts and rates |
Re-run a small evaluation weekly. A fixed set of a few dozen representative prompts with a pass mark catches quality changes that metrics cannot see.
Catching model swaps with INFRO
INFRO is a control plane in front of the provider accounts you connect; your providers bill you directly. For traffic that goes through it, three parts help here.
The model the provider named. Every request row carries served_model, the model id your provider's reply named, beside the model you requested, and the request log filters by it.
A finding when it changes. Traffic changes raise a traffic.model_changed finding when, on one provider connection, a model starts being answered by an id the provider had not reported in the previous 14 days, carrying at least 20% of the day's successful requests and at least 50 of them. The finding compares output tokens, cache share, truncation, fallbacks and p95 latency before and after, and gives an estimated weekly change in provider cost. Other findings cover output tokens per request, latency and error-code shares on their own.
A name you control. A route lets applications call a stable name while you change the provider model behind it deliberately.
What INFRO cannot do: it reads request metadata, never prompts or answers, so it cannot tell that answers got worse; that needs an evaluation. It also detects a swap only when the provider's reply reports a new id. A provider that echoes the requested name while serving a different model leaves that signal blank, and only the derived metrics remain.