Usage and metering
One row per request — tokens, cost, latency and status — and what the dashboard builds out of it.
Every request the gateway answers writes one row. That row is what the
Usage screen reads, what the ledger's spend entry is derived from,
and what you can point at when a bill looks wrong.
What is recorded
| Column | Meaning |
|---|---|
model / provider |
What it was actually routed to |
api_key_id |
Which key made the call |
prompt_tokens / completion_tokens |
Counted from the provider's response |
cost_micros |
Priced at the catalogue rate, in micro-dollars |
latency_ms |
Request start to last byte |
ttft_ms |
Request start to first token, on streamed calls |
status |
ok, error, cancelled or timeout |
Days are UTC
Buckets run midnight to midnight, UTC, everywhere — the chart, the totals and the comparisons. A team spread across time zones otherwise gets three different answers to "what did we spend yesterday".
Reading the screen
The three figures across the top of the chart are the window's totals, and they are also the control: whichever one is lit is the one plotted below it. There is one measure on the axis at a time, deliberately — a chart with two scales invents a correlation that is not in the data.
Underneath, four facts the plot cannot carry: average latency, average time to first token, the error rate, and how long the remaining credit lasts at the window's burn rate.
Retention
Metering rows are kept for as long as the account needs them for billing. Request and response bodies are a separate question — see Zero data retention.