litellm - ✅(Solved) Fix [Bug]: Fallbacks have stopped reporting the fallback model used [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#28241Fetched 2026-05-20 03:40:38
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×2cross-referenced ×1renamed ×1

Fix Action

Fixed

PR fix notes

PR #28260: Fix/fallback headers sdk completion

Description (problem / solution / changelog)

Relevant issues

Fixes #28241

Linear ticket

N/A

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

<!-- Include screenshots, screen recordings, or log output demonstrating that your changes work as expected. For bug fixes: show reproduction before the fix and passing behavior after. For new features: show the feature working end-to-end. For UI changes: include before/after screenshots. -->

Before this fix, SDK-level fallbacks could return the fallback model from LiteLLM, but the proxy response-model override could not detect that a fallback happened because x-litellm-attempted-fallbacks was missing or prefixed as a provider header. The override then stamped the originally requested model back onto the response.

<img width="2066" height="1275" alt="ss2" src="https://github.com/user-attachments/assets/b040f9d5-b4de-4525-ba47-f83170e2b8b8" />

After this fix:

<img width="2554" height="864" alt="Untitled" src="https://github.com/user-attachments/assets/940bee45-784d-4297-873a-27d2a554e540" />

Type

<!-- Select the type of Pull Request --> <!-- Keep only the necessary ones -->

🐛 Bug Fix

Changes

This fixes SDK-level fallbacks so the response keeps reporting the actual fallback model that handled the request.

When a fallback succeeds, async_completion_with_fallbacks now adds the same x-litellm-attempted-fallbacks marker that the router fallback path already sets. This lets downstream code detect that the primary model failed and a fallback model was used.

process_response_headers now keeps LiteLLM-owned x-litellm-* headers unchanged instead of treating them like upstream provider headers. Provider headers are still prefixed with llm_provider-*, but LiteLLM internal markers remain available under their original names.

Added regression tests for the fallback header, the primary-success case, and preservation of x-litellm-* response headers.

Changed files

  • litellm/litellm_core_utils/core_helpers.py (modified, +18/-1)
  • litellm/litellm_core_utils/fallback_utils.py (modified, +8/-2)
  • litellm/litellm_core_utils/llm_response_utils/response_metadata.py (modified, +2/-1)
  • tests/test_litellm/litellm_core_utils/test_fallback_utils.py (added, +110/-0)
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?

Until now, when a fallback was used (trouble with the original or, on purpose, using mock_testing_fallbacks: true in tests, the used fallback was returned as the model in the response.

That's not anymore (since 1.85.0 I've detected it) and always, the original model is returned instead of the used fallback.

So, right now, there isn't any way, in code, or in tests, to know that a fallback has happened and which has been the model responding.

In my case it has broken not less that 10 tests (that we use before upgrading LitelLLM) in completions, embeddings, image... fallbacks. And also a couple of real cases/integrations where the model in the response was being inspected to make some decisions.

In version 1.83.x-stable it was working ok (returning the fallback model used).

Steps to Reproduce

  1. run any request using "mock_testing_fallbacks": true
  2. expected: the fallback model used should be returned in the response.
  3. actual: the original requested model is returned, no matter a fallback happened.

Relevant log output

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.85.0

Twitter / LinkedIn details

No response

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING