Opus

## The model field is just a string Anthropic's Messages API does not take a family and a tier as separate parameters. There is no `tier="opus"` field: the entire model selection is one required string in the `model` parameter of the request. Choosing Opus therefore means writing an Opus model identifier into that string, and Anthropic publishes two spellings of it for every Opus release. ## Dated snapshots A dated snapshot looks like `claude-opus-4-1-20250805`. Read left to right it is: the family (`claude`), the tier (`opus`), the version within that tier (`4-1`), and the release date of that specific build (`20250805`, i.e. 5 August 2025). The important property is immutability. That identifier names one frozen artefact — the same weights, the same default output style, the same tool-call formatting, the same refusal boundaries — for as long as the model is served. Nothing Anthropic ships later changes what that string returns. ## Aliases An alias drops the date: `claude-opus-4-1`. It is a pointer that Anthropic controls, and it resolves to the newest snapshot released within that line. Anthropic documents aliases as a convenience and explicitly discourages them for production traffic. Two things about aliases surprise people. First, the alias tracks *its own line*, not "the strongest Opus that exists" — when a new Opus generation ships, it gets new snapshot IDs and its own alias, and the old alias keeps pointing inside the old line. Second, an alias resolving to a new snapshot is not a version upgrade you performed; it is a change to your production system made by a third party on their release calendar rather than yours. ## Why pinning is the production default Everything you validated about a model was validated against a specific set of weights. A snapshot change inside the same tier is usually an improvement in aggregate benchmark terms and can still be a regression for you, because a real service depends on far narrower behaviour than a benchmark measures: - **Output format brittleness.** Prompts that ask for a bare JSON object, a fixed heading structure or a specific citation style often depend on habits of a particular build. A newer snapshot may add a preamble, change list punctuation, or wrap output in a fence. - **Tool-call behaviour.** How eagerly the model calls a tool, how it fills optional arguments, and how many calls it batches per turn can all shift, which changes the shape of an agent loop even when every individual call is valid. - **Refusal and safety boundaries.** A prompt that sat just inside the line on one snapshot can sit just outside it on the next, producing a sudden class of empty or hedged responses in one workflow. - **Latency and token profile.** Response length distribution changes move p95 latency and per-request cost, which matters for timeouts and capacity assumptions even when quality is fine. - **Reproducibility.** When an incident is reported three weeks later, you need to know which weights answered. If the request named an alias and the alias has since moved, you cannot reproduce it. ## The operational pattern Put the model ID in configuration, not scattered through call sites — one constant or one environment variable, so a version bump is a single reviewable change. Keep a golden-set eval you can point at a candidate snapshot and diff against the incumbent. Roll the new snapshot out behind a flag or a percentage canary, exactly as you would a dependency upgrade, and keep the previous pin available so rollback is a config revert. Finally, log the `model` field the API returns on each response alongside your own request metadata: it tells you what actually served the traffic, which is the fact you will want during an investigation. ## When an alias is genuinely the right choice Aliases earn their place in throwaway scripts, notebooks, and internal tooling where "newest in the line" is the desired semantics and nobody is paged when the output shifts. They are also reasonable in an evaluation harness whose purpose is to notice change. The rule of thumb: use an alias where a silent behaviour change is information, and a pin where it is an outage. ## Common mistakes Treating the alias as pinned because it looks like a version number is the big one — `claude-opus-4-1` reads like a version and behaves like a branch name. A second is hardcoding a snapshot in a dozen files, which turns a one-line bump into a grep-and-pray exercise. A third is assuming a mistyped or unknown model string quietly falls back to some default; it does not — the request fails, which is the behaviour you want, but it means model IDs belong in config validated at startup rather than in a string built at request time.