litellm - ✅(Solved) Fix Responses API bridge drops tool_choice when routing chat completions through openai/responses/ prefix [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#23423Fetched 2026-04-08 00:36:55
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
Participants
Timeline (top)
referenced ×3cross-referenced ×2closed ×1labeled ×1

Root Cause

tool_choice is missing from the supported params list for the openai/responses/ chat completion bridge path.

In get_optional_params(), get_supported_openai_params(model="openai/responses/gpt-5.4", custom_llm_provider="openai") returns a list that includes tools but not tool_choice. This causes _check_valid_arg to either raise UnsupportedParamsError or silently drop the param (when drop_params=True).

The Responses API itself does support tool_choice — it's defined in ResponsesAPIOptionalRequestParams and handled correctly by LiteLLMCompletionResponsesConfig._transform_tool_choice(). The issue is that the chat completions → responses bridge validation rejects it before it can reach that code.

Verified on litellm 1.82.0:

from litellm.utils import get_supported_openai_params

params = get_supported_openai_params(
    model="openai/responses/gpt-5.4", 
    custom_llm_provider="openai"
)
print("tool_choice" in params)  # False
print("tools" in params)        # True

Fix Action

Fixed

PR fix notes

PR #23604: fix(openai): resolve capability lookups for responses/ prefix models

Description (problem / solution / changelog)

Relevant issues

Fixes #23423

Pre-Submission checklist

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Type

🐛 Bug Fix

Changes

When using the openai/responses/ prefix (e.g. openai/responses/gpt-5.4), get_llm_provider() returns model="responses/gpt-5.4". Capability lookup functions like supports_tool_choice() then fail to find this in the model cost map (which only has gpt-5.4), incorrectly returning False and silently dropping tool_choice from the request.

Fix: Strip the responses/ prefix in _supports_factory() before the model info lookup, so all supports_* functions resolve correctly for Responses API models.

Test: Added assertions in test_supports_tool_choice_simple_tests for both openai/responses/gpt-5.4 and responses/gpt-5.4 with explicit provider.

Changed files

  • litellm/utils.py (modified, +6/-0)
  • tests/test_litellm/test_utils.py (modified, +4/-0)

Code Example

import litellm

response = await litellm.acompletion(
    model="openai/responses/gpt-5.4",
    messages=[{"role": "user", "content": "Search the web for today's news"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "Search the web",
            "parameters": {
                "type": "object",
                "properties": {"query": {"type": "string"}},
                "required": ["query"],
            },
        },
    }],
    tool_choice={"type": "function", "function": {"name": "web_search"}},
    stream=True,
)

---

from litellm.utils import get_supported_openai_params

params = get_supported_openai_params(
    model="openai/responses/gpt-5.4", 
    custom_llm_provider="openai"
)
print("tool_choice" in params)  # False
print("tools" in params)        # True
RAW_BUFFERClick to expand / collapse

Bug Description

When calling litellm.acompletion() with tool_choice and a model using the openai/responses/ prefix (e.g., openai/responses/gpt-5.4), the tool_choice parameter is silently dropped and never reaches the underlying API call.

Steps to Reproduce

import litellm

response = await litellm.acompletion(
    model="openai/responses/gpt-5.4",
    messages=[{"role": "user", "content": "Search the web for today's news"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "Search the web",
            "parameters": {
                "type": "object",
                "properties": {"query": {"type": "string"}},
                "required": ["query"],
            },
        },
    }],
    tool_choice={"type": "function", "function": {"name": "web_search"}},
    stream=True,
)

Expected: The model is forced to call web_search.
Actual: The model ignores tool_choice and may call other tools or generate text directly.

Root Cause

tool_choice is missing from the supported params list for the openai/responses/ chat completion bridge path.

In get_optional_params(), get_supported_openai_params(model="openai/responses/gpt-5.4", custom_llm_provider="openai") returns a list that includes tools but not tool_choice. This causes _check_valid_arg to either raise UnsupportedParamsError or silently drop the param (when drop_params=True).

The Responses API itself does support tool_choice — it's defined in ResponsesAPIOptionalRequestParams and handled correctly by LiteLLMCompletionResponsesConfig._transform_tool_choice(). The issue is that the chat completions → responses bridge validation rejects it before it can reach that code.

Verified on litellm 1.82.0:

from litellm.utils import get_supported_openai_params

params = get_supported_openai_params(
    model="openai/responses/gpt-5.4", 
    custom_llm_provider="openai"
)
print("tool_choice" in params)  # False
print("tools" in params)        # True

Suggested Fix

Add tool_choice to the supported params list returned for models using the openai/responses/ bridge path, so that it flows through optional_params_map_optional_params_to_responses_api_requestresponses_api_request["tool_choice"] → the actual API call.

Environment

  • litellm version: 1.82.0
  • Python: 3.12

extent analysis

Fix Plan

To fix the issue, we need to add tool_choice to the supported parameters list for the openai/responses/ bridge path.

Here are the steps:

  • Modify the get_supported_openai_params function to include tool_choice for models using the openai/responses/ prefix.
  • Update the get_optional_params function to handle tool_choice correctly.

Example code:

def get_supported_openai_params(model, custom_llm_provider):
    # ... existing code ...
    if model.startswith("openai/responses/"):
        supported_params = ["tools", "tool_choice"]  # Add tool_choice here
    # ... existing code ...
    return supported_params

Verification

To verify the fix, you can use the following code:

from litellm.utils import get_supported_openai_params

params = get_supported_openai_params(
    model="openai/responses/gpt-5.4", 
    custom_llm_provider="openai"
)
print("tool_choice" in params)  # Should print: True
print("tools" in params)        # Should print: True

Then, test the litellm.acompletion function with the tool_choice parameter to ensure it is no longer silently dropped.

Extra Tips

  • Make sure to update the documentation to reflect the addition of tool_choice as a supported parameter for the openai/responses/ bridge path.
  • Consider adding tests to ensure that tool_choice is correctly handled for models using the openai/responses/ prefix.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING