Unsupported parameter: 'temperature' is not supported with this model: which GPT-6 models accept it

On 5 October a developer sent two requests to gpt-6-luna on the Responses API that differed only in reasoning effort, both with temperature: 0. With reasoning: { effort: "none" } OpenAI returned 200 and echoed the temperature back. With effort: "medium" it returned 400, Unsupported parameter: 'temperature' is not supported with this model.

The rule behind that 400 is in OpenAI's GPT-6 migration checklist, which says to remove temperature, top_p and top_logprobs when the reasoning effort is not none, and logprobs as well on Chat Completions. The five GPT-6 model pages, the reasoning guide and the API reference entries for temperature and top_p do not repeat it. A request that never mentions an effort runs at the model's default, and the default is medium on GPT-5.6, GPT-6 Sol, GPT-6 Luna, GPT-6.1 Sol and GPT-6.1 Terra. The gpt-5.4 page lists none as its default, so a request with a temperature that worked on gpt-5.4 starts failing when the model string is the only thing that changes. An energy-tracking app that reads supplier bills reported the same pattern on 27 October: gpt-5.6-terra returned the 400 for temperature: 0, while the same app still worked with gpt-5.4-nano. The same change of default breaks function tools on Chat Completions.

Sampling survives only at effort none, and only some models can run there

In OpenAI's GPT-6 guide, Astra is the highest-intelligence model, 6.1 Sol delivers near-Astra performance at a lower cost, Terra is fast and efficient, and Luna is the fastest and most cost-effective; GPT-6 Sol is the earlier Sol. GPT-6 Astra and GPT-6.1 Sol cannot run at none at all. OpenAI's reasoning guide says that setting none on GPT-6 Astra returns HTTP 400 and that GPT-6.1 Sol does not support it either, so the checklist leaves those two no effort at which sampling is allowed. GPT-6 Sol, GPT-6 Luna and GPT-6.1 Terra do accept none, and public checks show them taking sampling parameters there. TanStack AI's pull request lists live Responses calls with temperature: 0.5 and top_p: 0.9 that returned 200 at none and 400 at low on both Sol and Luna. A pull request to new-api, an open-source LLM gateway with OpenAI-compatible APIs, shows a request to GPT-6.1 Terra with none and temperature: 0.85 coming back 200, and a forum reply says the same of Terra and adds that sampling "was blocked on gpt-6.1-sol". OpenAI's pages phrase the rule as something to remove and never say outright that these parameters are accepted at none, so the Accepted cells in the table rest on the checks above.

The three GPT-5.6 models also run at none. The AI SDK's catalog allows sampling for them through its rule for GPT-5.1 and later, and a table in a Neon gateway issue says the same. Both are third-party sources, so the table leaves that cell unconfirmed.

Either remove the parameters, or keep them on a model the table marks Accepted and set the effort to none. For a gpt-4.1 call with temperature: 0 that does extraction or classification, running at none is the closest GPT-6 request, and the GPT-4o and GPT-4.1 migration guide covers how to compare its outputs with the old ones. Astra and 6.1 Sol offer no such setting.

The error comes in two wordings, and only removing the parameter is documented

The message in the title is the parameter wording. The value wording ends with a hint:

Unsupported parameter: 'temperature' is not supported with this model.
Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.

In reports of direct calls to OpenAI, Responses answered with the parameter wording: the AI SDK report above at medium, TanStack AI at low, and a LangChain report for gpt-6-astra. One report, llm_wiki #824, shows a direct Chat Completions call: it sent temperature: 0.1 to gpt-6-luna on /v1/chat/completions with no effort and got the value wording. nebula-chat #671 records param: temperature and code: unsupported_value for the value wording on gpt-5-mini. Cherry Studio's thread collects both wordings, including the value wording for gpt-6.1-terra through new-api. Most other reports do not name the endpoint, so I would match both. In these reports top_p appears only in the parameter wording, with the code unsupported_parameter in a Cherry Studio report for gpt-5.6-terra sent to CherryIN's Responses endpoint.

