8 views
-/https://github.com/berriai/litellm/issues/33448
GitHub · issue

#33448 [Bug]: Responses WebSocket drops deployment-level default request parameters

  • State: open
  • Author: @jimmychen-p72
  • Labels: llm translation

## Bug

Responses WebSocket mode does not apply deployment-level default request parameters when forwarding a `response.create` frame to a native provider WebSocket.

A router deployment configured with `reasoning_effort: high` selects the correct deployment, but because the client frame omits `reasoning`, the provider receives its default (`medium`) and rejects GPT-5 Pro, which only permits `high`. The equivalent HTTP Responses request succeeds because router deployment defaults are merged into the request.

## Reproduction

Configure a proxy model with a deployment-level default:

```yaml model_list: - model_name: gpt-5-pro litellm_params: model: azure/gpt-5-pro api_base: os.environ/AZURE_API_BASE api_key: os.environ/AZURE_API_KEY reasoning_effort: high ```

Connect to the Responses WebSocket endpoint and send a normal frame without an explicit `reasoning` block:

```json { "type": "response.create", "model": "gpt-5-pro", "store": false, "input": "Say hello", "tools": [] } ```

The proxy selects the configured deployment, but the provider returns:

```json { "type": "error", "status": 400, "error": { "type": "invalid_request_error…

GitHub resolver

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

Refresh page
vote history (1 events)
#0 of 0 · 31d17h53m38s ago — entered · #import:https:::github.com:berriai:litellm post #2958
The left requires coordinating request-default propagation across a stateful WebSocket translation path, provider forwarding, and regression coverage; the right is comparatively localized matching logic with focused tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search