In OpenAI Chat Completions, what happens if you set both temperature and top_p?

## Two knobs, one sampler After the model produces a probability for every possible next token, the API applies your sampling parameters and picks one. `temperature` and `top_p` both act at that moment, in the same pipeline, which is exactly why tuning both at once is discouraged. ## What temperature does at the API level `temperature` accepts 0 to 2 and defaults to 1. Lower values sharpen the distribution so the highest-probability tokens dominate, producing focused, repetitive, more predictable text. Higher values flatten it, giving rarer tokens a real chance — more varied, and more likely to go off the rails above roughly 1.2. Values near 0 are what you want for extraction, classification and code-shaped output. ## What top_p does at the API level `top_p` accepts 0 to 1 and defaults to 1, meaning no restriction. It keeps only the smallest set of candidate tokens whose probabilities add up to `top_p` and samples from that set. At 0.1, only the tokens making up the top ten percent of probability mass are eligible. Unlike temperature it does not reshape the distribution, it truncates it. ## Setting both The API will happily take `temperature: 0.2` together with `top_p: 0.5`. Nothing warns you. The problem is interpretive: the truncation and the rescaling interact, so you can no longer attribute a behaviour change to either knob, and a value that seems conservative on one axis can be swamped by the other. OpenAI's parameter documentation says explicitly to alter this or temperature but not both. The practical convention is: leave `top_p` at its default of 1 and move `temperature`, or, if you prefer nucleus control, pin `temperature` at 1 and move `top_p`. Write the choice down in your config so nobody later helpfully tunes the other one. ## Determinism is not what temperature 0 gives you A very common wrong answer is that temperature 0 makes the API deterministic. It makes sampling effectively greedy, which removes one source of variation, but identical requests can still return different text: floating-point non-determinism, batching, load balancing across hardware, and silent model updates all contribute. The API offers `seed` for best-effort reproducibility and returns `system_fingerprint` on the response, which identifies the backend configuration; if the fingerprint changes between calls, OpenAI is telling you the setup changed and reproducibility is not promised. Treat determinism as best-effort, and assert on structure or a grader in tests, never on exact strings. ## Models that reject these parameters This is where cross-provider habits get people. OpenAI's o-series reasoning models do not support arbitrary sampling values; sending a non-default `temperature` or `top_p` produces a 400 rather than being ignored. So code that blindly sets `temperature: 0` for every model breaks the moment someone points it at a reasoning model. Make the sampling parameters part of your per-model config, not a global constant, and be ready for the request to be rejected rather than silently degraded. ## Related knobs you may be asked to distinguish `frequency_penalty` and `presence_penalty` (both roughly -2 to 2, default 0) discourage repetition; they are not substitutes for temperature. `n` asks for more than one completion in a single response and multiplies your output-token cost. `stop` gives a small list of strings that end generation, and when one fires the response comes back with `finish_reason` `"stop"`. ## What to say in an interview Name the ranges and defaults, say that setting both is legal but discouraged and cite the one-or-the-other guidance, refuse the determinism trap, and mention that reasoning models reject the parameters outright. That combination is the answer that sounds like someone who has run production traffic rather than read a quickstart.