Forward custom_llm_provider through the Responses API bridge (Fixes #28505)

[Cyberfilo]

Relevant issues

Fixes #28505.

Pre-Submission checklist

• Added testing in `tests/test_litellm/` — `tests/test_litellm/completion_extras/test_responses_bridge_provider_propagation.py` (2 cases, both pass).
• My PR passes all unit tests on `make test-unit`.
• My PR's scope is as isolated as possible — adds `custom_llm_provider=custom_llm_provider` kwarg to two call sites.
• Greptile review pending — will comment `@greptileai` after open.

Type

🐛 Bug Fix

Changes

When a Chat Completions request to a GPT-5.4+ model contains both `tools` and `reasoning_effort`, `completion()` auto-routes through `responses_api_bridge`. The bridge handler called `litellm.responses()` / `litellm.aresponses()` without forwarding the already-resolved `custom_llm_provider`, so the downstream call re-invoked `get_llm_provider()` with `custom_llm_provider=None` and stripped a second provider prefix from a `provider/provider/model` deployment string.

For a deployment configured as `model: "openai/openai/openai/gpt-5.5"`:

Flow	Outgoing model	Result
Normal Chat Completions (no bridge)	`openai/openai/gpt-5.5`	✅ Correct
Bridge flow (`tools` + `reasoning_effort`)	`openai/gpt-5.5`	❌ Wrong — one prefix dropped

Upstream APIs that enforce model-name allow-lists rejected this as `key_model_access_denied`.

Fix

Pass the locally-resolved `custom_llm_provider` into both the sync `responses()` and async `aresponses()` calls in `ResponsesToCompletionBridgeHandler` (`litellm/completion_extras/litellm_responses_transformation/handler.py`). The downstream `_resolve_model_provider_for_responses` then sees an explicit provider and skips the second prefix-strip in `get_llm_provider_logic.py`.

Test plan

```sh
$ python -m pytest tests/test_litellm/completion_extras/test_responses_bridge_provider_propagation.py -v
...
============================== 2 passed in 0.14s ===============================
```

Each test patches `litellm.responses` / `litellm.aresponses`, drives the bridge handler with a `provider/provider/provider/model` deployment string + `custom_llm_provider="openai"`, and asserts the kwarg makes it through.

Black + ruff clean. Diff: 8 lines added across the handler (4 lines of comment + 1 kwarg per call site × 2 call sites) + 100 lines of new test.

[Cyberfilo]

@greptileai

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR fixes a double-prefix-strip bug in ResponsesToCompletionBridgeHandler where custom_llm_provider was not forwarded to the downstream responses()/aresponses() calls, causing get_llm_provider() to re-parse the model string and drop a provider prefix on every bridged request.

• Handler fix (handler.py): request_data[\"custom_llm_provider\"] = custom_llm_provider is now set on the dict before **request_data is spread into both the sync and async call sites, correctly overwriting any existing value carried through sanitized_litellm_params without creating a duplicate-keyword TypeError.
• Tests (test_responses_bridge_provider_propagation.py): Two new mock-only regression tests cover the sync and async paths; the mock's transform_request return value seeds custom_llm_provider: \"should-be-overwritten\" to verify the overwrite behavior (matching the production path where _build_sanitized_litellm_params already places the key in request_data).

Confidence Score: 5/5

Safe to merge — the change is minimal, well-targeted, and the previously identified crash path has been correctly addressed in this revision.

Both call sites now mutate request_data before spreading it, which correctly overrides any pre-existing custom_llm_provider value without introducing a duplicate-keyword error. The tests have been updated to seed custom_llm_provider in the mocked transform_request return value, mirroring the production code path and exercising the overwrite behaviour. No new issues were found.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/completion_extras/litellm_responses_transformation/handler.py	Correctly pins custom_llm_provider in request_data before spreading into responses()/aresponses(), avoiding both the original double-strip bug and the previously-flagged duplicate-kwarg TypeError.
tests/test_litellm/completion_extras/test_responses_bridge_provider_propagation.py	New regression tests covering sync and async bridge paths; mock now seeds custom_llm_provider in transform_request return value to exercise the overwrite (not just the add) behavior, directly addressing prior review feedback.
tests/test_litellm/completion_extras/init.py	Empty init file added to make the new test directory a proper Python package.

_{Reviews (6): Last reviewed commit: "chore: trigger shin-agent re-eval agains..." | Re-trigger Greptile}

[oss-pr-review-agent-shin]

🤖 litellm-agent: This PR is currently BLOCKED from merge.

Score: 2/5 ❌

Why blocked:

• 1 PR-related CI failure (Greptile gate: score 2/5 below required 4/5 — request a Greptile review (@greptileai) and resolve its comments before maintainer review.) (pr_related_failures, -2 pts)
• Greptile 2/5 (greptile_low, -1 pts)

Details: Score docked for: 1 PR-related CI failure (Greptile gate: score 2/5 below required 4/5 — request a Greptile review (@greptileai) and resolve its comments before maintainer review.); Greptile 2/5.

Fix the issues above and push an update — the bot will re-review automatically.

Note: This bot is still in beta and might not always work as expected. Please share any feedback via Slack.

[greptile-apps]

Greptile Summary

This PR forwards the already-resolved custom_llm_provider into both the sync responses() and async aresponses() calls inside ResponsesToCompletionBridgeHandler to prevent a second get_llm_provider() invocation from stripping an extra provider prefix off deployments that carry repeated prefixes like openai/openai/openai/gpt-5.5.

• handler.py: Adds custom_llm_provider=custom_llm_provider as an explicit keyword argument to both call sites. The approach conflicts with custom_llm_provider already present in request_data — _build_sanitized_litellm_params retains it from the litellm_params dict (which get_litellm_params() in main.py always populates), so Python raises TypeError: got multiple values for keyword argument 'custom_llm_provider' on any production bridge call.
• Tests: Two new mock-only unit tests verify the kwarg is forwarded, but both stub transform_request with a bare dict and use litellm_params: {}, so the duplicate-kwarg scenario is never reached.

Confidence Score: 2/5

Not safe to merge as written — the explicit custom_llm_provider kwarg conflicts with the same key already spread into request_data from litellm_params, raising a runtime TypeError on every bridge call through the normal completion() path.

The handler spreads sanitized_litellm_params (which always carries custom_llm_provider from get_litellm_params()) into request_data, then the new explicit kwarg attempts to pass the same name a second time. Python raises TypeError before the call executes. The unit tests avoid this by mocking transform_request with a minimal dict and an empty litellm_params, so the conflict is invisible in tests but surfaces on every real request through this bridge path.

litellm/completion_extras/litellm_responses_transformation/handler.py — both call sites need a different injection strategy (e.g. request_data["custom_llm_provider"] = custom_llm_provider before the call) to avoid the duplicate-keyword error.

Important Files Changed

Filename	Overview
litellm/completion_extras/litellm_responses_transformation/handler.py	Adds explicit custom_llm_provider forwarding to both sync and async responses() calls, but introduces a TypeError because request_data already contains custom_llm_provider from sanitized_litellm_params spread in transform_request.
tests/test_litellm/completion_extras/test_responses_bridge_provider_propagation.py	New regression tests for provider propagation through the bridge; both tests mock transform_request to return a minimal dict without custom_llm_provider and use litellm_params: {}, so they do not exercise the production code path that causes the duplicate-kwarg conflict.
tests/test_litellm/completion_extras/init.py	Empty __init__.py added to make the new test directory a Python package.

_{Reviews (2): Last reviewed commit: "Forward custom_llm_provider through the ..." | Re-trigger Greptile}

[Cyberfilo]

Pushed fix for Greptile's flagged TypeError. Switched both call sites from responses(**request_data, custom_llm_provider=...) to request_data['custom_llm_provider'] = ...; responses(**request_data) so the explicit-kwarg duplicate goes away on real bridge calls. Regression test now seeds request_data with a sentinel value so the overwrite path is actually exercised. @greptileai

[Cyberfilo]

@greptileai please re-review — the duplicate-keyword TypeError flagged on 2026-05-22 was fixed in commit 86429fda82 (current HEAD 2d22154250). Both call sites now do request_data["custom_llm_provider"] = custom_llm_provider then responses(**request_data) / aresponses(**request_data, aresponses=True) — no explicit kwarg, so the conflict with the value already spread from sanitized_litellm_params is gone. Tests strengthened to seed request_data with a sentinel "should-be-overwritten" so the overwrite path is exercised.

[Cyberfilo]

@greptileai please review commit 24732c418a — your earlier P1 (duplicate-keyword TypeError) is fixed in commit b638892e32 (now on this HEAD via force-push). Both sync and async call sites do request_data["custom_llm_provider"] = custom_llm_provider before responses(**request_data) / aresponses(**request_data, aresponses=True) — no explicit kwarg, so no duplicate-keyword conflict with the value already spread from sanitized_litellm_params. Tests seed request_data with sentinel "should-be-overwritten" to exercise the overwrite path.

[Cyberfilo]

@oss-pr-review-agent-shin

[Sameerlite]

@greptileai

[Sameerlite]

@Cyberfilo I think i merged this in a wrong branch. Can you create a new PR? Keep base litellm_internal_staging