OpenAI, Claude and Gemini API "Unsupported parameter: temperature": which models reject it and the fix
Last verified: November 6, 2026
A request that worked for months suddenly comes back with HTTP 400 and a message saying that temperature is not supported, or that it is deprecated for this model. Nothing in your code changed except the model name. The cause is almost always the same across providers: the newer reasoning models fix their own sampling settings, so remove temperature from the request. On OpenAI the same rule covers top_p and log probabilities, on Claude it also covers top_p and top_k, and on Gemini 4 the parameters stop doing anything even when they do not raise an error.
The change reached developers at different times. OpenAI's reasoning models have rejected sampling parameters since the o-series, and the GPT-6 family now accepts them only when reasoning is switched off. Anthropic started returning errors with Claude Opus 4.7 and applies the rule to every later Claude model, including Haiku 5.5, where open-source projects reported broken requests in the first days of November 2026. Google recommends leaving temperature at its default on Gemini 3 and ignores it entirely from Gemini 4 Argon onward. The tables below show what each provider does with the parameter and what to send instead.
··········
THE TEMPERATURE ERROR TEXT ON OPENAI, CLAUDE AND GEMINI.
The wording differs by provider, and only two of the three return an error at all. Libraries such as LangChain, LiteLLM or the OpenAI SDK used against another provider often add a default temperature on their own, so the parameter can appear in the request even when your code never sets it.
........
Provider | What you see | HTTP status | Where it is documented |
OpenAI API | Unsupported parameter: 'temperature' is not supported with this model. (code unsupported_parameter, param temperature) | 400 | Message reported on the OpenAI Developer Community; the rule is in the GPT-6 model guide |
Claude API | `temperature` is deprecated for this model. | 400 | Message reported in several GitHub issues; the rule is in Anthropic's migration guides |
Claude via OpenAI SDK compatibility | 400 for any temperature below 1, any top_p other than 0.99, or both set together | 400 | Anthropic's OpenAI SDK compatibility page |
Gemini API, Gemini 4 Argon | No error: sampling parameters are ignored | 200 | Google's Gemini 4 Argon migration checklist |
Gemini API, Gemini 3 models | No error: temperature below 1.0 is accepted but discouraged | 200 | Google's Gemini 3 developer guide |
........
The OpenAI message above is the one quoted by developers on the official community forum for o3-mini and for the GPT-5 models in 2025, and the same validation applies to the GPT-6 family. The Claude message comes from bug reports filed against several open-source projects, for example a report of November 4, 2026 in which every request to Claude Haiku 5.5, through both the Claude API and Amazon Bedrock, failed with it while the same code worked on Claude Haiku 4.5. Anthropic's documentation describes the rejection without quoting the exact message.
··········
WHY OPENAI, CLAUDE AND GEMINI REASONING MODELS STOPPED ACCEPTING TEMPERATURE.
Temperature controls how random the choice of each next token is. A low value makes the model pick the most likely tokens, a high one spreads the choice. Reasoning models generate a long internal chain of thought before the answer, and the providers tune that process around a fixed sampling setting. Google states it plainly for Gemini 3: the models' reasoning is optimized for the default temperature of 1.0, and lower values may cause looping or degraded performance on complex mathematical or reasoning tasks.
Anthropic's guides for Claude Opus 5.5 and Claude Haiku 5.5 tell developers to omit temperature, top_p and top_k and to use prompting to guide the model's behavior. The Opus 5.5 migration guide adds that a temperature of 0 never guaranteed identical outputs on earlier models either, which removes the most common reason teams set it. OpenAI's GPT-6 guide gives the rule in one line: when reasoning effort is not none, remove temperature, top_p and top_logprobs.
There is a second, less visible effect on Claude. Anthropic's compatibility documentation says that, depending on the model, text generated with a temperature or top_p different from the default might not carry Claude's text watermark, so applications that rely on the watermark should omit both parameters.
··········
CAUSES OF THE UNSUPPORTED TEMPERATURE ERROR AND HOW TO FIX EACH ONE.
Most failures fall into a short list. The first column is what is happening, the second tells you how to confirm it in a minute, the third is the change to make.
........
Cause | How to check | Fix |
You switched to an OpenAI reasoning model and still send temperature | Log the request body; look for temperature or top_p next to a GPT-6 model | Remove both, or set reasoning effort to none on a model that supports it |
The OpenAI model defaults to medium reasoning effort | No reasoning effort in the request: GPT-6.1 Terra then runs at medium | Send reasoning effort none explicitly if you need temperature |
The OpenAI model does not support effort none | Model is gpt-6-astra or gpt-6.1-sol | Remove temperature, top_p and top_logprobs; steer with the prompt |
You moved to Claude 4.7 or a later Claude model | Model ID is claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5 or a 4.7+ model | Remove temperature, top_p and top_k from the payload |
Your library adds a default temperature | Request body contains temperature that your own code never sets | Set the library's temperature option to none or unset, or upgrade to a release that omits it for these models |
You send both temperature and top_p to Claude | Both keys present in the request | Remove both on 4.7+ models; on older Claude models keep at most one |
Your Gemini 4 output does not change when you change temperature | Model is gemini-4-argon; compare two runs at different values | Remove the parameter and use thinking_level and the prompt instead |
........
··········
STEP-BY-STEP FIX FOR THE OPENAI API.
OpenAI's GPT-6 guide lists the current models as gpt-6-astra, gpt-6.1-sol, gpt-6.1-terra and gpt-6-luna, plus gpt-6-sol for existing users. Only some of them can run without reasoning, and only then are sampling parameters allowed.
........
OpenAI model | Reasoning effort none | Temperature and top_p |
gpt-6.1-terra | Supported (default is medium) | Only with effort none |
gpt-6-sol | Supported | Only with effort none |
gpt-6-luna | Supported | Only with effort none |
gpt-6.1-sol | Not supported (low to max, default medium) | Not accepted |
gpt-6-astra | Not supported, returns HTTP 400 | Not accepted |
........
1. Find where the request is built and print the final JSON body, after your SDK or framework has added its defaults.
2. If the model is gpt-6-astra or gpt-6.1-sol, delete temperature, top_p and top_logprobs. With Chat Completions also delete logprobs; with the Responses API remove message.output_text.logprobs from include.
3. If the model is gpt-6.1-terra, gpt-6-sol or gpt-6-luna and you need sampling control, set reasoning.effort (Responses) or reasoning_effort (Chat Completions) to none. Any other effort level brings the error back.
4. Check function calling: OpenAI's guide says GPT-6 Sol and GPT-6 Luna support function calling in Chat Completions only with reasoning_effort set to none.
5. Keep the effort value stable across requests. The guide notes that changing request-level reasoning effort breaks the cached prompt prefix.
The request below is illustrative, built from the parameter names in OpenAI's GPT-6 guide: a Responses API call to a model that supports effort none, with temperature allowed because reasoning is off.
{
"model": "gpt-6.1-terra",
"reasoning": { "effort": "none" },
"temperature": 0.2,
"input": "Classify this ticket as billing, bug or feature request: ..."
}··········
[[ADPLUS_300x250_1]]
STEP-BY-STEP FIX FOR THE CLAUDE API.
Anthropic's OpenAI SDK compatibility page gives the most precise statement of the rule: on Claude 4.7 and later models and Claude Mythos Preview, any temperature below 1 returns a 400 error, any top_p other than the default 0.99 returns a 400 error, and a request that sets both temperature and top_p also returns a 400 error. The migration guides for Claude Opus 5.5 and Claude Haiku 5.5 go one step further and tell developers to omit temperature, top_p and top_k entirely.
1. Remove temperature, top_p and top_k from every request to claude-opus-5-5, claude-sonnet-5-5, claude-haiku-5-5 and the other 4.7+ models.
2. If you used temperature 0 to get repeatable answers, move that requirement into the prompt (fixed output format, explicit rules) or into structured outputs. Anthropic says temperature 0 never guaranteed identical outputs anyway.
3. Replace the old thinking budget at the same time. On Claude Opus 4.7 and later, thinking with type enabled and budget_tokens returns a 400 error; use thinking with type adaptive and the effort parameter. On Claude Opus 5.5 thinking cannot be disabled at all.
4. Raise max_tokens if you set it low for Haiku 4.5. Anthropic notes that on Haiku 5.5 thinking tokens count toward max_tokens, so a small limit can stop the response after a thinking block and before any text.
5. Through Amazon Bedrock the same rule applies; the error arrives wrapped in a ValidationException from the Converse operation.
The before and after request below is taken from Anthropic's Claude Haiku 5.5 migration guide. The new request carries no sampling parameters and controls depth with effort.
{
"model": "claude-haiku-5-5",
"max_tokens": 16000,
"thinking": { "type": "adaptive" },
"output_config": { "effort": "medium" },
"messages": [{ "role": "user", "content": "..." }]
}Older Claude models behave differently. Claude Haiku 4.5, for example, still worked with a temperature in the November 2026 bug report cited above, which is why the error tends to appear on the day a team changes the model ID.
··········
WHAT GEMINI DOES WITH TEMPERATURE, TOP_P AND TOP_K.
Google takes a softer route, which makes the problem harder to notice. Nothing fails, but the setting may not do what you expect.
........
Gemini model | Temperature behavior | What Google recommends |
gemini-4-argon | Sampling parameters are ignored if provided | Remove temperature, top_p, top_k and candidate_count |
Gemini 3 models (e.g. gemini-3.1-pro-preview, gemini-3-flash-preview) | Accepted; values below 1.0 may cause looping or degraded reasoning | Keep the default of 1.0 |
........
1. On gemini-4-argon, remove temperature, top_p, top_k and candidate_count, as the migration checklist asks. Their presence does no harm, but it hides the fact that they no longer steer the output.
2. Use thinking_level for the trade-off between speed and depth. Gemini 4 Argon defaults to medium, which Google calls the recommended level for most tasks, including complex code and agentic use.
3. If you still send thinking_budget, Google says it maps to the nearest thinking_level and returns a warning. On Gemini 3, sending thinking_level and thinking_budget in the same request returns a 400 error.
4. On Gemini 3 models, delete any low temperature you set for determinism and test at the default of 1.0.
The request body below follows the REST example of Google's Gemini developer guide for the Interactions endpoint, with the model name changed to Gemini 4 Argon and the level set to medium: no sampling parameters, thinking level set explicitly.
{
"model": "gemini-4-argon",
"input": "How does AI work?",
"generation_config": {
"thinking_level": "medium"
}
}··········
DOCUMENTED RULES VERSUS USER REPORTS FOR THE TEMPERATURE ERROR.
The rules themselves are documented by all three providers: OpenAI in its GPT-6 guide and reasoning guide, Anthropic in the migration guides and the OpenAI SDK compatibility page, Google in the Gemini 3 and Gemini 4 Argon guides. What is not documented is the exact wording of each error. The OpenAI and Claude messages quoted in this page come from developers who posted them on the OpenAI Developer Community and in GitHub issues, and the providers can change that wording without notice.
Some details remain unclear. Anthropic's model guides say to omit temperature, while the compatibility page says values above 1 are capped at 1 and only values below 1 fail, so a temperature of exactly 1 may pass on some routes; the safe choice is to send nothing. On the OpenAI forum, developers have asked for an official compatibility matrix of reasoning effort and sampling parameters across model versions, and the tables shared there were built by users, not by OpenAI.
··········
HOW TO KEEP THE TEMPERATURE ERROR FROM COMING BACK.
Every model change is now also a parameter change. A short routine prevents most of these outages.
1. Keep sampling parameters out of shared defaults. Set them per model, in one place, and leave them unset for reasoning models.
2. Read the provider's migration guide before changing a model ID. Anthropic publishes one per model, OpenAI keeps a single guide for its latest family, and Google publishes a "what's new" page with a migration checklist.
3. Test the new model with your real request body, including the defaults that your framework adds, before switching production traffic.
4. Track model aliases. Our page on Claude, Gemini and DeepSeek API model names, aliases and pinned versions explains how an alias can move you to a new model without any change in your code, and with it to new parameter rules.
5. Watch the other parameters that changed together with temperature: forced tool choice, assistant prefill and manual thinking budgets now return 400 errors on several Claude models, as Anthropic's Opus 5.5 guide lists.
··········
THE UNSUPPORTED TEMPERATURE PARAMETER ON OPENAI, CLAUDE AND GEMINI: WHAT TO DO.
The fix is the same on all three platforms: stop sending temperature, top_p and top_k to reasoning models and steer them through the prompt and the provider's reasoning control. On OpenAI that control is reasoning effort, and sampling parameters return only on GPT-6.1 Terra, GPT-6 Sol and GPT-6 Luna with effort set to none. On Claude it is adaptive thinking with the effort parameter, and every model from Claude 4.7 onward rejects non-default sampling values. On Gemini it is thinking_level, and Gemini 4 Argon ignores sampling parameters without telling you. Code that still depends on temperature 0 for repeatable output needs a different mechanism, such as a fixed output schema, because none of the three providers now offers that guarantee on its newest models.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
