Sampling parameters

Overview

None of these are required. Omitting a field entirely means the model uses its own default for that setting, which is the right choice for most requests; reach for these when a specific request genuinely needs more determinism, more variety, or a hard stop condition. Every value here is validated on the way in: a value of the wrong type, or a number outside the accepted range, is silently ignored for that one field rather than failing the whole request, so a malformed sampling parameter never turns a working request into a broken one. If a request behaves as though a parameter you sent had no effect, checking that it's within the accepted range below is the first thing to verify.

Field	Type	Range	Effect
temperature	number	0–2	Higher values make output more varied and less predictable; lower values make it more focused and deterministic. 0 is close to always picking the most likely next token.
top_p	number	0–1	Nucleus sampling: restricts choices to the smallest set of tokens whose combined probability reaches this value. An alternative lever to temperature for controlling variety; most requests should set one or the other, not both.
presence_penalty	number	-2–2	Positive values reduce the odds of a token that has already appeared anywhere in the response so far, encouraging the model to bring up new topics rather than dwell on ones already mentioned.
frequency_penalty	number	-2–2	Positive values reduce the odds of a token in proportion to how many times it's already appeared, discouraging repetition of the same words and phrases.
seed	integer	any integer	Requesting the same seed with an otherwise-identical request makes output more reproducible run to run. Not a strict guarantee of byte-for-byte identical output every time, but meaningfully reduces variation for testing and debugging.
stop	string or array of strings	up to a few short sequences	Generation halts the moment any of these sequences would appear in the output. The sequence itself is not included in the returned text.

Example

{
  "model": "tai-4.1",
  "messages": [{"role": "user", "content": "Bir ürün açıklaması yaz"}],
  "temperature": 0.3,
  "presence_penalty": 0.4,
  "stop": ["###"]
}

When to reach for which one

For anything where consistency matters more than variety, extraction, classification, structured output, code, keeping temperature low (0 to around 0.3) is usually the right move. For open-ended writing, brainstorming, or anything where you'd rather see a range of plausible outputs across repeated calls, a higher temperature (0.7 to 1.0 or beyond) tends to produce more interesting variety. presence_penalty and frequency_penalty are worth reaching for specifically when a model is producing repetitive text, looping on the same phrase, or restating the same point; they're less useful as a general-purpose default than temperature. seed is primarily useful during development and testing, where reproducing the same output across runs makes debugging a prompt change much easier than chasing down whether a difference in output came from your change or from ordinary sampling variance.

Not currently supported

A few sampling-adjacent fields that exist in OpenAI's own API are not currently accepted: n (multiple candidate completions per request; tAI always returns exactly one), logprobs / top_logprobs, and response_format (structured JSON-mode output). Sending any of these has no effect; they're neither validated nor applied. See the OpenAI SDK compatibility page for the complete list of what is and isn't supported if you're porting an existing integration.