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

#35095 UI: show the model family logo in the models table, not just the provider's

  • State: open
  • Author: @ian75013
  • Labels: llm translation

## The problem

On a proxy that routes many models through a single aggregating provider, every row in the models table shows the **same** logo — the provider's. That makes the list visually uniform and hard to scan, even though the models come from very different families.

Concretely, with ~20 Scaleway models configured, every row shows the Scaleway mark, whether the model is Mistral Small, Qwen3, Gemma, Llama 3.3, GPT-OSS, GLM or Whisper. The same happens with any aggregator: OpenRouter, Together, Bedrock, SageMaker, Groq, Fireworks, DeepInfra, Novita.

Scaleway's own console solves this by showing the **model family** icon rather than its own: Mistral rows get the Mistral mark, Qwen rows the Qwen mark, Gemma the Google mark, and so on. It makes a twenty-row list readable at a glance.

## Why this looks cheap to do

Two things are already in place:

1. **The assets exist.** `ui/litellm-dashboard/public/assets/logos/` already ships `mistral.svg`, `qwen.png`, `google.svg`, `meta_llama.svg`, `openai_small.svg`, `deepseek.svg`, `anthropic.svg` — the families that aggregators mostly serve.

2. **The precedent exists.** `providerLogoMap` already maps some entries to a *family* logo ra…

GitHub resolver

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

Refresh page
vote history (6 events)
#0 of 0 · 31d18h51m49s ago — entered · #import:https:::github.com:berriai:litellm post #2106
The right issue is harder because it requires careful low-level streaming/concurrency changes across synchronous provider integration, thread scheduling, buffering behavior, and regression testing without disrupting existing async and proxy paths. The left issue is comparatively contained UI work involving model-family detection, asset mapping, and table rendering.
24513 is harder because it crosses the dashboard/backend request path and provider-routing semantics, requiring careful compatibility handling and regression coverage. 35095 is comparatively localized to frontend presentation logic and existing assets, with lower integration risk.
The left issue is harder because it involves tracing provider-specific tool-call normalization and the server-side agent execution lifecycle, with greater risk of regressions across model routes and MCP behavior. The right issue is a comparatively contained dashboard presentation change involving existing assets and model-to-family mapping.
The dependency work has broader cross-environment compatibility implications, touches build and release processes, and carries significant regression risk. The UI work is comparatively localized to presentation logic and existing assets.
The UI change has broader frontend mapping and fallback implications across model naming conventions and provider configurations, while the proxy change is comparatively localized to request-context capture in an error path. The UI work is therefore moderately harder, though neither requires major architectural changes.
#0 of 0 · 31d17h58m45s ago — current · #import:https:::github.com:berriai:litellm post #2982
The left issue requires tracing and correcting backend authorization across multiple budget-window paths, while preserving expiry semantics and compatibility with existing key accounting. The right issue is a comparatively localized dashboard presentation change using existing assets and mapping logic.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search