Features

Overview (/)#

30-day totals — requests, tokens, estimated spend — computed from the usage summary endpoint, plus provider health badges (green/closed, amber/half-open, red/open) from the providers endpoint.

Applications (/applications)#

A table of every application: name, status (derived from disabledAt), monthly quota, routing strategy. A "New application" modal creates one with just a name — see Applications for what happens next.

Application detail (/applications/{id})#

Three tabs:

• Settings — monthly quota, rate limit, an allowed-models multi-select (populated from the live registry), routing strategy, and a disable switch. Saves via PATCH /management/v1/applications/{id}.
• API keys — create issues a new key and reveals the raw secret exactly once in an alert banner (it cannot be shown again — see API Keys); the table lists existing keys by prefix with a revoke action per row.
• Usage — a 30-day usage table scoped to this application.

Providers (/providers)#

One card per provider: circuit state badge and a per-model average latency list. Read-only — this is Provider Health rendered, not a control surface (there's no "manually open/close a circuit" action).

Requests (/requests)#

A table of recent request log entries across every application, filterable by status (all / success / error). Status cells show either the HTTP status or the error_code. Backed by the request log endpoint.

How data loading works#

Every page reads through Pinia Colada queries (app/queries/*.ts) keyed hierarchically (e.g. ['applications', id, 'usage', { days }]), which call the dashboard's own server/api/* routes — thin proxies that attach the management key server-side and forward to the gateway (gatewayFetch). Writes go through matching mutations (app/mutations/*.ts) that invalidate the affected query keys on completion, so, for example, revoking a key immediately refreshes that application's key list without a manual page reload.