Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug]: AzureOpenAIGPT5Config._supports_reasoning_effort_level fails for Azure deployment names (e.g. gpt-5.1-DataZoneStandard) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25850•Fetched 2026-04-17 08:28:41
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
hahamark1hahamark1
Participants
hahamark1hahamark1
Timeline (top)
cross-referenced ×1labeled ×1referenced ×1

Error Message

litellm.UnsupportedParamsError: Azure OpenAI does not support reasoning_effort='none' for this model. Supported values are: 'low', 'medium', and 'high'.

Root Cause

AzureOpenAIGPT5Config._supports_reasoning_effort_level normalises the model string and then does a registry lookup:

# azure/chat/gpt_5_transformation.py
@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    if model.startswith(cls.GPT5_SERIES_ROUTE):
        model = "azure/" + model[len(cls.GPT5_SERIES_ROUTE):]
    elif not model.startswith("azure/"):
        model = "azure/" + model
    return super()._supports_reasoning_effort_level(model, level)

For gpt-5.1-DataZoneStandard this produces azure/gpt-5.1-DataZoneStandard. The registry only contains canonical model names like azure/gpt-5.1-2025-11-13, so the lookup returns False and reasoning_effort='none' is rejected.

This is a regression from 1.81.x, which used a simple model_name.startswith("gpt-5.1") check that correctly handled any deployment name containing gpt-5.1.

Fix Action

Fixed

PR fix notes

PR #25911: fix: add fallback for Azure deployment names in _supports_reasoning_effort_level

Description (problem / solution / changelog)

What's broken?

AzureOpenAIGPT5Config._supports_reasoning_effort_level fails for Azure deployment names that don't match entries in the model_prices map (e.g. azure/gpt-5.1-DataZoneStandard), incorrectly rejecting reasoning_effort='none' with UnsupportedParamsError.

Who is affected?

Anyone using Azure OpenAI with custom deployment names for gpt-5.1 or gpt-5.2 models and passing reasoning_effort='none'. Standard canonical model names (e.g. azure/gpt-5.1) are not affected.

Root Cause

The method normalises the model string and does a registry lookup via _supports_factory. Azure deployment names are user-defined (e.g. gpt-5.1-DataZoneStandard) and won't exist in model_prices_and_context_window.json, so the lookup always returns False. This is a regression from 1.81.x which used a simple startswith("gpt-5.1") check.

Fix

Added a string-based fallback in AzureOpenAIGPT5Config._supports_reasoning_effort_level: when the registry lookup returns False, check if the model name starts with a known prefix (gpt-5.1 or gpt-5.2) for level == "none". This restores the 1.81.x behaviour for custom deployment names while preserving the registry-first approach for canonical names.

Testing

  • All 24 existing tests in test_azure_gpt5_transformation.py pass
  • Verified deployment names like azure/gpt-5.1-DataZoneStandard, gpt-5.1-DataZoneStandard, gpt5_series/gpt-5.1-mydeployment, and azure/gpt-5.2-custom correctly return True for level="none"
  • Verified non-matching models (azure/gpt-5, azure/gpt-5-DataZone) still correctly return False

Fixes #25850

Changed files

  • litellm/llms/azure/chat/gpt_5_transformation.py (modified, +14/-1)

Code Example

import litellm

litellm.completion(
    model="azure/gpt-5.1-DataZoneStandard",
    messages=[{"role": "user", "content": "Say hi"}],
    reasoning_effort="none",
    api_base="https://<your-azure-endpoint>.openai.azure.com/",
    azure_ad_token="<token>",
    api_version="2024-12-01-preview",
)

---

litellm.UnsupportedParamsError: Azure OpenAI does not support reasoning_effort='none' for this model.
Supported values are: 'low', 'medium', and 'high'.

---

# azure/chat/gpt_5_transformation.py
@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    if model.startswith(cls.GPT5_SERIES_ROUTE):
        model = "azure/" + model[len(cls.GPT5_SERIES_ROUTE):]
    elif not model.startswith("azure/"):
        model = "azure/" + model
    return super()._supports_reasoning_effort_level(model, level)

---

@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    if model.startswith(cls.GPT5_SERIES_ROUTE):
        model = "azure/" + model[len(cls.GPT5_SERIES_ROUTE):]
    elif not model.startswith("azure/"):
        model = "azure/" + model

    if super()._supports_reasoning_effort_level(model, level):
        return True

    # Fallback: registry lookup fails for deployment names (e.g. gpt-5.1-DataZoneStandard)
    # that are not in model_prices_and_context_window.json. Use string matching as a
    # safe fallback, consistent with the behaviour in 1.81.x.
    model_name = model.split("/")[-1]
    if level == "none":
        return model_name.startswith("gpt-5.1") or model_name.startswith("gpt-5.2")
    return False
