6 views
-/https://github.com/berriai/litellm/issues/32214
GitHub · issue

#32214 [Bug]: sanitize_tool_use_ids_in_anthropic_messages breaks multi-turn tool-use on vLLM/Kimi K2.7 pass-through (v1.91.0 regression)

  • State: open
  • Author: @rikki
  • Labels: proxy, llm translation, claude code

## What happened?

On LiteLLM v1.91.0, routing `/v1/messages` (Anthropic-format) traffic to a vLLM backend running Kimi K2.7 (via `custom_llm_provider: anthropic` with `extra_headers.Authorization` pointing at the vLLM endpoint), Claude Code agentic skill workflows that involve multi-turn tool calls silently break: on a specific turn (reproducibly around the 5th-6th tool round), the model emits only a thinking block plus an empty text response with `stop_reason: end_turn` and no `tool_use` block. Claude Code sees the empty response and the skill halts.

The regression was introduced by commit `8bca05d311` (`fix(anthropic): sanitize tool_use ids on native /v1/messages path`, #31094, released in v1.91.0). That commit adds `sanitize_tool_use_ids_in_anthropic_messages`, which rewrites every `tool_use.id` and `tool_result.tool_use_id` in the request history via `re.sub(r"[^a-zA-Z0-9_-]", "_", ...)`. vLLM/Kimi K2.7 natively generates tool_use ids of the form `functions.Bash:0` (containing `.` and `:`), which get rewritten to `functions_Bash_0`. Kimi K2.7's chat template renders the historical `tool_call.id` verbatim into the prompt (`<|tool_call_begin|>{{ formatted_id }}<|tool_call_argum…

GitHub resolver

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

Refresh page
vote history (3 events)
#0 of 0 · 31d18h36m41s ago — entered · #import:https:::github.com:berriai:litellm post #2444
The left issue is harder because it involves preserving cross-turn protocol identity across provider-specific translation and requires broader compatibility testing. The right issue appears more localized to request-mode propagation and response handling, with a narrower regression surface.
The right issue is harder because it requires tracing a regression across message normalization, provider-specific identifier constraints, multi-turn state preservation, and compatibility tests, with risk of affecting existing Anthropic integrations. The left issue is comparatively localized: expose provider capability metadata through a small, stable API with focused tests.
#0 of 0 · 31d17h57m35s ago — current · #import:https:::github.com:berriai:litellm post #3120
The right issue is harder because it requires diagnosing and safely correcting provider-specific message translation behavior while preserving compatibility across existing Anthropic and tool-calling flows, with regression coverage. The left issue is a more contained SDK feature addition involving endpoint exposure, request/response modeling, and provider wiring.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search