9 views
-/https://github.com/berriai/litellm/issues/31824
GitHub · issue

#31824 [Feature]: End-user self-service usage endpoint and dashboard

  • State: open
  • Author: @limitjupyter-ops
  • Labels: enhancement, proxy

### Check for existing issues

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

### The Feature

I would like LiteLLM to provide a self-service usage endpoint and dashboard for ordinary virtual key holders.

The goal is to let an end user query their own usage without requiring master key or admin permissions.

Suggested endpoints:

- `GET /me/usage` - `GET /me/usage/detail` - `GET /me/usage/all-keys`

The response could include:

- current month call count - token usage - spend - budget - remaining budget - monthly call limit - remaining monthly calls - model-level breakdown - key-level breakdown - usage window start/end

Desired behavior:

1. A virtual key holder can retrieve only their own usage. 2. Master key should not be required for self-service usage. 3. Optional aggregation by `user_id`, `end_user`, or metadata fields such as `employee_id`. 4. Admin UI can expose a non-admin self-service usage page. 5. Existing admin usage endpoints remain unchanged.

### Motivation, pitch

In enterprise LiteLLM deployments, many users need to know their own usage without contacting an admin.

Common questions include:

- How many calls have I used t…

GitHub resolver

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

Refresh page
vote history (16 events)
#0 of 0 · 31d18h18m41s ago — entered · #import:https:::github.com:berriai:litellm post #2545
31824 requires coordinated backend authorization, usage aggregation, API design, dashboard work, and broad testing, while 24549 is primarily a localized provider-parameter filtering fix with targeted regression coverage.
The right issue is harder because it spans authorization boundaries, privacy-safe data scoping, aggregation across usage records, API design, and frontend work while preserving existing administrative behavior. The left issue is a comparatively contained provider adapter with model metadata, pricing, and protocol-selection integration.
Cross-cutting contract validation would require substantial schema integration, normalization across many providers, broad fixture and CI coverage, and ongoing compatibility maintenance. The other request is a bounded proxy feature involving authorization, usage queries, and UI work, with less systemic risk.
The right issue is harder because it spans authenticated API design, strict tenant-level authorization, usage aggregation and accounting semantics, backward compatibility, and dashboard/UI integration. The left issue is primarily a structured validation effort against an already-defined multi-commit compatibility stack, with substantial test coverage but lower product and architectural risk.
30421 is harder because it spans a new CLI workflow, multiple third-party agent integrations, remote model discovery, authentication, configuration translation, and cross-platform process behavior. 31824 is substantial but more bounded around authenticated API design, usage aggregation, and dashboard presentation.
The right issue is harder because it spans backend API design, authorization and tenant isolation, usage aggregation, and a new dashboard experience, while the left issue is a narrower but technically difficult distributed-counter debugging and correction effort.
Monthly call-limit enforcement is harder because it affects the request authorization path, requires accurate concurrent counting and reset semantics, and must integrate configuration, persistence, warnings, and administration surfaces. Self-service usage mainly extends existing reporting and UI capabilities with scoped authorization and aggregation.
Issue 30043 is harder because it requires cross-cutting protocol compatibility work, streaming correctness, provider-specific behavior, token accounting, and extensive regression testing across complex agent workflows. Issue 31824 is primarily scoped to authorization, usage aggregation, API design, and UI exposure.
The left issue is harder because it spans authenticated authorization boundaries, privacy-safe aggregation, usage-data consistency, API design, and dashboard integration while preserving existing administrative behavior. The right issue is narrower, primarily involving provider-specific configuration modeling, validation, propagation, and enforcement.
Historical financial-data mutation requires versioned pricing, idempotency, auditability, safe background execution, and nuanced failure semantics; the other mainly adds authorization-scoped read APIs and UI aggregation.
31824 is harder due to cross-cutting authorization, privacy isolation, usage aggregation, API design, and dashboard work across backend and frontend surfaces; 28125 is substantial routing/configuration work but is more concentrated in core model-group resolution and validation.
The left task is harder because it spans authenticated API design, authorization and data isolation, aggregation, and dashboard UI work, while the right is primarily a backend extension of existing budget, persistence, counter, and reset mechanisms.
The left task spans API design, authorization boundaries, usage aggregation, persistence/query behavior, and UI integration while preserving existing administrative flows. The right task is narrower and primarily involves defining an authentication abstraction and integrating credential handling, with less cross-cutting product surface and migration risk.
The self-service feature is harder because it spans authenticated authorization boundaries, usage-data aggregation, multiple API surfaces, and dashboard work while preserving existing administrative behavior. The routing feature is architecturally significant but can be concentrated in the proxy’s request-selection extension points and compatibility layer.
#31824 is harder because it spans authenticated self-service API design, tenant-scoped authorization and privacy guarantees, usage aggregation, multiple reporting dimensions, and dashboard/UI integration. #28032 is narrower in scope, primarily requiring hierarchical access resolution, cycle/consistency handling, and updates to authorization logic.
#0 of 0 · 31d17h23m18s ago — current · #import:https:::github.com:berriai:litellm post #3494
Distributed concurrency and data-isolation failures require difficult reproduction, diagnosis, and correctness validation across Redis Cluster and replicas, with substantial security risk; the self-service feature is broader in surface area but comparatively straightforward application, authorization, aggregation, and UI work.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search