Latest Results
fix(responses): build a Responses-API-shaped tool_choice for ResponsesAPIResponse
ResponsesAPIResponse.tool_choice crashed with 13 Pydantic validation errors
whenever a caller forced a named tool call (tool_choice={"type": "function",
"function": {"name": "..."}}, the Chat Completion shape) through the
litellm_completion Responses API bridge. That field only accepts strings or
the flat Responses API shape ({"type": "function", "name": "..."}), never
the nested Chat Completion dict.
Reproduced against Bedrock/Anthropic models specifically, not because the
bug is model-specific, but because OpenAI/Azure/xAI models get native
Responses API handling that never touches this bridge, while Bedrock/
Anthropic models always fall back to it (no responses_api_provider_config
exists for that provider). Any forced named tool call against a Claude
model on Bedrock reproduces this identically, regardless of which Claude
variant.
Root cause: both the streaming _default_response_created_event_data and the
non-streaming transform_chat_completion_response_to_responses_api_response
reused the Chat-Completion-shaped value from _transform_tool_choice (which
builds the outbound provider request) to also populate the inbound
ResponsesAPIResponse.tool_choice field. That function's docstring says it
"passes through as-is" for the OpenAI dict format - correct for the outbound
request, wrong for the Responses API response shape.
Adds _transform_tool_choice_for_responses_api_response, which rewrites the
Chat Completion nested shape to the flat Responses API shape, and uses it at
both call sites instead of reusing the Chat-Completion-shaped value.TobiMayr:fix/responses-api-tool-choice-validation Latest Branches
0%
madan-singulr:m.singulr.25jun 0%
TobiMayr:fix/responses-api-tool-choice-validation 0%
axelray-dev:litellm_fix_anthropic_adaptive_temp_33203 © 2026 CodSpeed Technology