Farewell, Temperature: Why Claude, GPT-6 and Gemini Are Killing the Knob

What this is about

If you've read any tutorial on language models in recent years, you know the rule of thumb: temperature 0 for factual, repeatable answers, higher values for creative ones. That rule no longer applies with the big providers. On October 21, 2026, Anthropic removed the temperature, top_p and top_k parameters entirely with API version 2026-10-21. It's the first new version since 2023-06-01. OpenAI rejects non-default values on GPT-6, and Google ignores them on Gemini 4. As a result, programs on GitHub are reporting errors left and right.

This piece explains what the setting does technically, why it tends to hurt modern reasoning models, and why “temperature 0 means deterministic” was always a myth. It also shows what you should set instead today, and where the knob still works.

What temperature actually does

A language model doesn't write a word directly. It gives every possible next word (more precisely, every token) a score, converts those scores into probabilities and then rolls the dice. That dice roll is called sampling. Before the conversion, temperature divides all scores by the same number. If the divisor is small, the gaps between candidates widen and the favorite almost always wins. If it's large, the gaps shrink and long shots get picked more often.

BenchLM works through a made-up example. The model is asked to continue “Quarterly revenue was …”, and the candidates get these scores: “strong” 5, “flat” 3, “mixed” 2. We checked the math, and it holds up:

Temperature	“strong”	“flat”	“mixed”
0.2	100.0%	0.0%	0.0%
0.5	98.0%	1.8%	0.2%
1.0	84.4%	11.4%	4.2%
1.5	71.5%	18.8%	9.7%
2.0	62.9%	23.1%	14.0%

Temperature 0 is a special case, because you can't divide by zero. Providers then simply always pick the most likely word, which is called greedy decoding. The compounding effect matters. By our calculation, a text with ten such forks in the road lands on the favorite every single time with only about 18 percent probability at temperature 1 (0.844 to the power of 10), and about 82 percent at temperature 0.5. BenchLM also stresses that a low temperature doesn't make a model smarter. It just makes the model commit more firmly to its first choice, whether that choice is right or wrong.

Top-k and top-p are related filters. They cut candidates before the dice roll: top-k keeps the k most likely words, top-p keeps the smallest group whose combined probability reaches p.

Why the knob hurts reasoning models

Modern models like GPT-6, Claude Opus 5.5 or Gemini 4 first write a long internal chain of thought before answering. Google puts it bluntly for Gemini 3: it “strongly recommends” leaving temperature at the default of 1.0. Lower values could lead to looping or degraded performance, especially on complex math and reasoning. The model's reasoning capabilities are optimized for the default value.

The paper “Wait, Wait, Wait… Why Do Reasoning Models Loop?” (ICML 2026, Pipis et al.) looks into why. The authors had open reasoning models solve AIME math problems at temperature 0 and counted responses in which a piece of text repeats at least 20 times:

Model (temperature 0)	Share of loops
R1-Distill-Qwen 1.5B	76%
R1-Distill-Llama 8B	54%
R1-Distill-Qwen 7B	49%
Phi-4-reasoning	43%
R1-Distill-Qwen 32B	37%
OpenThinker3-1.5B	30%
QwQ-32B	4%

The authors identify two causes, both of them learning errors. When the right next step is hard to learn but going in circles is easy, the circle gets too much probability. On top of that, transformers make errors that are correlated over time. Greedy decoding amplifies both, because it keeps picking the same wrong favorite. A higher temperature eases the problem but doesn't fix the cause. The authors call it a “stopgap.”

Our assessment: there's a second plausible reason, even if the providers don't spell it out. In reinforcement learning (the model learns from rewards for its own solution attempts), the model generates its practice answers using the normal sampling distribution. So what it learns applies to exactly that distribution. That fits the measurements: according to BenchLM, 71 percent of benchmark entries at Vals AI with a logged temperature ran at 1.0, and just 1.4 percent at 0. If you force 0 in practice, you're using a setting almost nobody has tested.

Qwen also warns explicitly in its Qwen3 model card:

“DO NOT use greedy decoding, as it can lead to performance degradation and endless repetitions.”

The myth of “temperature 0 = deterministic”

Even before the removal, temperature 0 never guaranteed identical answers. Horace He of Thinking Machines Lab explained why in 2025. The cause isn't vague “rounding errors” but a lack of batch invariance: servers bundle many requests into a batch, and depending on batch size, the compute kernels run operations in a different order. Batch size depends on server load, which changes constantly. In his experiment with Qwen3-235B and 1,000 requests at temperature 0, he got 80 different texts. All were identical up to token 102, then 992 wrote “Queens, New York” and 8 wrote “New York City.” Only with custom-modified kernels were all 1,000 identical, and the run took 42 seconds instead of 26.

Real-world tests back this up. Datallmlab sent five identical requests at temperature 0 via OpenRouter, and only 2 of 19 models gave the same answer every time. BenchLM had 30 support tickets evaluated: 277 of 289 three-run series were identical, and the differences showed up almost exclusively on ambiguous tickets.

What the providers are doing now

Anthropic: In version 2026-10-21, any request containing one of the three parameters returns a 400 error, “even at the parameter's default value.” That applies to the Messages API, token counting and batches. If you leave the parameter out, you get temperature 1.0. Nothing changes for Claude 4.7 and later, since those already accepted only the default. With Claude Sonnet 4.6, though, a deliberately lowered temperature is lost:

“No other setting replaces it.”

The new version arrives automatically as soon as you install the new major SDK versions (Python 2.0.0, TypeScript 1.0.0, Go 2.0.0, Java 3.0.0 and others). According to a bug report at ragas-ng, messages.create() in Python SDK 2.6.0 no longer knows the parameter at all. The request then fails on your own machine with a TypeError. If you still want control on models older than 4.7, you can send the old version 2023-06-01.

OpenAI: The GPT-6 guide says that when reasoning effort isn't none, you should “remove temperature, top_p and top_logprobs.” GPT-6 Astra and GPT-6.1 Sol don't support none at all; GPT-6.1 Terra, GPT-6 Sol and GPT-6 Luna do have that level. One catch: according to third parties like reAPI, the default is medium. That's why most requests that include a temperature fail. Flowplan's bug report from November 11 shows the typical picture: “'temperature' does not support 0.2 with this model. Only the default (1) value is supported.” Similar errors cropped up in Home Assistant and MCP Assist.

Google: Gemini 3 still accepts temperature but advises against changing it. From Gemini 3.6 on, the docs say the parameters are “deprecated and will be ignored,” and future model generations are supposed to respond with a 400 error. Gemini 4 Argon, generally available since October 13, ignores custom values and, according to Google, returns a deprecation warning.

The silent trap: you change a setting and nothing happens

An error is annoying, but at least you notice it. It's more dangerous when your value just quietly disappears:

• OpenRouter: According to its docs, requests on default routing also reach providers that don't support every parameter. Those providers “ignore unknown parameters.” Datallmlab confirmed it: four models responded normally to temperature: 1.7, while require_parameters: true produced an error. Digitalapplied also found that for 6 of 11 models where a changed temperature has no effect or triggers an error, the OpenRouter catalog still listed it as supported. Among them were Claude Opus 5.5, Kimi K3 and DeepSeek V4.1 Flash.
• DeepSeek API: Thinking mode is on by default. Temperature has no effect there, and according to the docs, you don't get an error either. DeepSeek's well-known table (0.0 for code, 1.5 for poetry) therefore only applies without thinking mode.
• Libraries: LiteLLM drops unsupported parameters with drop_params=True, and in its proxy for Claude Code and Codex it even does so by default. For a while, the Vercel AI SDK removed temperature on GPT-6 Sol and Luna even at none, though at least with a warning (fixed in @ai-sdk/openai 4.0.90).

Our assessment: a slider in a UI proves nothing. If you want to be sure, run the test Digitalapplied recommends: send a request with a non-default value and check whether you get an error or whether anything changes.

What helps instead

• Reasoning effort or thinking_level: Determines how long the model thinks, and with it cost, speed and thoroughness. Gemini 4 offers low, medium (default) and high.
• Verbosity: At OpenAI, text.verbosity (low/medium/high) controls response length, which is what many people used to tweak temperature for.
• Structured outputs: According to reAPI and Digitalapplied, a fixed JSON schema with strict: true is the best replacement for “temperature 0” when you need reliably machine-readable answers.
• Seeds: They're a best effort, not a guarantee. OpenAI itself says determinism isn't guaranteed. In Datallmlab's tests, seed: 42 brought Gemini 3.8 Flash down from five variants to one, while other models barely changed.
• Repeat instead of hoping: BenchLM recommends running every important case at least three times. If the answers differ, the input is apparently ambiguous to the model. If you want variety, ask for several variants in the prompt.

Overview: where the knob still works

Provider/model	Temperature	Vendor recommendation
Claude (API 2026-10-21)	400 error	omit, steer via prompt
Claude 4.7+ (old API)	default 1.0 only	omit
GPT-6 Astra, GPT-6.1 Sol	not supported	set effort
GPT-6.1 Terra, GPT-6 Sol, Luna	only at effort none	otherwise omit
Gemini 3	works	keep at 1.0
Gemini 3.6+, Gemini 4	ignored	omit
DeepSeek API (thinking mode)	silently ignored	omit
Kimi K3	error	fixed at 1.0
Grok 4.7, GLM-5.3, Mistral	works	Mistral: 0.0–0.7
Qwen3 (local, thinking/normal)	works	0.6/0.95/k20 or 0.7/0.8/k20
Qwen3.8-27B (local)	works	thinking 1.0/0.95/k20; instruct 0.7/0.8/k20, presence_penalty 1.5
DeepSeek V4.1 Flash (local)	works	1.0, top_p 1.0
Gemma 4 (local)	works	1.0/0.95/k64 for everything

With local tools, it pays to take a second look. Ollama has a global default of 0.8, but ships its own values for library models, for qwen3 for example 0.6/top_k 20/top_p 0.95. According to a pull request, llama.cpp uses a fixed order: first your launch parameters, then the recommendations stored in the GGUF file, and finally hard-coded defaults. There's no guarantee the recommendations are actually stored in your file. When in doubt, set the values from the model card yourself. Qwen also points out that not every program supports every parameter.

The bigger picture

This is more than housekeeping. For models that think first and answer second, temperature had turned from a tool into a liability. It did little for reliability and, in the worst case, caused infinite loops. Providers are shifting control to knobs that fit how these models work: thinking effort, response length, fixed formats.

Three concerns remain. First, teams on older models like Claude Sonnet 4.6 lose a real lever with no replacement, and they may not notice if an update slips through automatically. The newsletter Prompt-Led Product points this out. Second, the vendors barely justify the move: Anthropic says what to do, but not why. Third, there's no clean measurement of how much a given temperature actually costs or gains in quality on today's models. BenchLM explicitly didn't measure that either.

Our assessment: for most users, the right setting from now on is to simply leave the parameter out. For local models, take the values from the model card, not 0 from old tutorials. If you need reproducibility, secure it with schemas, pinned model versions and repeated runs, rather than expecting it from a knob that never guaranteed it.