RAW_BUFFERClick to expand / collapse

What happened?

In litellm 1.83.0, AzureOpenAIGPT5Config._supports_reasoning_effort_level was introduced to determine whether a model supports reasoning_effort='none'. However, it fails when the model string is an Azure deployment name rather than a canonical model name.

For example, using the model group azure/gpt-5.1-DataZoneStandard (a valid Azure deployment name for the gpt-5.1 model family), the registry lookup finds no entry and returns False, causing litellm to incorrectly raise UnsupportedParamsError even though gpt-5.1 fully supports reasoning_effort='none'.

Steps to reproduce

import litellm

litellm.completion(
    model="azure/gpt-5.1-DataZoneStandard",
    messages=[{"role": "user", "content": "Say hi"}],
    reasoning_effort="none",
    api_base="https://<your-azure-endpoint>.openai.azure.com/",
    azure_ad_token="<token>",
    api_version="2024-12-01-preview",
)

Error:

litellm.UnsupportedParamsError: Azure OpenAI does not support reasoning_effort='none' for this model.
Supported values are: 'low', 'medium', and 'high'.

Root cause

AzureOpenAIGPT5Config._supports_reasoning_effort_level normalises the model string and then does a registry lookup:

# azure/chat/gpt_5_transformation.py
@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    if model.startswith(cls.GPT5_SERIES_ROUTE):
        model = "azure/" + model[len(cls.GPT5_SERIES_ROUTE):]
    elif not model.startswith("azure/"):
        model = "azure/" + model
    return super()._supports_reasoning_effort_level(model, level)

For gpt-5.1-DataZoneStandard this produces azure/gpt-5.1-DataZoneStandard. The registry only contains canonical model names like azure/gpt-5.1-2025-11-13, so the lookup returns False and reasoning_effort='none' is rejected.

This is a regression from 1.81.x, which used a simple model_name.startswith("gpt-5.1") check that correctly handled any deployment name containing gpt-5.1.

Suggested fix

Add a string-based fallback in AzureOpenAIGPT5Config._supports_reasoning_effort_level when the registry lookup returns False:

@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    if model.startswith(cls.GPT5_SERIES_ROUTE):
        model = "azure/" + model[len(cls.GPT5_SERIES_ROUTE):]
    elif not model.startswith("azure/"):
        model = "azure/" + model

    if super()._supports_reasoning_effort_level(model, level):
        return True

    # Fallback: registry lookup fails for deployment names (e.g. gpt-5.1-DataZoneStandard)
    # that are not in model_prices_and_context_window.json. Use string matching as a
    # safe fallback, consistent with the behaviour in 1.81.x.
    model_name = model.split("/")[-1]
    if level == "none":
        return model_name.startswith("gpt-5.1") or model_name.startswith("gpt-5.2")
    return False

Additional context

LiteLLM version

1.83.0

extent analysis

TL;DR

The most likely fix is to modify the AzureOpenAIGPT5Config._supports_reasoning_effort_level method to include a string-based fallback for deployment names.

Guidance

  • Update the AzureOpenAIGPT5Config._supports_reasoning_effort_level method to include a fallback check for deployment names, as suggested in the issue.
  • Verify that the fallback check correctly handles deployment names like gpt-5.1-DataZoneStandard.
  • Test the updated method with different model names and reasoning_effort levels to ensure it returns the correct results.
  • Consider adding additional logging or error handling to handle cases where the registry lookup and fallback check both fail.

Example

@classmethod
def _supports_reasoning_effort_level(cls, model: str, level: str) -> bool:
    # ... (existing code)
    if super()._supports_reasoning_effort_level(model, level):
        return True

    # Fallback: registry lookup fails for deployment names (e.g. gpt-5.1-DataZoneStandard)
    model_name = model.split("/")[-1]
    if level == "none":
        return model_name.startswith("gpt-5.1") or model_name.startswith("gpt-5.2")
    return False

Notes

  • This fix assumes that the model_name can be reliably extracted from the model string and that the fallback check is sufficient to determine support for reasoning_effort='none'.
  • Additional testing and validation may be necessary to ensure the updated method works correctly for all possible model names and reasoning_effort levels.

Recommendation

Apply the suggested fix to the AzureOpenAIGPT5Config._supports_reasoning_effort_level method, as it provides a reliable fallback for deployment names and restores the correct behavior for reasoning_effort='none' support.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING