If you still begin every generation configuration with temperature = 0 to "guarantee determinism," it is time to revisit that recipe. In 2026, temperature, top_p, and top_k no longer form a universal control panel that works the same way in every API. In some models, they remain available. In others, they are accepted only in specific combinations. In newer Claude and Gemini models, non-default values have been deprecated or removed from the recommended path.
The most important change is this: the presence of a field in an API's general reference does not guarantee that the field is accepted by the model you chose. Today, the relevant contract is the combination of provider, model, endpoint, and reasoning mode. The official documentation consulted on August 29, 2026 makes this pattern clear.
The short answer: sampling is no longer the main control
Temperature remains a valid concept: it changes the distribution used to choose the next token and, in interfaces that still expose the parameter, lower values tend to concentrate generation on higher-probability options. Top_p applies nucleus sampling, limiting the choice to the set of tokens whose cumulative probability mass reaches the configured value. Top_k limits the choice to the K most probable tokens when the model and API provide that mechanism.
The problem is not with the concepts. The problem is treating them as a portable control layer across models. OpenAI still exposes temperature and top_p in the general Responses API reference, but its own documentation shows restrictions by model and reasoning effort. Anthropic has begun rejecting non-default values for these parameters in newer Claude models. Google instructs users to remove temperature, top_p, and top_k when migrating to the latest Gemini 3.x models.
In practice, the controls that became more important in 2026 are reasoning effort, effort, thinking level, formatting instructions, structured outputs, output limits, tool selection, and regression tests. They are not mathematical substitutes for temperature, but they are the controls providers now offer to govern behavior, depth, cost, format, and consistency.
OpenAI: temperature and top_p exist, but compatibility is model-specific
The general Responses API reference still documents temperature from 0 to 2 and top_p from 0 to 1. OpenAI still recommends changing one or the other, not both at the same time, when the model actually supports those fields. Top_k, by contrast, does not appear as a sampling parameter in the standard Responses or Chat Completions interface.
The decisive point is model compatibility. In the GPT-5.2 guide, OpenAI states that temperature, top_p, and logprobs are supported only when reasoning effort is set to none. The same guide says that requests using those fields at other reasoning effort levels produce an error, and it also records incompatibilities in earlier models from the GPT-5 family.
That makes the rule "the API has temperature, so my model accepts temperature" dangerous. The general schema describes API possibilities; the model page and migration guide tell you what that specific combination supports.
GPT-4.1: the classic scenario still exists
GPT-4.1 is still listed as a model without a reasoning stage and supports Responses and Chat Completions. In this type of model, temperature and top_p remain aligned with the classic usage described by the API. For applications that specifically need a non-reasoning model with traditional sampling control, this is the kind of combination where the old recipe still makes sense. Top_k is not part of OpenAI's standard parameter set.
GPT-5.2: temperature and top_p are conditional on reasoning
In GPT-5.2, the official rule is explicit: temperature and top_p are available only when reasoning effort is set to none. If you increase reasoning effort and keep those fields, the request may fail instead of simply becoming "less creative." This difference matters operationally because it turns what once looked like a continuous adjustment into a compatibility constraint.
GPT-5.6: behavior control has shifted to other axes
The GPT-5.6 family is OpenAI's current line in August 2026. The usage guide highlights reasoning.effort with levels from none to max, reasoning.mode for pro mode, and text.verbosity to control the level of detail. The migration guidance also emphasizes testing configurations on representative tasks instead of assuming that more reasoning always improves the result.
At the same time, the general Responses API reference still contains temperature and top_p. Because the current documentation separates the general schema from model-specific compatibility, the safe procedure is not to carry an old configuration forward by inertia. Check the model page, endpoint, and reasoning effort used by your application, and make a validation call before treating the parameter as part of the production contract.
Claude: on newer models, omit temperature, top_p, and top_k
Anthropic's change is more direct. The current Messages API reference marks temperature, top_p, and top_k as deprecated. For models released after Claude Opus 4.6, the documentation says these controls are no longer adjustable in the traditional way.
For backward compatibility, temperature at the default value of 1.0 may be accepted on some paths, and top_p at a value close to the default may also pass. That does not mean you still have a useful randomness control. In Claude Sonnet 5, the migration documentation is clearer: setting temperature, top_p, or top_k to non-default values returns a 400 error. The recommendation is to remove these fields from the payload.
The same shift appears in current Claude usage documentation: on models with adaptive thinking, effort is the recommended control for adjusting how much work the model devotes to the response. In Claude Sonnet 5, effort high is the default; medium and low reduce spend and depth, while xhigh and max reserve more capacity for difficult tasks. In Claude Opus 5, Anthropic likewise treats effort as the main control.
This changes what "I want less variation" means. Reducing effort is not equivalent to lowering temperature. Effort changes the total work devoted to the response, including thinking and, in some workflows, tool calls. For consistency of form and content, Anthropic recommends combining more explicit prompting with structured outputs when the response must conform to a schema.
Gemini: 3.x abandons the classic knobs, while 2.5 still coexists with the old model
Google made a visible transition in 2026. Gemini API release notes recorded the deprecation of temperature, top_p, and top_k on July 21. The Gemini 3.7 Flash guide, current in August, instructs users to remove all three parameters from the generation configuration. The same guide notes that Gemini 3.6 Flash already did not support them.
The central behavioral replacement in the 3.x line is thinking_level. In Gemini 3.7 Flash, the available levels are low, medium, and high, with medium as the default in the current documentation. Like effort in Claude and reasoning.effort in OpenAI, this control governs the relative amount of reasoning, not token-by-token randomness.
There is an important nuance for legacy code. Gemini 2.5 Pro and Gemini 2.5 Flash remain active, with no shutdown date announced on the deprecations page that was consulted. The general generation reference still describes temperature, topP, topK, and seed for models that support those fields. As a result, a payload that works in Gemini 2.5 may need to drop parameters when it is migrated to Gemini 3.6 or 3.7.
This coexistence explains why older examples found in searches can still look correct. They may be correct for another model generation or for a legacy endpoint, but wrong for the current 3.x line. When migrating, follow the target model page and migration guide, not just a generic SDK example.
What "accepted," "restricted," and "deprecated" mean in practice
Accepted means the model documents the parameter as a normal part of the request and changing its value is an expected operation. Restricted means the field exists but works only in certain combinations, such as temperature and top_p in GPT-5.2 with reasoning effort set to none. Deprecated means the provider wants you to stop depending on the parameter; in Claude Sonnet 5, non-default values produce an error, and in current Gemini 3.x models the guidance is to remove the fields.
There is also a fourth state that often confuses integrations: accepted only for compatibility. A default value may be tolerated so older payloads do not break, but without providing meaningful control. When that happens, leaving the field in the JSON is worse than removing it because it creates the impression that your application is governing a behavior the model already controls internally.
How to control variability now
The first change is to separate three problems that used to be attributed to temperature: reasoning depth, response format, and semantic diversity. They are different problems and require different controls.
Pin the model, version, and API path
If you measure consistency, record the exact model ID and endpoint. When the provider offers a snapshot or fixed version, use it in the test. OpenAI documents snapshots as a way to keep a specific model version. Anthropic says that Claude IDs from generation 4.6 onward identify fixed versions for the lifetime of that ID. Avoid comparing a run from today with another run weeks later using an alias that may point to updated behavior without recording the change.
Use reasoning or thinking controls for what they actually do In OpenAI, reasoning.effort changes reasoning depth in models that support the mechanism. In
Claude, effort is the recommended signal for adjusting total work and thinking depth in current models. In Gemini 3.x, thinking_level controls the relative intensity of reasoning.
These parameters are more useful for deciding cost, latency, and capability than for producing "the same sentence every time." If the task is simple classification, reducing effort may eliminate unnecessary paths. If the task is complex analysis, reducing it too much may increase errors. The choice should come from evaluation, not from an imagined equivalence with temperature.
Lock the output structure
If your problem is "every response comes back in a different format," structured outputs is usually a stronger control than sampling. OpenAI, Claude, and Gemini provide current mechanisms for constraining output to a schema. This does not guarantee that the semantic content will be identical, but it reduces variation in keys, types, logical order, and data format.
For extraction, classification, and system integration, this change is especially important. Instead of trying to get stable JSON only by lowering temperature, declare the schema and validate the result.
Specify criteria, not just style
Consistent prompts describe what must remain invariant. Define scope, format, required fields, stopping conditions, how to handle missing information, and which decisions are allowed. If the model must choose among categories, provide the categories. If it must return a conclusion and two pieces of evidence, say so. If it should avoid inferences, define how missing information should be represented.
A prompt with testable criteria reduces freedom where it gets in the way without trying to eliminate all model flexibility.
Control tools and context
In agents, much of the variation does not come from sampling. It comes from different search results, tool order, changed data, conversation history, cache, parallel calls, and intermediate decisions. If you compare two configurations, keep tools, context, and input data constant or record the differences.
This also explains why temperature = 0 was never a complete guarantee of reproducibility. Anthropic itself notes that temperature 0 does not make the result fully deterministic in models where the parameter still existed. In systems with tools and reasoning, there are even more sources of variation beyond local token selection.
Use seed only when the model and endpoint actually provide it
Google's documentation still describes seed on surfaces that support the field and notes that output can become more reproducible, but not absolutely deterministic. Seed is useful for tests when available, but it is not a portable standard across OpenAI, Claude, and Gemini and does not replace versioning, context control, and repeated evaluation.
A reproducible test to find out whether your configuration really became more consistent
The safest way to choose among parameters is to measure the behavior of your own task. The test below does not depend on believing that a "low" value is automatically better.
Define a closed test case
Choose a representative task and keep the input fixed. A good example is asking for a text to be classified into one of five categories, with a short justification and structured output. Record the system prompt, user prompt, context, available tools, schema, token limit, model, endpoint, and reasoning or thinking controls.
Run a repeated baseline
Run the same configuration at least twenty times. Save the raw response, token usage, latency, tool calls, and any API errors. If there is a documented seed for that model, record the value used as well.
The main metric does not have to be "identical text." For classification, measure category agreement rate. For extraction, measure schema validity and equality of fields. For free text, evaluate the presence of required information, length, and meaningful semantic divergences.
Change one variable at a time
Change only one element: reasoning effort, effort, thinking level, model, prompt, or structured output. Do not change the model and prompt at the same time. If the API still provides temperature or top_p for that model, test one at a time, following the provider's recommendation not to tune both simultaneously without a reason.
Then repeat the runs and compare. The goal is to discover which configuration delivers the best combination of accuracy, consistency, latency, and cost for your case, not to find a magic number.
Treat a parameter error as a test result
In 2026, a 400 caused by temperature, top_p, or top_k is useful information: it shows that your configuration is coupled to a different model generation. Your compatibility test should fail early during deployment when a field stops being accepted, rather than silently retaining a parameter with no effect.
Why "temperature = 0" has become an incomplete recommendation
The phrase is still useful in models that actually expose temperature and when the goal is to reduce sampling diversity. The mistake is turning it into a synonym for determinism, quality, or operational consistency.
Determinism depends on more things: model version, infrastructure, context, tools, retrieved data, reasoning, output format, and possible backend updates. In addition, current providers are shifting behavior control toward parameters that do not exist in the old sampling recipe.
In a modern model, the best configuration may be to omit temperature, use reasoning or thinking at the appropriate level, require structured output, limit the response, and run evals. In another model, temperature may still be legitimate. The decision now starts with the model's documented compatibility, not the numerical value of the parameter.
A migration rule that keeps your application from breaking
When switching models, preserve the prompt and test case first, then review the payload against the destination model's specific documentation. Remove deprecated parameters, explicitly set the new reasoning or thinking control when it affects cost and behavior, keep the same output schema, and run the evaluation suite before changing the prompt text.
In OpenAI, do not assume that a field available in the Responses API works in every GPT model at every reasoning effort level. In current Claude models, remove temperature, top_p, and top_k from newer models and work with effort, prompting, and structured outputs. In Gemini 3.x, follow the migration to thinking_level and remove the three classic sampling controls. If you remain on Gemini 2.5 or an older non-reasoning model, document that dependency so the next migration is not a surprise.
Modern control is about contracts, not parameter superstition
Temperature, top_p, and top_k have not disappeared from generation theory, but they have lost their status as universal product knobs. The 2026 practice is more specific: confirm what the model accepts, use the appropriate reasoning or thinking control, impose structure when output must be predictable, and repeatedly measure the real task.
If you need consistency, the more useful question is no longer "what temperature should I use?" but "what combination of model, version, reasoning, format, context, and testing keeps behavior within the amount of variation my product can tolerate?" That question remains valid even when the provider decides to remove the next parameter from the API.
