Claude accepts temperature from 0.0 to 1.0 inclusive, and defaults to 1.0. Both halves of that sentence catch people out: the ceiling is half what several other APIs allow, and the default is at the top of the range rather than in the middle.
The documented range and default
temperature number, optional
0.0 ≤ temperature ≤ 1.0
default: 1.0
Sending 1.5 does not clamp silently. It is a validation failure, and the request is rejected with a 400 before anything is generated:
{
"type": "error",
"error": {
"type": "invalid_request_error",
"message": "temperature: Input should be less than or equal to 1"
}
}
The default being 1.0 rather than 0 is the more consequential fact. If you have never set temperature in your integration, you have been sampling at the top of the range this whole time. For a classification or extraction task, that is very likely not what you want, and it is the first thing to change when identical inputs are producing inconsistent outputs.
Range and default as documented in Anthropic’s Messages API reference at the time of writing. Defaults are versioned per model in principle; check the reference for the model id you are calling rather than assuming it is family-wide.
What the number does to the distribution
The model produces a score — a logit — for every token in its vocabulary. Temperature divides those scores before they are turned into probabilities by the softmax. Dividing by a number below 1 magnifies the differences between them, so the leading candidate takes an even larger share of the probability mass. Dividing by 1 leaves the distribution exactly as the model produced it.
p(token) ∝ exp(logit / temperature)
temperature → 0 the largest logit takes essentially all the mass
temperature = 0.2 sharply peaked; the top candidate almost always wins
temperature = 1.0 the model's own distribution, unmodified
temperature > 1.0 flatter than the model's own distribution
(not available on Claude)
The exponential is the reason the parameter does not behave linearly. Halving the temperature does not halve anything the reader would notice; it squares the ratio between any two probabilities. A token the model scored twice as likely as another at temperature 1 is four times as likely at 0.5 and sixteen times as likely at 0.25. That is why the useful range is compressed toward the bottom — most of the behavioural difference you care about lives between 0 and 0.4, and the span from 0.7 to 1.0 changes less than its width suggests.
Two things follow that are often stated backwards. Temperature does not make the model more or less capable; it changes only how the sampler draws from scores the model already produced. And it does not “add creativity” — it declines to discard the alternatives the model already considered plausible. If the model was confident, a high temperature changes little; if it was genuinely torn between three continuations, a high temperature is what lets the second and third through.
Why the ceiling is 1.0
Temperature 1.0 is the model’s own distribution. Everything above 1.0 is flatter than what the model believes — deliberately promoting tokens it scored lower. There is a use for that in creative sampling research, and it is a reliable route to incoherence, because the tail of a vocabulary distribution is very long and mostly nonsense.
Anthropic’s ceiling means the flattest sampling available to you is the model’s honest opinion. If you want more variation than that, the levers are top_p, which truncates the distribution rather than reshaping it, and the prompt itself — asking for three different approaches in one response produces more genuine variety than any sampler setting, and costs one request instead of three.
Anthropic’s guidance is to adjust temperature or top_p, not both. They interact in ways that make the combined effect hard to reason about, and a low temperature with a low top_p in particular can be far more restrictive than either setting suggests on its own.
The reason the two are hard to combine is that they act at different stages. Temperature reshapes the whole distribution; nucleus sampling then discards the tail of whatever distribution it is given, keeping only the smallest set of tokens whose probabilities sum to top_p. Lower the temperature and you have already concentrated the mass in the leading tokens, so a top_p of 0.9 now admits two candidates where it would have admitted twenty. The settings do not add; the first one changes what the second one is measuring.
One mode where the value is fixed
Extended thinking constrains this. When thinking is enabled, Claude requires temperature to be 1 — other values are rejected rather than ignored, so a service that sets temperature: 0 globally will start failing the moment somebody turns thinking on. If you are enabling it, the temperature line has to become conditional. The budget parameter and its own constraints are on the extended thinking budget page.
Porting a value from another API
The OpenAI Chat Completions API documents temperature from 0 to 2, and Google’s Gemini API also allows values above 1 on current models. A configuration file that travels between providers therefore carries a number whose meaning changes on arrival:
0.7 on a 0–2 scale = 35% of the way up that range
0.7 on a 0–1 scale = 70% of the way up this one
Same string. Different setting.
The mapping is not a simple halving, because the parameter is a divisor in an exponent and not a linear dial — 0.35 on Claude is a considerably sharper distribution than 0.7 on OpenAI, not the “same position” in any behavioural sense. There is no correct conversion, only a starting point. Treat a ported value as unset: choose from intent instead.
- 0.0 — extraction, classification, routing, anything whose output is parsed by code. Take the most likely token, always.
- 0.2 to 0.4 — factual answering and summarisation, where you want stability but not identical phrasing across a batch.
- 0.7 to 1.0 — drafting, ideation, anything where two identical outputs would be a fault rather than a feature.
Values above 2 in other APIs are similarly rejected there; the ranges differ but the validation behaviour does not. Nobody clamps.
There is a related trap in configuration layers that carry a provider-neutral settings object. A field called creativity: 0.8 normalised to each provider’s range is a reasonable abstraction and a bad default, because the same normalised value produces materially different sampling behaviour on each side and nothing in the system reports that. If you maintain such a layer, keep the raw per-provider value visible in logs alongside the normalised one, so an output-quality difference between two providers can be attributed rather than argued about.
Temperature 0 is not determinism
Setting temperature to 0 makes the sampler pick the highest scoring token every time. It does not guarantee that the scores are identical between two runs, and on hosted infrastructure they often are not.
Floating-point addition is not associative, so the order in which a GPU reduces a sum changes the last bits of the result. Which order it uses depends on the batch your request landed in, which depends on other people’s traffic. On a mixture-of-experts model, the routing of a token to experts can be affected by batch composition too. When two near-tied tokens are separated by less than that noise, the argmax flips, and one different token early in a generation takes the rest of the output somewhere else entirely.
Anthropic does not document a seed parameter for the Messages API, so there is no reproducibility control of the kind OpenAI exposes with seed — and even where a seed exists, providers describe it as best-effort rather than a guarantee. The practical consequence: write tests that assert on properties of the output — it parses, it contains the required field, the classification is one of five values — and never on exact strings. Temperature 0 buys you a large reduction in variance and not an equality assertion.
Top comments (0)