fix(gpt-5): stop forwarding temperature and top_p to reasoning models that reject them

[tin-berri]

TLDR

Problem this solves:

• gpt-5.5/5.6 accept a non-default temperature/top_p only when reasoning effort resolves to "none"
• litellm read "supports none" as "defaults to none" and forwarded the params
• the carve-out returned before the drop_params branch, so the provider 400 leaked to callers

How it solves it:

• new map key default_reasoning_effort declares the effort a provider applies when unset
• one shared predicate gates temperature and top_p/logprobs across chat, Responses, and /v1/messages
• an undeclared model resolves conservatively: dropped under drop_params, else an actionable 400
• Azure name shapes (azure/, bare, gpt5_series/) normalise in one resolver

User Flow

Before: an agent or eval job using a gpt-5.6-family model with temperature: 0 dies on a raw provider 400 even though the proxy sets drop_params: true

1. They send POST https://litellm-domain/v1/chat/completions with "model": "gpt-5.6-terra", "temperature": 0
2. Back comes 400: Unsupported value: 'temperature' does not support 0 with this model. Only the default (1) value is supported.
3. The same request through POST https://litellm-domain/v1/responses or POST https://litellm-domain/v1/messages fails with the same provider rejection, so an agent dies mid-loop
4. A shadow-evaluation job with that model as judge records judged_count: 0 with every attempt an error row

After: the same requests succeed because the proxy drops the parameter the model cannot take

1. They send POST https://litellm-domain/v1/chat/completions with "model": "gpt-5.6-terra", "temperature": 0
2. 200 comes back with the completion; the proxy dropped temperature under drop_params: true
3. POST https://litellm-domain/v1/responses and POST https://litellm-domain/v1/messages return 200 the same way, and top_p follows the same rule
4. The shadow-evaluation job scores normally, while gpt-5.1/5.2/5.4 requests keep honoring temperature exactly as before

Relevant issues

Supersedes #34210

Linear ticket

Resolves LIT-6355
Resolves LIT-3797
Resolves LIT-5028

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

Local proxy, real OpenAI upstream, no mocks. Shared config:

model_list:
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: os.environ/OPENAI_API_KEY
  - model_name: gpt-5.1
    litellm_params:
      model: openai/gpt-5.1
      api_key: os.environ/OPENAI_API_KEY
general_settings:
  master_key: sk-litellm-qa-6429
litellm_settings:
  drop_params: true

Same five commands both runs, only the checked-out commit changes.

Before (49affa7)

/v1/chat/completions gpt-5.6-terra temperature=0

1. curl -s -X POST http://localhost:31620/v1/chat/completions -H "Authorization: Bearer sk-litellm-qa-6429" -H 'Content-Type: application/json' -d '{"model":"gpt-5.6-terra","messages":[{"role":"user","content":"Say ok"}],"temperature":0}'
2. HTTP 400: litellm.BadRequestError: OpenAIException - Unsupported value: 'temperature' does not support 0 with this model. Only the default (1) value is supported.

/v1/responses gpt-5.6-terra temperature=0

1. curl -s -X POST http://localhost:31620/v1/responses -H "Authorization: Bearer sk-litellm-qa-6429" -H 'Content-Type: application/json' -d '{"model":"gpt-5.6-terra","input":"Say ok","temperature":0}'
2. HTTP 400: litellm.BadRequestError: OpenAIException - Unsupported parameter: 'temperature' is not supported with this model.

/v1/messages gpt-5.6-terra temperature=0

1. curl -s -X POST http://localhost:31620/v1/messages -H "Authorization: Bearer sk-litellm-qa-6429" -H 'Content-Type: application/json' -d '{"model":"gpt-5.6-terra","max_tokens":32,"messages":[{"role":"user","content":"Say ok"}],"temperature":0}'
2. HTTP 400: litellm.BadRequestError: OpenAIException - Unsupported parameter: 'temperature' is not supported with this model.

/v1/chat/completions gpt-5.6-terra top_p=0.5

1. curl -s -X POST http://localhost:31620/v1/chat/completions -H "Authorization: Bearer sk-litellm-qa-6429" -H 'Content-Type: application/json' -d '{"model":"gpt-5.6-terra","messages":[{"role":"user","content":"Say ok"}],"top_p":0.5}'
2. HTTP 400: litellm.BadRequestError: OpenAIException - Unsupported parameter: 'top_p' is not supported with this model.

control: /v1/chat/completions gpt-5.1 temperature=0

1. curl -s -X POST http://localhost:31620/v1/chat/completions -H "Authorization: Bearer sk-litellm-qa-6429" -H 'Content-Type: application/json' -d '{"model":"gpt-5.1","messages":[{"role":"user","content":"Say ok"}],"temperature":0}'
2. HTTP 200, content: ok

After (e5c3df2)

/v1/chat/completions gpt-5.6-terra temperature=0

1. Same command as Before
2. HTTP 200, content: ok

/v1/responses gpt-5.6-terra temperature=0

1. Same command as Before
2. HTTP 200, output text: ok

/v1/messages gpt-5.6-terra temperature=0

1. Same command as Before
2. HTTP 200, content: [{"type": "text", "text": "ok"}]

/v1/chat/completions gpt-5.6-terra top_p=0.5

1. Same command as Before
2. HTTP 200, content: ok

control: /v1/chat/completions gpt-5.1 temperature=0

1. Same command as Before
2. HTTP 200, content: ok

The same rig reproduced the customer-visible symptom end to end. A shadow-evaluation job whose judge was gpt-5.6-terra returned judged_count: 0 with every attempt an error row; on the same job, same key and same requests after the fix:

	before	after
judged_count	0	4
error_count	4	4 (frozen)
judge_spend	0.0	0.003184
results	null	populated

That path never needed a caller-side change: judge_acompletion already passes drop_params=True, and the primitive now honours it.

Type

🐛 Bug Fix

Caveats (if any)

Low

• a future entry declaring supports_none_reasoning_effort without default_reasoning_effort drops the params conservatively
• deployments on a published map predating the key keep today's behavior until the map carries it

Details

The bug

A gpt-5 model accepts a non-default temperature only while its effective reasoning effort
resolves to "none". litellm has no representation of the effort a model applies when the
request omits reasoning_effort, so it substituted supports_none_reasoning_effort, which is
a different fact. Models that support "none" without defaulting to it had temperature
forwarded and rejected upstream, and because the carve-out returned before the drop_params
branch, drop_params: true could not save it.

# gpt_5_transformation.py, before
if supports_none and (effective_effort == "none" or effective_effort is None) or temperature_value == 1:
    optional_params["temperature"] = temperature_value   # keeps temperature=0 for gpt-5.5/5.6

Measured, against the live provider

model	effort unset	effort=none	effort=medium
gpt-5.1, gpt-5.2, gpt-5.4, gpt-5.4-mini, gpt-5.4-nano	accepts
gpt-5.5, gpt-5.6, gpt-5.6-terra, gpt-5.6-sol, gpt-5.6-cyber	rejects	accepts	rejects

The cleanest confirmation is a pair from one family, one map flag apart, behaving oppositely:
gpt-5.6-cyber carries no supports_none_reasoning_effort and litellm correctly dropped
temperature, while gpt-5.6-terra carries it and litellm forwarded temperature=0.

The fix

Declare the missing fact. default_reasoning_effort states the effort the provider applies when
the request omits one, and a single predicate resolves the effective effort: an explicit
reasoning_effort wins, otherwise the declared default, otherwise the conservative answer.

An undeclared model resolves to "reasoning is active", so a model released before its entry
declares a default is dropped or refused with an actionable error instead of 400ing at the
provider, and needs no code change once its entry lands.

