fix(openai): stop removing temperature/top_p for gpt-5.1 and gpt-5.2

[ColinSidberry]

What

Removes temperature and top_p from removeParams for gpt-5.1 and gpt-5.2. Keeps n and max_tokens removed (see "What this PR deliberately does not change").

Why

The removeParams list on these two files appears to have been carried forward from gpt-5.yaml, where it was correct: the original gpt-5 rejects any non-default temperature/top_p unconditionally. That contract changed with gpt-5.1.

OpenAI's current GPT-5.2 guide, "GPT-5.2 parameter compatibility" states verbatim:

The following parameters are only supported when using GPT-5.2 with reasoning effort set to none: temperature, top_p, logprobs. Requests to GPT-5.2 or GPT-5.1 with any other reasoning effort setting, or to older GPT-5 models — for example, gpt-5, gpt-5-mini, or gpt-5-nano — that include these fields will raise an error.

And none is the default reasoning effort for both models, per their model pages (gpt-5.1: "Reasoning.effort supports: none (default), low, medium, and high"; gpt-5.2: "none (default), low, medium, high and xhigh") — consistent with these files' own params entry (reasoning_effort, defaultValue: none).

So for the default-configuration request — the common case — OpenAI accepts temperature and top_p, and the gateway strips them anyway.

Impact of the current behavior

The strip is silent: a caller sending temperature: 0 to gpt-5.2 gets HTTP 200 and is actually served the model defaults (temperature: 1, and gpt-5.2's internal top_p default of 0.98 — see this OpenAI forum thread). Nothing in the response indicates the parameter was discarded except the echoed values.

We hit this in production: a pipeline that pinned temperature: 0 for deterministic output was migrated from a Claude target (where the gateway forwards temperature untouched) to openai/gpt-5.2, and began sampling at temperature 1 with no error anywhere — the regression surfaced as nondeterministic output quality and took an incident investigation to trace back to the registry entry.

Note that OpenAI itself never silently ignores these params — unsupported combinations get an explicit 400 ("Unsupported value: 'temperature' does not support 0.5 with this model."). After this change, a caller that combines temperature/top_p with reasoning_effort ≥ low will receive that 400 instead of a silent drop. We'd argue that's the better contract: it matches the raw OpenAI API, and it's an actionable client error rather than an invisible behavior change. (This is the same fix direction LiteLLM took for the equivalent issue — see BerriAI/litellm#21911 / #27351, where sampling params are now gated on per-model supports_none_reasoning_effort flags rather than dropped across the board.)

What this PR deliberately does not change

• max_tokens stays removed — gpt-5.x still rejects it; callers must use max_completion_tokens / max_output_tokens.
• n stays removed — we found no official OpenAI statement that gpt-5.x accepts n, so we left it alone.
• gpt-5.4 likely has the same contract (LiteLLM's registry and Azure behavior agree), but OpenAI's guide only names 5.1 and 5.2 explicitly, so we scoped this PR to what's officially documented. Happy to extend to gpt-5.4 if you have confirmation.
• gpt-5.5 / gpt-5.6 family untouched — their default reasoning effort is medium, so removing the strip there would 400 default-effort callers who send temperature. The removal is still protective for those models.
• gpt-5.2-chat-latest (if/where present) should keep rejecting/removing temperature — OpenAI returns 400 for non-1 temperature on that variant regardless of effort.

Sources

• https://developers.openai.com/api/docs/guides/latest-model/gpt-5.2 (parameter-compatibility section)
• https://developers.openai.com/api/docs/models/gpt-5.1
• https://developers.openai.com/api/docs/models/gpt-5.2
• https://community.openai.com/t/top-p-problem-when-running-gpt-5-2-api/1369144 (gpt-5.2 internal top_p default 0.98)
• [Bug]: drop_params: true does not drop temperature for gpt-5.2-chat / gpt-5.2-chat-latest (both OpenAI and Azure) BerriAI/litellm#21911, [Bug]: gpt-5.1-mini / gpt-5.1-nano reject temperature when reasoning_effort is omitted (registry gap — supports_none_reasoning_effort missing) BerriAI/litellm#27351 (same bug class + fix in LiteLLM)

---

Note

Medium Risk
Changes request parameter forwarding for production gpt-5.1/5.2 traffic. Callers combining temperature/top_p with non-default reasoning effort may start receiving OpenAI 400s instead of silent param drops.

Overview
Stops silently stripping temperature and top_p from requests to gpt-5.1 and gpt-5.2. Those params are now forwarded to OpenAI, matching the models' documented support when reasoning_effort is none (the default).

n and max_tokens remain in removeParams. Callers that send temperature/top_p with non-none reasoning effort will now get OpenAI's explicit 400 instead of a silent drop.

^{Reviewed by Cursor Bugbot for commit ad2cdd1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit ad2cdd1. Configure here.}