The hint at the end of the value wording fits GPT-5, which retires on 11 December: LangChain's validator keeps a temperature of 1 and removes every other value for gpt-5 names unless the effort is none. OpenAI's GPT-6 checklist says nothing about 1; it says to remove the parameter. Two reports sent the default value and were still rejected: openai-oauth #49 sent temperature: 1 to gpt-6-astra on Responses through the Codex backend the project forwards to and got a 400 that cleared when the field was removed, and a Cherry Studio request carrying top_p=1 to gpt-5.6-terra on Responses through CherryIN was rejected for top_p.

Amazon Bedrock's Converse API gives no exception for none. Pydantic AI's live probe found that OpenAI's GPT-5.6 and GPT-6 models reject temperature and top_p there even with the effort set to none, and the AI SDK's Bedrock issue shows the text: This model doesn't support the temperature field. Remove temperature and try again.

Library fixes key on the model name, and the names lag the models

Issues and pull requests in 13 repositories quote one of the two wordings between 20 September and 29 October. Where a fix exists, it matches on the model name.

LangChain's ChatOpenAI removes temperature only for names that start with gpt-5, once in validate_temperature and again when it builds a Responses payload. It never removes top_p, and a gpt-6-* name matches neither check, so both go out as set. arm/metis hit that on 29 September with Sol and Luna, and a LangChain issue reporting it for gpt-6-astra was closed as not_planned on 20 October, with the maintainer asking anyone who hit it in real use to open a new issue. With LangChain I would leave both unset above none, because an unset value is not sent.

The Vercel AI SDK removes the parameters instead of sending them, and it decides from a catalog keyed by model ID: temperature and top_p stay only when the effort resolves to none and the model's entry allows it. Its GPT-6 entries allow the same models as the Accepted rows above. Until a fix merged on 8 October, Sol and Luna lost them even at none, which is the report behind this post's opening. Because the SDK drops the value without failing, the only sign is a warning on the result.

One project shipped a retry and another proposed one. obelix74/docs fixed its GPT-6 failure in v8.8.0 by matching every GPT major from 5 on and adding a retry that drops the parameter after a rejection, "so a future model family will not hit this again", and llm_wiki #824 proposes a retry keyed on the sentence Only the default (1) value is supported. That sentence is in the value wording only, so a retry keyed to it never fires on the parameter wording. I prefer a lookup by model ID with a log line to a retry: the text a retry would match comes in two wordings here and a third on Bedrock, and every retry adds a failed round trip before the call that works.

How AIVAX handles temperature: validated at save time, omitted for flagged models on requests

AIVAX's integrated models carry a NoTemperature flag in the product code. It is set on @openai/gpt-6-astra, @openai/gpt-6.1-sol, @openai/gpt-6.1-terra, @openai/gpt-6-sol, @openai/gpt-6-luna and the three @openai/gpt-5.6-* models. It is also set on @openai/gpt-5.4, the older GPT-5 models, @openai/o3, @openai/o3-mini and @openai/o4-mini, and not on @openai/gpt-5.5 or @openai/gpt-5.5-pro. The public catalog does not expose the flag, and the AI Gateway docs say only that some integrated models reject temperature.

The flag is checked twice. Saving a gateway that uses an integrated model with a Temperature, 0 included, is refused with a 400, and the validation error reads The specified model @openai/gpt-6-luna does not supports temperature. Please, remove that parameter. Editing a gateway merges the fields you send into the saved parameters and validates the result, so a gateway that already stores a temperature is refused the same way when you point it at one of these models. I think the save-time refusal is the more useful half: a gateway is configured once, and the mistake surfaces when you save it instead of in the first production request.

