17 views
-/https://github.com/berriai/litellm/issues/28234
GitHub · issue

#28234 [Feature]: Compare daily usage across multiple keys of a single user in the Usage dashboard

  • State: open
  • Author: @Qwarctick
  • Labels: enhancement, ui-dashboard, claude code

### Check for existing issues

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

### The Feature

### The Feature

Allow selecting multiple API keys belonging to the same user and visualizing their daily usage (spend, tokens, requests) as comparable time series on a single chart in the Usage tab.

### Current state

The backend already returns everything needed: `GET /user/daily/activity?start_date=...&end_date=...` includes `breakdown.api_keys` per day with spend / prompt_tokens / completion_tokens / api_requests. This is purely a UI gap.

### Proposal

On the Usage tab (when scoped to a single user):

- A multi-select listing that user's keys by key_aliases - A line chart with one series per selected key, x = date, y = spend, with a toggle for tokens / requests - Keep the existing aggregated view as default; the multi-key comparison is an opt-in mode

### Motivation, pitch

In our deployment, individual users own many keys, typically one per tool/integration (Claude Code, Zed, internal scripts, CI jobs, etc.). The current Usage tab shows a breakdown by key, but there's no way to chart several keys of a single user as overlaid series on the …

GitHub resolver

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

Refresh page
vote history (4 events)
#0 of 0 · 31d19h5m59s ago — entered · #import:https:::github.com:berriai:litellm post #1774
The dashboard work spans selection state, chart-series rendering, metric switching, and integration with existing UI behavior, while the provider issue is a more localized parameter-mapping fix with targeted regression tests; therefore the dashboard work is harder.
The left requires coordinated backend, data-model, pricing, policy, auditability, and idempotent migration work with significant correctness risk. The right is a comparatively contained dashboard interaction and visualization change using existing data.
The left issue is harder because it requires provider-specific request routing, authentication-derived endpoint handling, and compatibility across Responses API and model variants. The right issue is primarily a frontend enhancement using already available backend data, with comparatively limited integration risk.
#0 of 0 · 31d18h40m14s ago — current · #import:https:::github.com:berriai:litellm post #2196
The left issue is harder because replacing a deprecated database client is a potentially cross-cutting migration involving data-access compatibility, dependency changes, schema behavior, rollout risk, and broad regression testing. The right issue is comparatively bounded: it extends an existing dashboard with selection and visualization logic over already available data.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search