AI Token Dashboard

Demo & usage

More examples

When to use

• Monitoring LLM token usage and cost across models and time.
• FinOps and engineering dashboards that track AI spend.
• For general (non-token) analytics, use the Charts components.

Async states

• loading
• error
• retry

Outputs

Wire it to your API

This component is headless about transport: it renders what you give it and reports what the user asks for. Nothing below requires @styloviz/data — drive it from whatever you already use.

• This component does not emit a query, so it renders what you give it. Fetch on your own trigger and bind `daily`, `loading` and `error`.
• Normalize failures with `toSvDataError()` from `@styloviz/core`. It derives `retryable` from the status, so a 404 does not get a "Try again" button that can only fail again.

Full walkthrough: Connecting to a backend.

Customization & theming

• `cachedInputTokens` and `reasoningTokens` are subsets of input and output, shown as notes rather than added to the total: per model in `breakdown`, and summed across models on the `overview` Token Distribution card. Beside the quality-adjusted multiple, `breakdown` shows the amount — cost per passing result against cost per request — in the display currency.
• `daily`, `models` and `budgets` are inputs defaulting to the bundled sample, so the dashboard demonstrates itself out of the box and reports your real usage when you have it.
• `period` is two-way, so the reporting window can be driven from your own state and used to refetch.
• KPI, breakdown, trend and comparison views.
• Per-model cost and token tracking.
• Configurable currency and period.
• Emits `periodChange` when the usage period changes.
• The cost-efficiency verdict is host policy: `[efficiencyMinRequests]` (25) is the traffic a row needs before it is compared with the fleet at all — without a floor the anomaly column is permanently topped by a tenant who made two calls, one of them a long document — and `[efficiencyBand]` (0.5) is how far from the fleet rate reads expensive or cheap. Both default to the still-exported `SV_EFFICIENCY_MIN_REQUESTS` / `SV_EFFICIENCY_BAND`, and `svAttribute` takes them as an optional last argument. A band at or above 1 is refused, because "cheap" would then ask for a non-positive cost per request and no row could ever reach it.
• `[billing]` — currency, rate, tax, discount, and how far the provider has settled — drives both the figures and a note that says **which gaps this page cannot account for**. Every displayed cost — totals, per-model, per-request, per-1M, budgets and attribution — goes through `svDisplayCost`, so the discount, tax and conversion the note claims are the ones the numbers carry, and the note renders under every variant that shows a cost, not only the breakdown. `rateAsOf` names the day the conversion rate was taken; a converted figure with no rate date says so, because an invoice converted on a different day will differ. A non-USD `currency` with no usable `rate` stays in USD and the note names the missing conversion — labelling unconverted dollars in another currency would be a claim about money nobody has. Budgets are compared with usage at list price, so they are displayed on the same basis as the spend they cap. A cost dashboard that disagrees with the invoice destroys trust in one billing cycle, and it will disagree: list prices, in USD, before tax, before whatever the contract discount is, over a window nobody has settled. A dashboard that says 'estimated' and stops has not helped — the reader needs to know which direction it is wrong in before taking it to finance.
• `cachedInputTokens` and `reasoningTokens` are **subsets** of the input and output figures, never additions, so nothing on the page moves when a host adopts them. Cached input bills at a fraction, so counting it with fresh input overstates spend on exactly the workload somebody optimised; reasoning output is billed and never shown, so a reader who counts the words they got back and a bill that counts the tokens produced disagree by a factor — and the reader concludes the provider is overcharging.
• `[passRates]` (model id → 0–1, from your eval suite) turns spend into **cost per result that passed**, rendered as a multiple of the sticker price because that survives a currency change and a period change. A model at a third of the price that passes two thirds as often is not cheaper, and every dashboard in this category ranks by raw spend and calls the cheap one a saving. At a zero pass rate the figure is refused rather than rendered as infinity — which would put a number in a column somebody will sort — or as the raw cost, which would say the failures were free. A pass rate outside 0–1 is labelled out of range (above 1 it reads as a percentage passed by mistake) rather than 'not recorded', and a model with no spend reads 'no spend recorded' rather than NaN×.

Best practices

• Do: Show both tokens and cost — stakeholders care about the dollar figure.
• Do: Break usage down per model so expensive calls are visible.
• Tip: Pick the variant by audience: overview for execs, comparison for engineers.

Accessibility

• Chart values are surfaced as text/tables.
• Period and sort segmented controls are labelled and report aria-pressed.
• Color-coded series paired with labels.