Three consumers now share that one predicate:

• the temperature gate
• the top_p/logprobs/top_logprobs gate, which carried the same assumption spelled
  differently and was live-confirmed broken the same way
• the Responses API, which reimplemented the rule, and which the default /v1/messages bridge
  routes openai models through

Azure normalises its routing names in one resolver every capability lookup goes through, which
replaces its bespoke per-lookup rewrite and makes azure/, bare and gpt5_series/ names agree.

Blast radius

60 map entries carry supports_none_reasoning_effort: true, all gpt-5.x, none other.

• 37 entries (gpt-5.1 x13, gpt-5.2 x2, gpt-5.4 x22) accept temperature=0 today and are declared
  "none", so their behaviour is byte-identical
• 23 entries (gpt-5.5 x7, gpt-5.6 x16) reject it today and stay undeclared, fixed by the fallback

Tests

Mutation-checked: with the sources reverted, the new cases fail on exactly the broken models and
pass on the preserved ones. The azure and responses suites needed the bundled cost map pinned,
since the default import fetches the published map, which lags this branch.

Notes for review

• Supersedes fix(gpt-5): respect model default reasoning effort when deciding temperature support #34210, which fixed the same line. That PR falls back to supports_none when the key
  is absent, which is the original guess, so the gpt-5.6 family released after it would still have
  been broken. This one inverts the fallback and declares only defaults measured against the
  provider, so no unverified effort level enters the shared catalogue.
• type-discipline-budget.json is already exceeded on staging for LIT002, LIT006 and LIT012. This
  branch is neutral on every counter; the pre-existing drift is not from here.

Post-review: a regression a live base-vs-head run caught

An earlier revision of this PR fell back conservatively whenever default_reasoning_effort was
absent. That is wrong when the CATALOGUE is older than the code, which is the default topology:
litellm/__init__.py:413 fetches the cost map from the published main branch at import time,
and that map does not carry a key until this PR lands there.

Measured on the actually-published map, base vs head, both trees asserted:

	changes	of which regressions
earlier revision	63 of 132 gpt-5 entries	39
this revision	0	0

The 39 were gpt-5.1, gpt-5.2, gpt-5.4 and their azure/, azure/us|eu|global/ and
azure_ai/ variants silently losing temperature, models that provably accept it. It also broke
a real test, test_azure_base_model_routing.py::test_should_pass_logprobs_through_get_optional_params,
which is unpinned and so reads the published map: it passes on base, failed on the earlier
revision, and passes now. CI did not catch it because the outcome depends on whether the remote
map fetch succeeds or falls back to the bundled copy.

So the absence of a declaration is only meaningful once the catalogue carries the key at all. A
map predating the feature keeps the answer litellm gave before it existed, and the conservative
answer switches on by itself the moment the data lands. TestACatalogueOlderThanTheCodeDoesNotStripTemperature
pins both halves, mutation-checked.

Merge-ref checked against current staging (2306816d40): merges clean, 0 changes and 0
regressions on the merged tree.

[tin-berri]

@greptileai can you reply here with a score and why that score?

[tin-berri]

bugbot run

[greptile-apps]

Score: 9/10.

This is a strong, focused fix with no blocking correctness issues found. It correctly separates supports_none_reasoning_effort from the model’s declared default, applies the same effective-effort predicate to temperature, sampling parameters, and Responses API requests, and uses a conservative fallback for undeclared models so drop_params=True can work instead of forwarding a provider-rejected value. The Azure resolver centralizes name normalization, and the added tests cover preserved GPT-5.1/5.4 behavior, GPT-5.5/5.6 regressions, explicit effort overrides, Responses, Azure route shapes, schema validation, and model-info hydration.

I’m withholding the final point because the PR’s CI status is still pending, so the complete suite has not yet provided an independent confirmation.

[greptile-apps]

Greptile Summary

