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

#34096 [Bug]: "Models + Endpoints" page shows "No models found" even though the models work

  • State: open
  • Author: @hluaces
  • Labels: bug, ui-dashboard

### Check for existing issues

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

### What happened?

On our proxy, users are given access to models by tier (e.g., "economy", "standard", "premium") rather than by listing each model.

For those users, the Models + Endpoints page in the UI says "No models found".

The same users see the full model list in the Playground and in the model dropdown when creating a key, and their requests to those models work fine. So the access is there, just that one page is blank.

If I change a user so they list the model names individually instead of the tier, the page starts working for them.

Users are internal users (w write) and are not in any team.

Version: v1.91.0.

### Steps to Reproduce

1. Set up models in your proxy with different groups (e.g. `economy`) 2. Create a new internal user with write and no team, assign it to that model list 3. Log in with the user, go to the "_Models + Endpoints_" page. No model is available

### Relevant log output

```shell N/A ```

### What part of LiteLLM is this about?

UI Dashboard

### What LiteLLM version are you on ?

v1.91.0

### Twitter / LinkedIn details

_No…

GitHub resolver

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

Refresh page
vote history (5 events)
#0 of 0 · 31d18h55m28s ago — entered · #import:https:::github.com:berriai:litellm post #1944
30442 is harder because it spans numerous dashboard data flows, role-aware request handling, and authorization/logging behavior, while 34096 is a more localized model-discovery UI defect.
26918 requires coordinated changes across container packaging, runtime filesystem constraints, migration tooling, and deployment configuration, with broader compatibility and security risks. 34096 is more localized to dashboard data fetching and authorization/filtering behavior.
The left issue is harder because it involves tracing state across database updates, router configuration, model synchronization, and API serialization, with regression risk in shared proxy-model infrastructure. The right issue is more localized to dashboard data loading and access-filter handling, making it narrower to diagnose and validate.
The left issue is substantially harder because it requires designing and integrating configurable throttling across provider/model routing, request scheduling, concurrency, configuration, and potentially distributed deployments. The right issue is a more localized dashboard data/filtering defect with a narrower validation surface.
#0 of 0 · 31d17h49m20s ago — current · #import:https:::github.com:berriai:litellm post #3048
The right issue is harder because it likely requires tracing dashboard data-loading, access-control, and model-group resolution across frontend and backend layers, with broader regression testing. The left appears localized to a provider-specific header-merging path.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search