feat(gpt-5): Add supports_none_reasoning_effort and supports_xhigh_reasoning_effort to model cost map

[Sameerlite]

Summary

Shifts GPT-5 reasoning effort detection from hardcoded model checks to dynamic lookup via the model cost map.

Changes

• Model cost map: Add supports_none_reasoning_effort and supports_xhigh_reasoning_effort to all GPT-5 model entries
• OpenAI transformation: Replace is_model_gpt_5_1_model, is_model_gpt_5_1_codex_max_model with _supports_reasoning_effort_level() using _supports_factory
• Azure transformation: Use _supports_reasoning_effort_level for reasoning_effort='none' and logprobs logic
• Types: Add new fields to ProviderSpecificModelInfo in litellm/types/utils.py
• Tests: Update test_gpt5_1_model_detection to assert model map lookup behavior

Models affected

• supports_none_reasoning_effort=true: gpt-5.1, gpt-5.1-2025-11-13, gpt-5.1-chat-latest, gpt-5.2, gpt-5.2-2025-12-11, gpt-5.4, gpt-5.4-2026-03-05
• supports_xhigh_reasoning_effort=true: gpt-5.1-codex-max, gpt-5.2, gpt-5.2-2025-12-11, gpt-5.2-pro, gpt-5.2-pro-2025-12-11, gpt-5.2-codex, gpt-5.4, gpt-5.4-2026-03-05

Testing

LITELLM_LOCAL_MODEL_COST_MAP=True poetry run pytest tests/test_litellm/llms/openai/test_gpt5_transformation.py -v

All 44 tests pass.

Made with Cursor

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 6, 2026 0:47am

[greptile-apps]

Greptile Summary

This PR replaces hardcoded model-name checks (is_model_gpt_5_1_model, is_model_gpt_5_1_codex_max_model) with a dynamic model-cost-map lookup via _supports_factory, adding supports_none_reasoning_effort and supports_xhigh_reasoning_effort flags to the GPT-5 model entries. The approach is architecturally sound and aligns with the project's convention of encoding capabilities in the model map rather than in code.

However, two issues need to be addressed before merging:

• Critical data loss: In model_prices_and_context_window.json (the main file), supports_web_search: true was accidentally replaced instead of supplemented for gpt-5.1, gpt-5.1-2025-11-13, and gpt-5.1-chat-latest. The backup file was edited correctly. This will silently break web-search capability detection for these models.
• Azure routing regression: The new _supports_reasoning_effort_level helper does not strip provider/routing prefixes (e.g. gpt5_series/gpt-5.1) before calling _supports_factory, unlike the old methods which used model.split("/")[-1]. Models routed via the gpt5_series/ Azure prefix will have the capability lookup silently return False, causing unexpected errors or parameter drops for reasoning effort on those deployments.
• Minor test coverage drop: gpt-5.3-chat-latest was removed from test_gpt5_2_chat_temperature_restricted without explanation, reducing regression coverage for that model.

Confidence Score: 2/5