A request is treated differently. The same docs page lists temperature, top_p and reasoning_effort among the values a request can override, and the chat endpoint reads all three from the body. For a flagged model the gateway leaves temperature out of the payload whatever the effort, so the call succeeds without it; on @openai/gpt-6-luna at none, where OpenAI's API accepted it in the checks above, the value is simply not sent, and the response does not mention the omission. top_p is passed to the provider as sent, so a request with top_p and no reasoning_effort reaches the provider at the model's default effort, which is medium on most of these models, where OpenAI's checklist says it is rejected; whether it fails depends on the provider that serves the call, and a route through Amazon Bedrock accepted it in my run. The way to avoid that is to set reasoning_effort to none on the models the table marks Accepted, and to leave top_p unset on the others. @openai/gpt-5.5 has no flag, so its temperature is forwarded, and the table in the Neon issue lists gpt-5.5 as accepting it only at none.

For an integrated model and for a BYOK gateway alike, a provider's 400 comes back as an HTTP 400 carrying the provider's message, inside AIVAX's own envelope: error.param is null and error.code is invalid_request_error, so a client that branches on OpenAI's unsupported_parameter has to match the message text instead. On a stream, the error is a last chunk with finish_reason set to error, followed by [DONE]. The wording depends on which provider served the request: the public catalog lists Azure for each of these models and Amazon Bedrock for most.

On AIVAX I would set reasoning_effort explicitly, because the gateway adds no effort of its own to these models and the provider's default applies, and keep top_p only for requests at none on the models the table marks Accepted. An integrated model cannot carry a temperature even there, because the flag drops it; a BYOK gateway is not validated against the flags, so one that points at OpenAI forwards a saved Temperature as written. The post on setting reasoning effort across providers shows how.

One guard in front of the client can apply the rule from the model and the effort

The rule fits in one function that runs on the request body before it is sent. It needs the model ID, with a prefix such as openai/ or @openai/ removed, and the effort: reasoning_effort on Chat Completions and reasoning.effort on Responses. A request that names no effort is treated as above none, because the three models that can keep sampling default to medium.

const SAMPLING = ["temperature", "top_p", "top_logprobs", "logprobs"];
const LOGPROBS_INCLUDE = "message.output_text.logprobs";
const KEEPS_SAMPLING_AT_NONE = new Set(["gpt-6-sol", "gpt-6-luna", "gpt-6.1-terra"]);

export function dropRejectedSampling(body) {
  const id = String(body.model).split("/").pop();
  if (!/^gpt-(6|5\.6)\b/.test(id)) return { body, dropped: [] };

  const effort = body.reasoning_effort ?? body.reasoning?.effort;
  if (effort === "none" && KEEPS_SAMPLING_AT_NONE.has(id)) return { body, dropped: [] };

  const dropped = Object.keys(body).filter(key => SAMPLING.includes(key));
  const kept = Object.fromEntries(Object.entries(body).filter(([key]) => !SAMPLING.includes(key)));

  if (kept.include?.includes(LOGPROBS_INCLUDE)) {
    kept.include = kept.include.filter(item => item !== LOGPROBS_INCLUDE);
    dropped.push(LOGPROBS_INCLUDE);
  }

  return { body: kept, dropped };
}

It lets sampling through only for the three models with a public check at none. The GPT-5.6 models and any GPT-6 ID outside the set lose their sampling parameters at every effort, so a new model costs a missing temperature instead of a 400. The function also removes message.output_text.logprobs from include, which the checklist asks for on Responses.

Return the dropped list to the caller and log it with the model and effort, the way the AI SDK attaches a warning to its result.

Read on 30 October 2026: the OpenAI 200 and 400 results come from public reports, the AIVAX behavior from the product code, and the guard ran against twelve offline tests. On November 10, 2026 I ran the AIVAX side against the live API: @openai/gpt-6-luna with temperature: 0 at effort none, and with temperature and top_p at medium, both returned 200 from an Amazon Bedrock route, and saving a gateway with Temperature: 0 on that model returned the 400 quoted above. I did not find or check a temperature: 1 request on Chat Completions, sampling on the GPT-5.6 models at none, gpt-5.5 at its default effort, sampling at none through the Azure and Amazon Bedrock providers, or the HTTP status of a streamed error. The count of 13 repositories comes from GitHub searches without a token and is partial.