LLM Usage Cost Analyzer
Drop the usage file your provider lets you export — a CSV from the console or a JSON response from the usage API — and turn it into the answers a raw export buries: what each model cost, which days spiked, how much of your input was cached, and which models cannot be priced at all. Everything is parsed locally in your browser and your file is never uploaded, because a usage file is a map of what you run, how often, and what it costs you.
Last updated:
What this analyzer reads
Providers hand you usage in two shapes, and this page reads both. The first is the CSV export from a provider console — one row per day, model or API key, with columns for input tokens, output tokens, cached tokens, requests and sometimes cost. The second is the OpenAI usage API JSON: an object with a data array of time buckets, each holding per-model results with the n_-prefixed token counts that API returns. Column names differ between providers and change between console versions, so the parser does not demand one fixed layout: it normalises every header, matches it against the names OpenAI, Anthropic and generic exports actually use, and shows you the resulting mapping before it computes anything.
That mapping step is deliberate. Automatic detection gets the common exports right, but a renamed column or a provider-specific extra field can silently put output tokens where input tokens belong — and a cost report built on swapped columns looks plausible while being wrong. The selects above the results show exactly which column feeds each field, pre-set to the detected mapping, and you can correct any of them and re-run. Rows whose date cannot be read, or whose input or output value is not a number, are skipped and counted in the results rather than guessed at: a smaller honest total beats a larger invented one, and the skipped count tells you how much of the file did not survive.
How costs are computed — and what to look for
When the file carries its own cost column, those figures are used as-is: the provider billed them, and no recomputation improves on the bill. When there is no cost column, each row is priced from this site’s own LLM pricing table — the same verified rates behind the cost calculator — using the formula providers use: uncached input at the input rate, cached input at the cached rate when the model offers one, and output at the output rate. Models are matched by their exact API id or display name, allowing for a provider prefix and a trailing date or “latest” suffix — and nothing looser. The results banner says where the money came from: file, computed, mixed, or none, so you always know whether you are reading a bill or an estimate.
A model that matches nothing in the pricing table is listed as unpriced, never guessed. That matters more than it sounds: usage files routinely contain fine-tunes, preview ids, deprecated snapshots and third-party deployments whose real price is whatever a contract says, and inventing a rate for them would poison the totals for every model that was priced honestly. Unpriced models still contribute their token and request counts to the totals and appear in their own list with their volumes, so you can see exactly how much of your traffic the estimate does not cover — and price that slice yourself if it is large.
Three patterns are worth looking for in any usage file, and the per-model and per-day tables here are built to expose them. A cached-token ratio that is near zero on a workload with repeated prompts means prompt caching is off, misconfigured, or being defeated by a changing prefix — often the single cheapest fix available. A model mix drifting towards the expensive tier — flagship models answering questions a small model handles equally well — shows up as a rising cost share for one model while request counts stay flat. And a runaway key or loop shows up in the per-day table as a spike, often at a weekend or overnight, with request counts far above the surrounding days. The companion guide, how to analyze your LLM usage file, works through each pattern and what to do about it.
The five facts this page shows
| Cost by model | Requests, input, output and cached tokens per model, with its cost and its share of the total — grouped by the raw model name exactly as it appears in your file. |
| Cost by day | The same totals per calendar day, in date order, so spikes, weekend loops and quiet periods are visible at a glance. |
| Cached share | Cached input tokens against total input — the ratio that tells you whether prompt caching is actually working on your traffic. |
| Cost source | Whether the money figures came from the file itself, were computed from the pricing table, are a mix of both, or could not be produced at all. |
| Unpriced models | Models with no match in the pricing table, listed with their volumes instead of an invented price, so the gap in the estimate is explicit. |
Frequently asked questions
Where do I get a usage file to analyse?
From your provider’s console or API. OpenAI exposes usage in the console usage page and through the usage API, whose JSON this page reads directly; Anthropic exposes usage and cost in its console and through its API reports, which export as CSV. Any CSV with a date column, a model column and input/output token columns will work here regardless of provider, because the column mapping is detected from the headers and can be corrected by hand.
Is my usage file uploaded anywhere?
No. The file is read and parsed in your browser, in this page; nothing is uploaded, transmitted or stored, and closing the tab removes it. That is deliberate: a usage export lists every model you call, your volumes by day and what you spend — operational data that has no reason to sit on a stranger’s server or in a chat log. The pricing table used for estimates is public data embedded in the page itself.
Why does my total differ from my provider bill?
A few honest reasons. If the file had no cost column, the total is an estimate from list prices: it cannot see negotiated discounts, credits, batch or off-peak rates, free-tier allowances, or tiered long-context pricing, and rows that were skipped are missing from it. If the file did carry costs, check the skipped-row count and the date range first — a truncated export is the most common cause of a short total. Treat a computed total as a close guide to where the money went, not as a reconciliation of the invoice.
What does “unpriced” mean for a model?
It means the model name in your file matched nothing in this site’s pricing table — not by exact id, not after removing a provider prefix, and not after stripping a date or “latest” suffix. Fine-tunes, preview and deprecated snapshots, and models from providers the table does not cover all land here. Their tokens and requests still count in the totals; only their cost is left blank rather than invented, and they are listed separately so you can see the size of the gap.
How is cost computed when the file has no cost column?
Per row: (input − cached) × the model’s input rate, plus cached × its cached-input rate (or the input rate when the model offers no cached discount), plus output × its output rate, all divided by one million, using the rates on the LLM pricing page. Those rates are the standard list prices verified against official provider pages; scheduled or tiered variants are noted on the pricing page and are not modelled here, which is one reason a computed total is an estimate.