• Not safe to merge — contains a data-loss regression in the main model cost map and a behavioral regression for Azure gpt5_series/ routing.
• The architectural direction is correct and aligns with project conventions. However, the accidental removal of supports_web_search: true from three gpt-5.1 model entries in the primary JSON file is a clear regression that would silently break web-search capability detection. Additionally, the new lookup helper can return incorrect results for Azure models using the gpt5_series/ routing prefix. These two issues prevent a safe merge.
• model_prices_and_context_window.json (web search field dropped for gpt-5.1 entries) and litellm/llms/openai/chat/gpt_5_transformation.py (prefix stripping in _supports_reasoning_effort_level).

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Critical regression: supports_web_search: true was accidentally removed from gpt-5.1, gpt-5.1-2025-11-13, and gpt-5.1-chat-latest when adding the new reasoning-effort flags. The backup file has the correct edit; the main file does not.
litellm/model_prices_and_context_window_backup.json	Correctly adds supports_none_reasoning_effort and supports_xhigh_reasoning_effort to all GPT-5 model entries without accidentally removing any existing fields.
litellm/llms/openai/chat/gpt_5_transformation.py	Good refactor replacing hardcoded model-name checks with a dynamic model-map lookup via _supports_factory. However, the new helper doesn't strip provider/routing prefixes (e.g. gpt5_series/) before calling _supports_factory, which can silently return False for valid Azure-routed models.
litellm/llms/azure/chat/gpt_5_transformation.py	Correctly replaces is_model_gpt_5_1_model with _supports_reasoning_effort_level, but inherits the prefix-stripping gap from the OpenAI class — Azure deployment names passed with the gpt5_series/ prefix won't resolve correctly in the model map.
litellm/types/utils.py	Clean addition of supports_none_reasoning_effort and supports_xhigh_reasoning_effort as optional bool fields to ProviderSpecificModelInfo.
tests/test_litellm/llms/openai/test_gpt5_transformation.py	Tests are updated to reflect the new model-map-based detection. However, gpt-5.3-chat-latest is silently dropped from the temperature-restriction test loop, reducing regression coverage.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User calls with model + reasoning_effort] --> B{Is model GPT-5?}
    B -- No --> C[Standard path]
    B -- Yes --> D[_supports_reasoning_effort_level]
    D --> E[_supports_factory]
    E --> F[litellm.get_llm_provider]
    F --> G{Provider resolved?}
    G -- "openai/azure (normal model name)" --> H[_get_model_info_helper]
    G -- "gpt5_series/ prefix (unrecognized)" --> I[Exception → returns False ⚠️]
    H --> J{Key in model_cost?}
    J -- Yes --> K[Return flag value]
    J -- No --> L[Bare model key fallback]
    L --> M[Return flag or False]
    K --> N{supports_none?}
    M --> N
    N -- True --> O[Allow flexible temperature\nAllow logprobs\nAllow reasoning_effort=none]
    N -- False --> P[Drop or raise UnsupportedParamsError]
    D2[supports_xhigh check] --> E2[_supports_factory]
    E2 --> Q{Model in map with xhigh=true?}
    Q -- Yes --> R[Allow reasoning_effort=xhigh]
    Q -- No --> S[Drop or raise error]

Loading

Comments Outside Diff (3)

1. model_prices_and_context_window.json, line 514-516 (link)

   supports_web_search accidentally removed from gpt-5.1 entries

   When adding the new supports_none_reasoning_effort / supports_xhigh_reasoning_effort fields, the existing "supports_web_search": true property was dropped for gpt-5.1, gpt-5.1-2025-11-13, and gpt-5.1-chat-latest. Contrast with the backup file where the same edit was done correctly (the new keys were appended without touching supports_web_search).

   Affected entries (all in model_prices_and_context_window.json):

   • gpt-5.1 (~line 514)
   • gpt-5.1-2025-11-13 (~line 524)
   • gpt-5.1-chat-latest (~line 534)

   The diff for gpt-5.1 shows:

   -        "supports_web_search": true
   +        "supports_none_reasoning_effort": true,
   +        "supports_xhigh_reasoning_effort": false

   supports_web_search: true needs to be kept alongside the new keys:

2. tests/test_litellm/llms/openai/test_gpt5_transformation.py, line 922-923 (link)

   gpt-5.3-chat-latest silently dropped from temperature-restriction test

   gpt-5.3-chat-latest was removed from the loop without explanation. The model map entry for gpt-5.3-chat-latest has supports_none_reasoning_effort: false, so strict temperature behavior (temperature != 1 → UnsupportedParamsError) should still apply — yet the test no longer verifies this. Removing it reduces regression coverage for that model and makes it harder to catch future accidental relaxations.

   Consider keeping gpt-5.3-chat-latest in the loop or adding a comment explaining why its behavior is now covered elsewhere.

3. litellm/llms/openai/chat/gpt_5_transformation.py, line 58-62 (link)

   gpt5_series/ prefix not stripped before model map lookup

   The removed helpers (is_model_gpt_5_1_model, is_model_gpt_5_1_codex_max_model) all did model.split("/")[-1] to handle provider-prefixed model strings. The new _supports_reasoning_effort_level passes the raw model value directly to _supports_factory, which in turn calls litellm.get_llm_provider(model=model, ...).

   In the Azure layer (AzureOpenAIGPT5Config), the model string can arrive with a gpt5_series/ prefix (e.g. gpt5_series/gpt-5.1) because transform_request is the only method that strips it — get_supported_openai_params and map_openai_params do not. Since gpt5_series is not a recognized LiteLLM provider, get_llm_provider will either raise (caught by the try/except and returns False) or resolve to a provider with no matching cost entry. Either way, _supports_reasoning_effort_level silently returns False for any gpt5_series/-prefixed model.

   The regression: on Azure, models routed via the gpt5_series/ prefix will no longer have reasoning_effort='none' or 'xhigh' recognized, causing unexpected errors or silent parameter drops.

   Consider normalizing the model name before calling _supports_factory (extracting only the last path segment, just like the old helpers did) to fix this.

_{Last reviewed commit: 6ba2e9f}