Issue Station
Sign In
Tools hereToolbox

litellm - 💡(How to fix) Fix [Feature]: Expose key-level fallback configuration in the Virtual Keys UI [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#25261•Fetched 2026-04-08 03:02:24
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
SunsilkkSunsilkk
Participants
SunsilkkSunsilkk
Timeline (top)
labeled ×1
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.
  • Related but not the same: #21993, #8331, #24152.

The Feature

Add a clear UI in Virtual Keys / key edit to view, create, update, and delete key-level fallback configuration.

At minimum, the UI should let admins manage:

It would also help if the key page showed the effective router settings resolution for that key (Key > Team > Global), so it is obvious which fallback chain is currently active.

Motivation, pitch

Today LiteLLM supports router settings conceptually at the key/team level, and the docs already describe key/team fallback configuration. But in practice there is not a clear/stable UI flow in the Virtual Keys experience to inspect and reconfigure fallback chains per key.

That creates a few problems:

  • Admins have to fall back to API / DB / config-level work instead of the dashboard.
  • It is hard to audit which fallback chain a specific key is using.
  • Global fallback settings are not enough when different customers, products, or environments need different fallback behavior per key.
  • When debugging routing or reliability issues, there is no obvious place in the UI to confirm the key-level fallback setup.

Requested UX:

  • Show current key-level fallback mappings on the key details / edit screen.
  • Allow adding, editing, reordering, and deleting fallback targets.
  • Distinguish key-level settings from inherited team/global settings.
  • Ideally show validation for missing / invalid model groups before save.

What part of LiteLLM is this about?

UI Dashboard

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

No

Twitter / LinkedIn details

No response

extent analysis

TL;DR

To address the issue, implement a UI in the Virtual Keys / key edit section to manage key-level fallback configuration, including viewing, creating, updating, and deleting fallback targets.

Guidance

  • Identify the current technical limitations in the Virtual Keys experience that prevent admins from managing key-level fallback chains through the dashboard.
  • Design a UI flow that allows admins to inspect and reconfigure fallback chains per key, including adding, editing, reordering, and deleting fallback targets.
  • Develop a feature to display the effective router settings resolution for each key, showing the fallback chain hierarchy (Key > Team > Global).
  • Ensure the UI distinguishes between key-level settings and inherited team/global settings, and provides validation for missing or invalid model groups before saving changes.

Example

No specific code example can be provided without more technical details, but the UI implementation could involve creating a table or list to display current fallback mappings, with buttons or links to add, edit, or delete targets.

Notes

The solution requires a thorough understanding of the current LiteLLM UI and backend architecture, as well as the specific requirements for key-level fallback configuration. The implementation should prioritize a clear and intuitive user experience for admins managing fallback chains.

Recommendation

Apply a workaround by implementing the requested UI features to manage key-level fallback configuration, as this will directly address the identified problems and improve the overall user experience.

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…
#api#ssr#installation#tensor shape#autograd error

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 - 💡(How to fix) Fix [Feature]: Expose key-level fallback configuration in the Virtual Keys UI [1 participants]