Read the report
Make one
On the ico host, from deploy/:
docker compose exec collector ico report --window 24h --out /tmp/report.html
docker compose cp collector:/tmp/report.html report.html
--window is how far back it looks (90m, 24h, 7d), ending now or at --until, an ISO time in UTC unless it says otherwise. The result is one HTML file with no scripts and nothing loaded from elsewhere: open it, mail it, attach it to a ticket.
Raw records are kept for 30 days, so a window can reach back that far.
What it says
The examples below come from a real run: 16 minutes of four simulated customers on one H100 SXM, rented at $3.99 an hour, serving Qwen3-8B with vLLM 0.31.
The headline
$0.0366 per million tokens. GPUs cost $1.05 in this window, and $0.0650 of it (6%) paid for time with nothing to serve. Another $0.0891 (9%) paid for compute cores that had nothing to run while requests were being served. Without idle time the same tokens would have cost $0.0344 per million.
Tokens are prompt and completion tokens together. The idle share is the first thing to look at: on rented GPUs, every idle hour is billed like a busy one. The second sentence appears where the GPUs report profiling counters: it is capacity paid for while serving and left unused, as with small batches. See How costs are counted.
Cost by model
Each model carries the cost of the replicas that serve it, idle time included: GPU-hours, cost, serving share, idle cost and idle GPU-hours, tokens, and cost per million tokens.
Cost by tenant
Each replica's cost, idle time included, split across the tenants it served by the work their requests took:
| Tenant | Requests | Share of cost | Per million tokens |
|---|---|---|---|
| meridian-freight (chat assistant) | 6,140 | 40% | $0.0351 |
| orbit-analytics (research agent) | 2,429 | 38% | $0.0769 |
| lumen-media (questions over documents) | 4,868 | 22% | $0.0202 |
| daily-ledger (batch summaries) | 360 | <1% | $0.0279 |
Two tenants with the same token count can cost very different amounts. Here the research agent paid more than twice as much per token as anyone else: it thinks before every step, so most of its tokens are generated one at a time, while the questions over documents are mostly prompt tokens, which the GPU processes in bulk. Requests without a tenant header appear as (no tenant header). Past 100 tenants, the smallest are folded into one row.
Replicas
One row per replica: its host and GPUs, the price per GPU-hour, the hours it was seen, its cost and serving share, and how each was measured. Serving measured by is time with a request in flight, unless the compute cores were active for longer, as with traffic that bypassed the gateway; Cores unused while serving shows the profiling counters' finding where there are any; Tenants split by says whether engine traces were there to weigh prefill and decode; Requests traced is the share of requests that had an engine span.
Replay
When a replay was run on the window's traffic, its results: the current config against the cheapest one that held the latency limits, and whether it was clearly cheaper. The report shows the newest replay of traffic inside its window, or, if there is none, the newest that finished by the window's end. See The replay lab.
Telemetry level
Per host: the telemetry level, and over the window the average share of time the compute cores, the tensor cores and the memory bandwidth were busy, the peak memory in use and the average power draw. On the H100 above: 85% compute cores active, 51% tensor cores, 51% memory bandwidth, 73.1 GiB peak, 606 W.
Inputs
The window, when the report was made, the prices it used and where they came from, and how each number was made. Every number in the report can be traced back to here.
Query the numbers yourself
The report reads views that take the window as parameters, and you can query them directly:
SELECT * FROM usage_by_tenant(since = '2026-10-14 00:00:00', until = '2026-10-15 00:00:00')
The views are usage_by_tenant, replica_busy, replica_phases, replica_engine and host_gpus. The tables underneath are described in Stored data.