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

#26241 [Bug]:Anthropic → Responses adapter ignores litellm.drop_params when mapping metadata.user_id to `user` (breaks strict /responses gateways)

  • State: open
  • Author: @sjt-xfwh
  • Labels: bug, llm translation, claude code

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

### Summary

When Claude Code talks to LiteLLM Proxy using the Anthropic `/v1/messages` endpoint and the deployment routes to an **OpenAI Responses API** backend (`openai/...` with `api_base` pointing to a custom gateway), LiteLLM’s `LiteLLMAnthropicToResponsesAPIAdapter.translate_request()` **always** adds a top-level `user` field to the Responses request when the incoming Anthropic request includes `metadata.user_id`.

Some providers (e.g. custom unified gateways) return **400** with a body like `Unsupported parameter: user` for `POST .../v1/responses`.

Setting `litellm_settings.drop_params: true` in the proxy `config.yaml` **does not** prevent this, because the adapter does not check `litellm.drop_params` before setting `responses_kwargs["user"]`. So `drop_params` is effectively ignored on this code path.

### Environment

- LiteLLM: `1.83.11` (uv tool install) - Flow: `POST /v1/messages?beta=true` (Anthropic) → internal `aresponses` → upstream `https://example.com/v1/responses`

### Steps to reproduce

1. Configure a model in `model_list` …

GitHub resolver

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

Refresh page
vote history (2 events)
#0 of 0 · 31d18h59m2s ago — entered · #import:https:::github.com:berriai:litellm post #1889
Issue #26241 is harder because it crosses request translation, parameter-filtering semantics, configuration propagation, and compatibility testing across API paths. Issue #31909 is comparatively localized to nested input normalization and focused regression coverage.
#0 of 0 · 31d18h24m37s ago — current · #import:https:::github.com:berriai:litellm post #2448
The right issue is harder because it crosses adapter configuration behavior, request translation semantics, provider compatibility, and regression-test coverage, while the left is a narrowly scoped protocol-header correction with focused testing.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search