9 views
-/https://github.com/berriai/litellm/issues/32505
GitHub · issue

#32505 fix(anthropic_responses): translate_tool_choice_to_responses_api returns invalid objects instead of string literals

  • State: open
  • Author: @kvncrw
  • Labels: llm translation

## Bug

`translate_tool_choice_to_responses_api` in the Anthropic→Responses API adapter returns `{"type": "auto"}` and `{"type": "required"}` (object form) where the OpenAI Responses API requires string literals `"auto"` and `"required"`. This causes 400/422 errors from vLLM (and potentially other OpenAI-compatible backends) when an Anthropic `/v1/messages` client sends `tool_choice` and the request is routed through the Responses API path.

## What happened

LiteLLM v1.91.0 proxy receiving Anthropic `/v1/messages` requests for an `openai/`-provider model (e.g. vLLM backend) routes through the Responses API adapter (`litellm/llms/anthropic/experimental_pass_through/responses_adapters/`). The `tool_choice` translation produces invalid objects:

| Anthropic `tool_choice` | Current output (broken) | Correct output | |---|---|---| | `{"type": "auto"}` | `{"type": "auto"}` | `"auto"` | | `{"type": "any"}` | `{"type": "required"}` | `"required"` | | `{"type": "none"}` | `{"type": "auto"}` ← **also wrong: enables tools when user asked to disable** | `"none"` | | `{"type": "tool", "name": "foo"}` | `{"type": "function", "name": "foo"}` | `{"type": "function", "name": "foo"}` (correct alrea…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (3 events)
#0 of 0 · 31d18h1m57s ago — entered · #import:https:::github.com:berriai:litellm post #2838
Supporting additional repository providers requires coordinated UI validation, proxy/API handling, authentication, security review, and regression coverage, while the other issue is a localized adapter mapping correction with targeted tests.
The right issue is harder because it requires correcting an adapter’s cross-provider schema translation, preserving nuanced tool-choice semantics, and validating compatibility across request variants and backend behavior. The left issue appears comparatively localized to provider credential recognition in an existing validation path, with narrower testing and regression scope.
#0 of 0 · 31d17h45m7s ago — current · #import:https:::github.com:berriai:litellm post #3136
The right issue is harder because it requires modifying a protocol translation path, validating edge cases across API semantics, and adding regression coverage. The left issue appears largely achievable through existing local-provider support with limited integration and validation work.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search