How it works
The explanation, with examples you can run.
Temperature
Temperature divides the scores before the softmax. Below 1 it exaggerates the gaps, so the top token wins more often; above 1 it shrinks them, so less likely tokens get a real chance. As temperature approaches 0, sampling becomes greedy decoding: always take the single most likely token.
Top-p and top-k
Top-k keeps the k most likely tokens and discards the rest. Top-p (nucleus sampling, from Holtzman et al.) keeps the smallest set of tokens whose probabilities add up to p. Both exist to cut off the long tail of unlikely tokens that produce nonsense when sampled; top-p adapts to how confident the model is at each step. A common recommendation is to adjust temperature or top-p, not both at once.
Run this to see both on a made-up distribution for the word after "The capital of France is". The random generator is seeded so the counts are repeatable.
Press Run to see what your code prints, in order.
Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.
Choosing settings
- One right answer (classification, extraction, routing, code that must compile): low temperature, or the provider's recommended default, plus structured output.
- Many good answers (brainstorming, varied copy, test data): higher temperature, and generate several candidates if you then pick the best.
- Defaults are reasonable. Many teams never touch these knobs and get good results by improving the prompt instead.
At the time of writing, some providers have stopped accepting custom temperature or top-p values on their newest models, especially those that reason before answering. Check the API reference for the model you use instead of assuming every knob exists.
Determinism is a property you build, not a setting
Even at temperature 0, providers say results will not be fully deterministic: requests are batched with others on shared hardware, and floating-point arithmetic is not associative, so near-ties between tokens can resolve differently. One flipped token early on changes everything after it.
If you need repeatable behaviour:
- Store the output the first time and reuse it (cache by a hash of model, prompt and settings) when the same input must give the same answer.
- Constrain the output (fixed labels, a JSON schema) so variation cannot change the meaning.
- Write tests and evaluations that check properties ("contains the order id", "label is one of five", "grader score at least 4") rather than exact strings, and run them several times.
- Pin the model version where the provider allows it, and re-run your evaluations before switching.
Check yourself
3 questions. Get them all right to finish this topic.
0 of 3 right so far. Get all three to finish this topic.