Analytics
Break down cost, requests, and tokens by model for any project
The Analytics page shows where a project's spend actually goes. It leads with the project's totals for the range, then breaks usage down — as a ranking and over time — so you can see what drives cost, requests, and tokens across any date range.

Open it from the Analytics item in the project sidebar. Like the rest of the dashboard, the page respects the shared date-range picker at the top, so every chart reflects the same window.
Totals
Three cards at the top show the project's total cost, requests, and tokens for the selected range, each with a sparkline of its daily values. They are computed from the same data as the charts below, so the total and the breakdown always agree.
Request and token counts use commas every three digits, regardless of browser locale. Chart axes and compact summaries use k, M, B, or T for thousands through trillions; hover chart points to inspect full counts.
Choosing a breakdown
The Group by selector switches which dimension the two charts break the project down by:
| Breakdown | What it shows |
|---|---|
| Model | Spend per model (the default) |
| API key | Spend per API key in the project |
| User | Spend per team member — Enterprise, owners and admins only |
Breakdown by user answers "what is each person on this team costing us?" in the same view as the project total. It is available to organization owners and admins on the Enterprise plan — see Member Analytics.
Spend is attributed to whoever created the API key that made each request. Traffic from platform keys has no member behind it, so the API key and user breakdowns show it as Unattributed rather than dropping it.
Every breakdown adds up to the total cost card: data storage, billed on top of inference, appears as a Storage entry, and the over-time charts collapse everything past the top 10 into Other.
Cost by Model
A horizontal bar chart that ranks the models used in the selected range. Switch the metric with the tabs above the chart:
| Tab | What it ranks |
|---|---|
| Cost | Total spend per model, in USD |
| Requests | Number of requests routed to the model |
| Tokens | Total tokens (input + output) |
Use it to spot the one or two models responsible for most of your bill, or to confirm that traffic is spread the way you expect.
Cost by Model Over Time
Choose Line to compare individual series or Bar to stack their values across the date range. Your chart-style choice is remembered across visits and also applies to the API key, user, and token charts. It has the same Cost / Requests / Tokens tabs, plus a Mappings / Canonical toggle:
- Mappings — each model variant is shown separately, exactly as it was requested (for example a custom provider mapping is kept distinct from the built-in model).
- Canonical — variants of the same underlying model are collapsed into one canonical model (the provider prefix and tag are dropped), so
openai/gpt-5.5and a custom mapping of it count as a single line.
Switch to Canonical when you care about the underlying model's total footprint; stay on Mappings when you need to compare specific routes.
The Mappings / Canonical toggle is specific to models — the API key and user breakdowns rank named entities, so there is nothing to collapse.
Token breakdown
Tokens over time separates uncached input, cache writes, cache reads, and output, so no input token is counted twice. Each type shows its token count and its spend; hover a bar to see both for that day. The note below the chart reconciles the four token costs with total spend, listing any fees that are not per token (request, image, audio, web search) and data storage separately.
The Total cost card includes data storage, which is billed on top of inference. The per-model, per-key, and per-user charts show inference spend only.
The same token breakdown appears on each API key's usage page.
The model selector above the chart narrows all four series and their costs to a single model, so you can see where one model's cache reads or output actually land. It lists the models used in the selected range and is available on the model breakdown.
Token counts always include credits and BYOK traffic. The billing-mode selector filters spend and requests, but the historical token counters are combined.
For budget warnings, upcoming model retirements, and provider issues, enable notifications from the bell in the dashboard header.
Admin usage views
In the admin console, organization and project detail pages share Traffic, Window, and Breakdown by controls in Usage Metrics. Choose mappings, canonical models, providers, or model families; the charts inherit that selection. Organization views also support project breakdowns, and project views support source breakdowns; both support API keys and users.
On Global Stats, Breakdown by and Measure live in the top filter bar and apply to the share chart, daily time series, breakdown table, and exports. Card-level controls do not change the selected breakdown or measure. Enabling Display: Breakdown also changes the time-series CSV from one row per time bucket to one row per bucket and dimension.
How the data is computed
These charts derive from the same activity data the rest of the dashboard already reads — there is no separate analytics pipeline to wait on. Aggregation happens per time bucket and is timezone-correct, so totals line up with the Activity and Usage pages for the same range.
For a per-key view of the same breakdowns, see API Keys. For an org-wide, per-person view on the Enterprise plan, see Member Analytics.
Idle periods and missing samples
Model and provider history stores request-bearing buckets. Successfully processed idle periods appear with zero requests, tokens, and cost; latency remains null when there are no samples. Unprocessed periods are not reported as confirmed idle periods. Failed, cached, and zero-cost requests still count as activity.
Minute history covers the last 30 days, with hourly summaries retained for longer ranges. Recovery preserves finalized hourly totals when older minute history expires. Eligible providers remain listed when idle, and rolling request counters return to zero as activity leaves the window. These storage semantics do not change routing or alert thresholds.
How is this guide?
Last updated on