Usage
Account-wide managed tenant usage dashboard for LLMs
See execution usage across owned tenants and inspect failed and rejected requests separately without exposing secrets or request content.
Teams giving users self-service AI access while keeping usage visible.
The problem
A multi-tenant key-management portal is incomplete when its default dashboard hides every tenant except one or implies that selecting a tenant activates it.
How LLM Proxy helps
LLM Proxy's authenticated Usage Overview defaults to account-wide execution aggregates across every owned tenant. It reports requests rejected before provider dispatch separately from failed executions. Independent chart toggles control the provider and model breakdowns. Requests and Tokens have distinct UTC and per-bucket quantity axes.
How it works
- Create managed tenants and their generated client keys.
- Send proxy requests through any owned tenant's generated secret; each tenant remains operational independently.
- Record one rejected, succeeded, or failed disposition with canonical outcome metadata and no request or provider-error content.
- Select a tenant for its usage or select Account usage for combined totals.
- Use each breakdown card's icon button to switch that card between ranked bars and a count-and-percentage donut.
- Read Requests and Tokens against their visible UTC and zero-based per-hour or per-day axes.
- Read account-wide totals from GET /api/management/usage or one tenant from GET /api/management/tenants/:tenant_id/usage.
- When failures exist, open N failed requests; account-wide rows include safe tenant context and tenant-scoped rows do not repeat it.
- When rejections exist, open N rejected requests to inspect requests that did not reach provider dispatch.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Explicit account usage | Account usage shows combined requests, tokens, success rate, providers, models, statuses, and time buckets. | The selected tenant has its own usage view. |
| One tenant context | The selected tenant controls configuration, model defaults, and tenant usage. | Account usage is a separate, labeled view. |
| Independent request breakdowns | Each card has one keyboard-operable icon button that switches only that card between bars and a donut. | Both views derive from the same ordered aggregate request counts without another management request. |
| Explicit time-series axes | Requests and Tokens each show UTC X ticks and a zero-based integer Y scale for the canonical hour or day bucket. | The charts do not imply one shared numeric scale or an exact event time. |
| Separate dispositions | Execution metrics contain only succeeded and failed requests, while rejected_requests reports requests that could not dispatch. | Invalid input or missing provider configuration does not reduce the proxy success rate. |
| Safe detail reports | Failure rows contain attempted execution errors; rejection rows contain invalid_request, payload_too_large, or provider_not_configured. | Both reports expose bounded metadata without raw error content. |
| Scope-bound pagination | Newest-first cursors remain bound to All tenants or one exact tenant. | Prompts, responses, provider bodies, free-form errors, and credentials never enter the dialog. |
Use-case examples
Portfolio overview
A user sees the combined request and token totals for every owned tenant without making one browser request per tenant.
Tenant investigation
Selecting Research shows its connections, defaults, usage, and request details.
Scope-safe failure review
Changing from All tenants to one tenant invalidates the old dialog request so stale rows and cursors cannot cross scopes.
Impossible request review
A request for a recognized provider without a saved tenant credential appears as provider_not_configured in the rejection report and never reaches provider dispatch.
Objections and limitations
- Usage is recorded for managed tenants using generated secrets.
- The donut is a request-share view, not a token-share or provider-performance comparison.
- Every provider and model category stays separate; the donut does not create an Other tail.
- The charts are client-side presentations of existing aggregates, not billing, provider-key, exact-event-time, or new management-API features.
- Failure and rejection rows are operational metadata, not reconstructed provider error messages or a billing system.
- Administrators receive aggregate summaries only; per-event rows remain owner-only.
Repository evidence
GET /api/management/usage?interval=30d
GET /api/management/tenants/:tenant_id/usage?interval=30d
GET /api/management/usage/failures?interval=30d
GET /api/management/usage/rejections?interval=30dVerified 2026-09-10 by Tyemirov on GitHub against README.md.
FAQ
Does selecting a tenant activate or deactivate it?
Each tenant remains routable through its API key. Dashboard selection changes the visible context.
What does Usage Overview show by default?
It shows the selected tenant and the 30-day interval. Account usage combines all owned tenants.
Does changing a breakdown chart request new usage data?
No. Each independent chart toggle changes one local presentation of the same request aggregates.
Does tenant selection change the usage view?
Yes. Selecting a tenant shows its configuration and usage. Select Account usage to examine combined totals.
What tenant data appears in account-wide failure rows?
Only the safe opaque tenant ID and current display name are added. Credentials, prompts, responses, provider bodies, and free-form errors remain excluded.
Does an unconfigured provider count as a proxy failure?
No. The proxy rejects the request before provider dispatch, increments rejected_requests, and exposes provider_not_configured only in the rejection report.
What should I read next?
A closely related resource is Normalized token usage metadata across providers, which covers normalized token usage metadata.
Related resources
Inspect managed usage contracts
Review the account-wide and tenant-scoped usage endpoints before you inspect their aggregates in Usage Overview.
Open API reference