This PR adds model-catalogue metadata for default reasoning effort and uses it consistently when deciding whether GPT-5 requests may forward sampling parameters.

• Adds default_reasoning_effort to model metadata, schemas, and typed model information.
• Shares effective-effort resolution across OpenAI Chat Completions and Responses transformations.
• Normalizes Azure routing names before capability lookups.
• Adds regression coverage for GPT-5 model families, Azure aliases, Responses requests, and older catalogues.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
litellm/llms/openai/chat/gpt_5_transformation.py	Centralizes effective reasoning-effort resolution and applies it to temperature, top_p, and logprobs gating.
litellm/llms/openai/responses/transformation.py	Reuses the shared GPT-5 effort resolver when filtering Responses API temperature.
litellm/llms/azure/chat/gpt_5_transformation.py	Normalizes Azure model aliases through one cost-map lookup hook.
litellm/utils.py	Adds string-valued model metadata lookup while preserving input parameters through separate resolved bindings.
model_prices_and_context_window.json	Declares a default reasoning effort of none for verified GPT-5 model entries.
tests/test_litellm/llms/openai/test_gpt5_transformation.py	Covers sampling-parameter behavior across explicit, declared-default, undeclared, and older-catalogue cases.

_{Reviews (2): Last reviewed commit: "fix(gpt-5): resolve temperature support ..." | Re-trigger Greptile}

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[tin-berri]

Pushed e649da2 addressing the rebinding finding (replied on the thread; it also corrects the LIT011 detail). CI lint is green locally across all of: ruff check litellm, ruff check --config ruff-tests.toml tests, ruff_strict_gate, type_discipline_gate, test_quality_gate, ruff format, check_files_match and the schema --check.

@greptileai can you reply here with a score and why that score?

[tin-berri]

bugbot run

[greptile-apps]

Score: 10/10.

The rebinding concern is resolved in litellm/utils.py, and the prior LIT011 detail has been correctly withdrawn. The implementation now cleanly separates supports_none_reasoning_effort from the declared provider default, applies the shared effective-effort rule consistently across Chat Completions, sampling parameters, Responses, and Azure route aliases, and uses a conservative fallback for undeclared models. The model-map/schema updates and regression tests cover both preserved and previously failing behavior, explicit effort overrides, hydration, and Azure name normalization. The reported lint/type-discipline/schema checks are green, and the current CI status is successful. I found no remaining correctness or merge-blocking issues.

[codecov]

Codecov Report

❌ Patch coverage is 93.61702% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/utils.py	84.21%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[tin-berri]

Pushed 3b33bbb. CI's basedpyright budget gate caught two reportPrivateUsage errors I had not run locally, both from the new code reaching across a module or class boundary:

• litellm/utils.py now exports declared_value_factory publicly rather than _declared_value_factory, since unlike its two legacy siblings it is read from the provider configs rather than from within that module
• OpenAIGPT5Config.effort_resolves_to_none is public for the same reason: the Responses config calls it, and a shared predicate that two modules consult is not a private one

Both are intentional API surface rather than suppressions. All nine gates green locally now: ruff check litellm, ruff check --config ruff-tests.toml tests, ruff_strict_gate, type_discipline_gate, test_quality_gate, type_check_gate, ruff format, check_files_match, schema --check.

@greptileai can you reply here with a score and why that score?

[tin-berri]

bugbot run

[greptile-apps]

Score: 5/5.

The basedpyright findings are resolved in the correct way: both cross-module consumers now use deliberately public APIs rather than private-usage suppressions. declared_value_factory is an appropriate public utility because provider configurations consume it, and OpenAIGPT5Config.effort_resolves_to_none is appropriately public because the Responses configuration delegates to the same predicate. The implementation keeps the capability/default lookup logic centralized, preserves Azure name normalization, and the added tests cover the shared behavior across model families and API surfaces. With all nine reported gates green and no remaining correctness concerns, this is ready to merge.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_gpt5_default_reasoning_effort (e5c3df2) with litellm_internal_staging (67c7b97)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (2306816) during the generation of this report, so 67c7b97 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[tin-berri]

