The usage dashboard

The usage dashboard lives at /assay/dashboard. Every admitted Owner, Admin and Member can open it. It is a single page of plain tables, one per view, with a Usage metric selector at the top that applies to every table that reports usage.

Assay reports usage units, never money. To estimate cost, combine these numbers with your provider's current published prices yourself.

Usage metrics

The selector offers every metric Assay stores. The default is input tokens.

input_tokens, output_tokens, cache_read_input_tokens, cache_write_input_tokens, reasoning_tokens, image_input_tokens, image_output_tokens, audio_seconds, search_units.

A metric only has values when the provider reported it. Assay does not estimate missing metrics.

The tables

Usage Over Time. Daily usage of the selected metric, broken down by app, environment, operation, provider and model.

Usage By Agent. For each agent class: how many runs it had, how many reported the selected metric, the median and 95th-percentile usage per run, and the median number of steps per run.

Usage By Subject. Usage and run count per app and subject. Runs without a subject appear as unknown.

Top Runs. The runs that used the most of the selected metric, counting everything below them in the run tree. Each row shows the app, environment, operation, agent, subject, capture mode, whether content was sampled, the failure-capture state and the run status. People with content access also get a Run tree link on each row.

Reliability. Agent failure rate, failover rate, tool failure rate and the failed-or-lost rate of non-agent operations, broken down by provider and model where it applies. Each row carries the event and observation counts behind the rate.

Latency. Median (p50) and 95th-percentile (p95) durations in milliseconds, by scope (agent, step or operation), provider and model.

Pipeline Health. One block per reporting application. It shows:

• transport drops and hook drops, the cumulative counts reported by the client;
• incomplete agent runs, runs that never sent a final record;
• the share of runs with no subject;
• runs whose captured content is incomplete;
• client clock skew, the p50 and p95 gap between when the client sent a batch and when Assay received it.

Use Pipeline Health to confirm a new application is reporting and to spot one that has started dropping telemetry.

Filters and limits

The selector covers the metric. The other filters are query-string parameters on the dashboard or table URLs:

For example, /assay/dashboard?metric=output_tokens&app=billing-api&operation=agent.

Downloading a table

Each table is also available on its own, as JSON or CSV, at:

/assay/dashboard/{table}
/assay/dashboard/{table}.csv

where {table} is one of usage-over-time, usage-by-agent, usage-by-subject, top-runs, reliability, latency or pipeline-health. The same query parameters apply. The CSV downloads as assay-{table}.csv.

Run trees

The Run tree link in Top Runs opens /assay/runs/{run}/tree. It returns the run and every run below it as JSON: identifiers and parent links, operation, agent, provider, requested and responded model, subject, capture mode, sampling, failure capture, status and failure class. For runs captured in full mode it also includes the stored content records and messages, which is why the link is shown only to people with content access.

A run that has not sent a final record 30 minutes after Assay first received it is marked incomplete, or failed_or_lost for a non-agent operation. The scheduler checks for these every minute.

The risk guide

The dashboard links to /assay/risk, the full-capture risk and operations guide. It describes exactly what full capture stores, how sampling and failure capture behave, who can read content, the retention and erasure model, queue and MCP egress, and the payload-filter recipes. Everyone who can see the dashboard can read it.