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

#28145 [Feature]: Optional return of raw_response for search tools

  • State: open
  • Author: @wityamin
  • Labels: enhancement, proxy

### Check for existing issues

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

### The Feature

Based on an optional request header would be nice to disable the search tool response transformation and send back the original response (raw_response) back to the client.

### Motivation, pitch

In case of Tavily the current implementation removes meaningful parts from the response of Tavily API. https://docs.tavily.com/documentation/api-reference/endpoint/search

It would be nice to have support with a flag per request that forces LiteLLM Proxy to act as a proxy.

### What part of LiteLLM is this about?

Proxy

### LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

Yes

### Twitter / LinkedIn details

_No response_

Open on GitHub

GitHub resolver

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

Refresh page
vote history (6 events)
#0 of 0 · 31d19h31m25s ago — entered · #import:https:::github.com:berriai:litellm post #1668
-/https://github.com/berriai/litellm/issues/241234:1-/https://github.com/berriai/litellm/issues/28145⭐
The right issue is harder because it requires a breaking third-party SDK migration, dependency and API compatibility work, lifecycle changes, and broad regression testing. The left issue is comparatively localized to request-scoped proxy response handling and conditional serialization.
#0 of 0 · 31d19h22m23s ago · #import:https:::github.com:berriai:litellm post #1807
-/https://github.com/berriai/litellm/issues/28145⭐3:1-/https://github.com/berriai/litellm/issues/29995
The right-side change has broader proxy-wide API-contract, request-option propagation, response-shape compatibility, and regression-testing implications. The left-side work is more localized to provider-specific streaming behavior and diagnosis.
#0 of 0 · 31d19h20m56s ago · #import:https:::github.com:berriai:litellm post #1833
-/https://github.com/berriai/litellm/issues/28145⭐3:2-/https://github.com/berriai/litellm/issues/33328
The proxy change has broader scope: request-level option handling, response-path branching, provider compatibility, and end-to-end tests. The pricing correction is comparatively localized, mainly requiring consistent unit normalization and regression coverage.
#0 of 0 · 31d19h10m38s ago · #import:https:::github.com:berriai:litellm post #2008
-/https://github.com/berriai/litellm/issues/28145⭐4:1-/https://github.com/berriai/litellm/issues/28123
The right issue is harder because it requires a new, request-scoped proxy behavior across request parsing, tool-response handling, compatibility paths, and integration tests. The left issue is a localized defensive-access fix with a narrow regression test.
#0 of 0 · 31d19h3m53s ago · #import:https:::github.com:berriai:litellm post #2124
-/https://github.com/berriai/litellm/issues/28145⭐3:1-/https://github.com/berriai/litellm/issues/29505
The feature requires a new request-level control, propagation through proxy and tool-response handling, preservation of provider-specific payloads, and compatibility tests. The other item is a narrower authorization-path investigation and fix.
#0 of 0 · 31d18h19m49s ago — current · #import:https:::github.com:berriai:litellm post #2843
-/https://github.com/berriai/litellm/issues/256114:1-/https://github.com/berriai/litellm/issues/28145⭐
#25611 is harder because it requires broader changes to proxy startup, packaging, dependency management, configuration, and operational behavior across supported environments, while #28145 is a relatively contained request/response-path option with focused compatibility and testing work.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search