Pushed e5c3df2. A base-vs-head live run (/live-pr-risk) found a regression in the previous revision that CI could not see, so this revision changes the fallback.

The cost map is fetched from the published main branch at import time (litellm/__init__.py:413), so it can be OLDER than the code reading it. On such a map every model looks undeclared, and the previous revision read that as "reasoning is active" and dropped temperature.

Measured against the actually-published map, base vs head, tree identity asserted on both sides:

	changes	of which regressions
previous revision	63 of 132 gpt-5 entries	39
this revision	0	0

The 39 were gpt-5.1/5.2/5.4 and their azure variants silently losing temperature, models that provably accept it. It also broke test_azure_base_model_routing.py::test_should_pass_logprobs_through_get_optional_params, which is unpinned and therefore reads the published map: passes on base, failed on the previous revision, passes now. CI missed it because the outcome depends on whether the remote map fetch succeeds or falls back to the bundled copy.

The fix: an absent declaration only means something once the catalogue carries the key at all. A map predating the feature keeps the old answer; the conservative answer switches on by itself once the data lands. Costs one any() over the map on the fallback path, measured at ~80us worst case.

Also verified while I was in there: azure_ai/gpt-5.4* and the bedrock openai-compat entries are unchanged base vs head, and the merge against current staging is clean with 0 regressions on the merged tree.

@greptileai can you reply here with a score and why that score?

[tin-berri]

bugbot run

[greptile-apps]

Score: 5/5

This revision addresses the regression correctly. The catalogue-version check distinguishes an older map that predates default_reasoning_effort from a current map where an omitted declaration is meaningful, preserving existing behavior for gpt-5.1/5.2/5.4 while conservatively dropping unsupported parameters for undeclared newer models. The shared effort_resolves_to_none predicate is used consistently for temperature and sampling parameters across Chat Completions and Responses, and the Azure lookup normalization keeps all supported routing-name forms aligned.

The added coverage exercises current-map and older-map behavior, explicit versus default effort, Responses, Azure aliases, and model-info hydration. The reported live base-vs-head and merge-ref results provide additional evidence that the prior regression is gone. I see no remaining merge-blocking correctness issue.

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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

[tin-berri]

Filed LIT-6355 for the originally reported symptom (case study section 7.2: shadow-eval judge returning judged_count: 0 / error_count: 167) and linked it above. It sits alongside LIT-3797 and LIT-5028, which are the same root cause reaching two other surfaces.

On the red codecov/patch: the new lines are covered. Measured locally over the two gpt-5 transformation files, 92% with 14 uncovered lines, and none of them are from this change:

litellm/llms/azure/chat/gpt_5_transformation.py    50   2   96%   110, 134
litellm/llms/openai/chat/gpt_5_transformation.py  130  12   91%   40, 42, 45, 61, 118-119, 127-132

Those are the pre-existing _get_effort_level / _normalize_reasoning_effort_for_chat_completion branches and is_model_gpt_5_4_model / is_model_gpt_5_4_plus_model. The new _catalogue_declares_default_effort (line 15) and its call site (line 184) are both covered, and removing the guard fails 6 of the 7 new tests.

Codecov reported 92.50% on the two previous shas of this PR and 21.42% on this one. The only difference is that this push inserted a function near the top of gpt_5_transformation.py, shifting every subsequent line. codecov.yaml documents that exact failure mode in its individual_flags comment: carried-forward sessions "were measured against old revisions, and the stale line maps mark comment lines of since-edited files as missed, sinking patch coverage on unrelated PRs". I am flagging rather than asserting it, since every other open PR is currently green on this check, so if a reviewer would rather I chase it further I will.

[mateo-berri]

@greptileai

[mateo-berri]

LGTM. Thanks!