How to Export and Read Your OpenAI Usage CSV (and Find the Hidden Costs)

OpenAI's usage export is a goldmine most developers never open. From the OpenAI platform dashboard, go to Usage, pick a date range that covers a full billing cycle, and export the CSV. Each row is roughly a model, a day, and its token counts, sometimes split further by project or API key. That flat file is enough to reconstruct your entire spend and spot the leaks.

What is actually in the file

The export is a flat table: one row per model per day, sometimes broken down further by project or API key. Two columns carry almost all of the meaning, the tokens you sent and the tokens that came back, and providers spell them differently. Our own bill auditor accepts prompt_tokens, input_tokens, n_context_tokens_total and several other spellings for the same quantity, because exports from OpenAI, Anthropic and OpenRouter each name it their own way. That is the first small tax on reading your own bill, and it is worth knowing before you start writing formulas against a column name that only one provider uses.

The cached token column is the one that will trip you

If your export reports cached input tokens, read it carefully before adding anything up, because the two largest providers mean different things by the same idea.

OpenAI reports cached tokens as a subset of the prompt tokens it already counted. The cached figure is contained in the input column, so adding the two together counts those tokens twice and overstates your bill. Anthropic reports cache reads separately from input tokens. There the two must be added to get the quantity you were actually charged for, and treating the cached figure as already included understates it.

Get this backwards and a reconstructed bill is wrong in opposite directions on the two providers, which is exactly the kind of error that survives a sanity check because the total still looks plausible. It is the most common mistake in a hand-built spreadsheet. Both conventions are normalised before anything is priced in the auditor, for this reason and no other.

Three places the money hides

The input and output columns are not priced alike. Across the 40 models we track, output costs a median of 5 times what input costs, and the widest gap is 8.3 times. So a row with modest token counts but a high share of generated tokens can outweigh a row with several times the traffic. Sort by output tokens, not by total tokens, and the ranking usually changes.

Models you forgot were running. An old evaluation job, a debugging script left on a schedule, a staging environment pointed at production keys. These rarely announce themselves, and they show up in an export as a model line you do not recognise or a project you thought was retired. Anything you cannot name in the model column deserves a look before you optimise anything you can.

Cheap calls at volume. Embeddings and small models cost so little per call that nobody meters them, and then a re-indexing job runs nightly over the same corpus for a year. Per call they are noise. Per month they are a line item. The export is where that becomes visible, because it aggregates what your logs show you one request at a time.

Why the total will not match your invoice

Expect a gap, and do not spend an afternoon hunting it. Usage exports are commonly bucketed by UTC day while an invoice covers a billing period in another timezone, so the first and last day of any range are partial. Batch jobs, free trial credits, taxes and any negotiated rate are all applied after the token counts the export shows you. The export is the right tool for answering where the money went proportionally, which is the question worth asking. It is the wrong tool for reconciling to the cent, and the invoice is the authority on what you owe.

What the export cannot tell you

It has no idea which feature, customer or prompt caused the spend, because the rows are aggregated by model and day rather than by request. If the answer you need is which part of the product is expensive, no amount of reading will produce it, and the fix belongs upstream: send a distinct project or API key per feature, and next month's export answers the question by itself. That one change is the highest-value thing most teams take away from their first audit.

Skip the spreadsheet

Rather than build one, paste the exported CSV straight into the bill auditor. It maps the column names automatically, normalises both cached-token conventions, sums your tokens per model, and prices the same usage on every model we track, so you go from a raw export to a ranked list of where the money went and what it would cost elsewhere. The parsing happens in your browser and the file never leaves your machine, which you can verify in your network tab while you do it.