Usage
Account-wide managed tenant usage dashboard for LLMs
See all owned tenants by default, filter one tenant when needed, and inspect safe failed-request details without exposing secrets.
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 aggregates across every owned tenant, with an independent tenant filter and safe scope-bound failure details.
How it works
- Enable management mode and generated-secret routing.
- Send proxy requests through any owned tenant's generated secret; each tenant remains operational independently.
- Record canonical outcome metadata for managed-tenant requests without storing request or provider-error content.
- Open Usage Overview on All tenants and 30 days, or use the Usage tenant selector immediately before ALL to narrow the report.
- 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.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| All-tenant default | The default All tenants and 30 days selections populate requests, tokens, success rate, providers, models, statuses, and buckets together. | The first dashboard snapshot represents every owned tenant rather than the oldest one. |
| Independent selectors | The Tenant control in Settings chooses only the editor; Usage tenant chooses only the report. | Changing provider settings for one tenant cannot silently narrow the usage dashboard. |
| Safe failure vocabulary | Rows distinguish validation, payload size, rate limit, unavailable, timeout, and upstream failures with canonical codes. | A failed request is not automatically labeled a provider failure. |
| 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 narrows every usage surface and failure row to that tenant while Settings can remain on Default.
Scope-safe failure review
Changing from All tenants to one tenant invalidates the old dialog request so stale rows and cursors cannot cross scopes.
Objections and limitations
- Usage is recorded for managed tenants using generated secrets.
- Failure 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=30dVerified 2026-07-26 by Tyemirov on GitHub against README.md.
FAQ
Does selecting a tenant activate or deactivate it?
No. Every owned tenant remains independently routable through its own generated secret; the Settings and Usage selectors only choose an editor or report scope.
What does Usage Overview show by default?
It selects All tenants and the 30-day interval, then aggregates the owned tenants at the server's database boundary.
Does changing the Tenant control in Settings change Usage Overview?
No. The Tenant control in Settings and the Usage tenant control are independent; changing one does not change the other.
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.
What should I read next?
A closely related resource is Normalized token usage metadata across providers, which covers normalized token usage metadata.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference