What is a model?
A model is a frozen set of trained weights plus the tokenizer and serving configuration that turn your request into a reply. In an API it is not a product, it is a string: the name you send selects one specific build, two names from the same family behave differently on the same prompt, and nothing you send back ever changes the weights.
What you are actually selecting when you name a model
Three things arrive together under one name. The weights, which were fixed when training ended and are identical for every user of that build. The tokenizer, which decides how your text is cut into the units the weights operate on. And the serving configuration: the context limit, whether tool calling and images are supported, the maximum output length, and the price per million tokens in each direction.
The first of those has a consequence people keep rediscovering. The weights are read-only. Your conversations do not train the model, corrections do not persist, and yesterday's session leaves no trace unless your own code stored it and resends it. Everything that looks like learning in a product is state your application keeps, not a change in the model.
The second matters for cost. Tokenization is part of the model, so the same text can be a different number of tokens on two models, and a price comparison per million tokens is only meaningful alongside how many tokens your actual traffic produces on each.
Aliases move, dated IDs do not
Providers publish two kinds of name. Anthropic's model documentation describes the short form plainly: aliases are convenience pointers that resolve to a dated model ID. So the friendly name is a moving target by design, and the dated identifier is the thing that stays put.
Use the alias while you are exploring, because you want the current build without editing code. Pin the dated ID in anything you have evaluated, because otherwise the model under your production prompts can change without a deploy, and your regression will show up as a mysterious quality shift with no commit to blame. The pinned build is not eternal either: providers retire versions on a published schedule, so pinning buys you a controlled migration rather than a surprise one.
Why the same prompt gives different answers
Four causes, worth separating before you go looking for a fifth. Sampling: unless the temperature is zero the model draws from a distribution, so repetition alone produces variation. Reasoning budgets: on models that think before answering, the intermediate work differs between runs and so does what it concludes. Your own assembly: a harness that prunes history, injects retrieved passages or reorders tool definitions is sending a different prompt than you think. And the model itself changed, which is only possible if you were using an alias.
The diagnosis order follows from that list. Log the exact request body, not your template, then compare two runs. Most reports of a model getting worse turn out to be a change in the text around the prompt rather than a change in the weights.
The model is not the system
Choosing a model is one decision among several, and rarely the one that decides whether a build works. The same weights behave completely differently depending on what the harness resends, which tools are exposed, how tool errors are reported and where the stopping rules sit. Teams often upgrade the model when the honest fix is that the prompt is assembled badly, or that half the context window is spent on stale tool output.
The reverse mistake is real too. If a task needs genuine multi-step reasoning, no amount of prompt tuning gets a small model there, and time spent tuning would have been better spent measuring the two tiers against each other on your own examples.
One name selects everything below the line
POST /v1/messages
{
"model": "claude-opus-4-5-20260101", <- pinned build: fixed weights
"max_tokens": 1024,
"system": "...", <- yours, changes per request
"messages": [ ... ] <- yours, changes per request
}
fixed by the model name controlled by you
--------------------------- ---------------------------
weights system prompt
tokenizer conversation history
context window limit tools exposed
max output length temperature, budgets
price per million tokens how much you resend
"claude-opus-4-5" (alias) -> resolves to a dated ID, and can
resolve to a NEWER one over timeThe left column is why you pin the dated ID. The right column is why most behaviour changes you notice are not the model.
Common questions
Model: frequently asked
Does the model remember my previous requests?
No. The weights are frozen and the call keeps nothing. Anything that looks like memory is your code storing history and sending it again inside the next request, which is also why long conversations cost more per turn than short ones.
Should I use the alias or the dated model ID?
Alias in development, dated ID in production. The alias is documented as a pointer that resolves to a dated build, so it can move under you; that is convenient while exploring and unacceptable once you have evaluation results tied to a specific build.
Is a bigger or newer model always better?
Better on aggregate benchmarks, not necessarily on your task, and never on latency or price. Classification, extraction and routing often run just as well on a small model at a fraction of the cost. The only ranking that matters is the one you produce from your own examples.
Does pinning a version make behaviour fully deterministic?
No. Pinning fixes the weights; sampling, reasoning budgets and whatever your harness assembles into the request are still sources of variation. Determinism, to the extent it exists, comes from controlling those as well, and it is safer to design for variation than to assume it away.
Sources
Where these facts come from
- Anthropic docs: models overview: states that aliases are convenience pointers resolving to a dated model ID
- OpenAI docs: models: per model context limits, capabilities and versioned identifiers
- Anthropic docs: Messages API: the request shape in which the model name is one field among many