litellm - ✅(Solved) Fix [Bug]:Anthropic → Responses adapter ignores litellm.drop_params when mapping metadata.user_id to `user` (breaks strict /responses gateways) [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#26241Fetched 2026-04-23 07:24:23
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×3cross-referenced ×1

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.

Root Cause

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.

Fix Action

Fixed

PR fix notes

PR #26243: fix: respect drop_params when mapping metadata.user_id to user in Responses adapter

Description (problem / solution / changelog)

Summary

When litellm.drop_params is True, the Anthropic → Responses API adapter was still unconditionally setting responses_kwargs["user"] from metadata.user_id, causing 400 errors on strict gateways that reject the user field.

Root cause: translate_request() in responses_adapters/transformation.py did not check litellm.drop_params before mapping metadata.user_id → user.

Fix: Guard the assignment behind a drop_params check — one line change.

# before
if isinstance(metadata, dict) and "user_id" in metadata:
    responses_kwargs["user"] = str(metadata["user_id"])[:64]

# after
if isinstance(metadata, dict) and "user_id" in metadata:
    if not litellm.drop_params:
        responses_kwargs["user"] = str(metadata["user_id"])[:64]

Tests

Added 3 unit tests to the existing TestDropParamsMetadataUserId class:

  • test_user_field_set_when_drop_params_false — user is included when drop_params=False
  • test_user_field_omitted_when_drop_params_true — user is omitted when drop_params=True
  • test_no_metadata_no_user_field — no metadata → no user field regardless

Fixes #26241

Changed files

  • litellm/llms/anthropic/experimental_pass_through/responses_adapters/transformation.py (modified, +4/-1)
  • tests/test_litellm/llms/anthropic/experimental_pass_through/responses_adapters/test_responses_adapters_transformation.py (modified, +48/-1)

Code Example

# metadata user_id -> user
metadata = anthropic_request.get("metadata")
if isinstance(metadata, dict) and "user_id" in metadata:
    responses_kwargs["user"] = str(metadata["user_id"])[:64]


### 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` that maps Claude client model names to `openai/<model>` with `api_base` set to a gateway whose Responses API rejects the `user` parameter.
2. Ensure `litellm_settings.drop_params: true`.
3. Send Anthropic-format requests that include `metadata.user_id` (typical for Claude Code).
4. Observe upstream **400**: `Unsupported parameter: user`.

### Expected behavior

When `litellm.drop_params` is `True`, LiteLLM should omit the `user` field from the outgoing Responses API payload if the deployment/gateway does not accept it—or at minimum, **respect `drop_params`** in the Anthropic→Responses adapter the same way other call paths document.

Reference: [Drop unsupported params](https://docs.litellm.ai/docs/completion/drop_params) (proxy: `litellm_settings.drop_params`).

### Actual behavior

`responses_kwargs["user"]` is always set from `metadata.user_id` regardless of `litellm.drop_params`.

### Root cause (code location)

File (approximate path in site-packages):

`litellm/llms/anthropic/experimental_pass_through/responses_adapters/transformation.py`

Method: `LiteLLMAnthropicToResponsesAPIAdapter.translate_request`

Current logic (conceptually, near end of method):

---
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • 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 that maps Claude client model names to openai/<model> with api_base set to a gateway whose Responses API rejects the user parameter.
  2. Ensure litellm_settings.drop_params: true.
  3. Send Anthropic-format requests that include metadata.user_id (typical for Claude Code).
  4. Observe upstream 400: Unsupported parameter: user.

Expected behavior

When litellm.drop_params is True, LiteLLM should omit the user field from the outgoing Responses API payload if the deployment/gateway does not accept it—or at minimum, respect drop_params in the Anthropic→Responses adapter the same way other call paths document.

Reference: Drop unsupported params (proxy: litellm_settings.drop_params).

Actual behavior

responses_kwargs["user"] is always set from metadata.user_id regardless of litellm.drop_params.

Root cause (code location)

File (approximate path in site-packages):

litellm/llms/anthropic/experimental_pass_through/responses_adapters/transformation.py

Method: LiteLLMAnthropicToResponsesAPIAdapter.translate_request

Current logic (conceptually, near end of method):

# metadata user_id -> user
metadata = anthropic_request.get("metadata")
if isinstance(metadata, dict) and "user_id" in metadata:
    responses_kwargs["user"] = str(metadata["user_id"])[:64]


### 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` that maps Claude client model names to `openai/<model>` with `api_base` set to a gateway whose Responses API rejects the `user` parameter.
2. Ensure `litellm_settings.drop_params: true`.
3. Send Anthropic-format requests that include `metadata.user_id` (typical for Claude Code).
4. Observe upstream **400**: `Unsupported parameter: user`.

### Expected behavior

When `litellm.drop_params` is `True`, LiteLLM should omit the `user` field from the outgoing Responses API payload if the deployment/gateway does not accept it—or at minimum, **respect `drop_params`** in the Anthropic→Responses adapter the same way other call paths document.

Reference: [Drop unsupported params](https://docs.litellm.ai/docs/completion/drop_params) (proxy: `litellm_settings.drop_params`).

### Actual behavior

`responses_kwargs["user"]` is always set from `metadata.user_id` regardless of `litellm.drop_params`.

### Root cause (code location)

File (approximate path in site-packages):

`litellm/llms/anthropic/experimental_pass_through/responses_adapters/transformation.py`

Method: `LiteLLMAnthropicToResponsesAPIAdapter.translate_request`

Current logic (conceptually, near end of method):

```python
# metadata user_id -> user
metadata = anthropic_request.get("metadata")
if isinstance(metadata, dict) and "user_id" in metadata:
    responses_kwargs["user"] = str(metadata["user_id"])[:64]

### Steps to Reproduce

1. 
2. 
3. 


### Relevant log output

```shell

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

1.83.11

Twitter / LinkedIn details

No response

extent analysis

TL;DR

The most likely fix is to modify the LiteLLMAnthropicToResponsesAPIAdapter.translate_request() method to respect the litellm.drop_params setting and omit the user field when it is True.

Guidance

  • Check the litellm_settings.drop_params value in the proxy config.yaml to ensure it is set to true.
  • Modify the LiteLLMAnthropicToResponsesAPIAdapter.translate_request() method to check the litellm.drop_params value before setting responses_kwargs["user"].
  • If litellm.drop_params is True, omit the user field from the outgoing Responses API payload.
  • Verify that the upstream API no longer returns a 400 error with an Unsupported parameter: user message.

Example

# metadata user_id -> user
metadata = anthropic_request.get("metadata")
if isinstance(metadata, dict) and "user_id" in metadata:
    if not litellm_settings.drop_params:
        responses_kwargs["user"] = str(metadata["user_id"])[:64]

Notes

This fix assumes that the litellm_settings.drop_params value is correctly propagated to the LiteLLMAnthropicToResponsesAPIAdapter.translate_request() method. If this is not the case, additional modifications may be necessary to ensure that the drop_params setting is respected.

Recommendation

Apply the workaround by modifying the LiteLLMAnthropicToResponsesAPIAdapter.translate_request() method to respect the litellm.drop_params setting. This will allow the LiteLLM proxy to omit the user field when the upstream API does not support it, preventing the 400 error.

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…

FAQ

Expected behavior

When litellm.drop_params is True, LiteLLM should omit the user field from the outgoing Responses API payload if the deployment/gateway does not accept it—or at minimum, respect drop_params in the Anthropic→Responses adapter the same way other call paths document.

Reference: Drop unsupported params (proxy: litellm_settings.drop_params).

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Bug]:Anthropic → Responses adapter ignores litellm.drop_params when mapping metadata.user_id to `user` (breaks strict /responses gateways) [1 pull requests, 1 participants]