LEARN / USAGE EXPORTS

How to read your AI usage export

PUBLISHED 2026-08-04 · BY Llorenç Ballester — Chief Burn Officer

The invoice tells you how much money disappeared. The usage export tells you whether it went into prompts, cached context, output, retries, models, or a single endpoint that believed every request required the collected works of your repository.

Export the same scope from usage and cost views

For OpenAI, the usage dashboard exports detailed Activity data or Cost data as CSV. Activity is for request and token analysis; Cost is the spend breakdown you reconcile against. Select the same organization, projects, UTC date range, interval, capability, and grouping for both. A comparison between March usage and April cost produces an impressive discrepancy with no diagnostic value.

For Anthropic, pick the workspace, model, date range, and API key in the Console usage view, then export the displayed CSV, plus the matching cost view for the same scope. The Console filters by workspace, model, and API key, but does not currently break cost down by individual user. Keep the raw files unchanged, record the export settings, and analyze on a copy — spreadsheets turn unreliable the moment humans start “cleaning” source columns by hand.

Normalize the provider-specific token columns

OpenAI usage can include input_tokens, output_tokens, num_model_requests, input_cached_tokens, input_cache_write_tokens, and input_uncached_tokens, with finer splits for text, image, and audio. At the individual response level, cached input can appear under input_tokens_details.cached_tokens and reasoning under output_tokens_details.reasoning_tokens. Read the schema: OpenAI’s aggregate input_tokens can already include cached and cache-write tokens, so adding every input field together double-counts them.

Anthropic usually separates input_tokens, cache_creation_input_tokens, cache_read_input_tokens, and output_tokens; supported thinking responses also expose output_tokens_details.thinking_tokens. Normalize both providers to a common shape — uncached_input, cached_read, cache_write, output, requests, reported_cost — while preserving the originals. Never infer equivalence from similar names without checking whether a total already contains its parts.

Requests turn token totals into useful ratios

Raw totals find the large categories; request counts reveal behaviour. Compute average total input per request, average uncached input per request, average output per request, cache-read share, and reported cost per request. Use weighted arithmetic: average input = sum(input tokens) / sum(requests). Do not average daily averages unless every day has the same request count, a condition production traffic rarely observes out of politeness.

Compute percentiles from request-level logs where you have them. An average of 3,000 input tokens might mean every request uses ~3,000, or 99% use 500 while 1% ships a whole repository. Group by project, API key, model, endpoint, prompt version, and customer workflow. Provider CSVs may not carry your application route, so join them to request IDs, API-key ownership, project IDs, or internal telemetry where possible.

High input per request is a diagnostic signal

A high average-input value can mean full conversation replay, complete files sent for small edits, excessive retrieval chunks, large tool outputs returned to the model, duplicated system instructions, every tool schema attached to every call, or agent state that grows each turn. Inspect the largest requests against the task performed. A 40-page contract analysis may legitimately be large; a language classifier carrying 20,000 tokens has taken an interest in literature.

Break the prompt into measurable components before changing it: system instructions, conversation history, retrieved documents, tool definitions, tool results, user content, and hidden framework metadata. Log a token estimate per component, or serialize them separately during tracing. Then decide what can be removed, summarized, retrieved later, scoped by tool, or cached. For the caching mechanics rather than the export analysis, see prompt caching.

Worked example: finding repeated history

A monthly export shows 300,000 requests, 600 MTok uncached input, 300 MTok cached reads, and 90 MTok output. Logical input is 600 + 300 = 900 MTok, so average input is 900M / 300k = 3,000 tokens/request; average output is 300 tokens/request. Unremarkable — until you segment.

One support endpoint is 50,000 requests and 500 MTok of logical input: 500M / 50k = 10,000 input tokens/request. Trace inspection shows ~6,000 removable history tokens per call, so 50,000 × 6,000 = 300 MTok is recoverable, split roughly 2:1 uncached-to-cached like the rest of the export (~200 / ~100 MTok). At Claude Sonnet 5 ($2 input, cached reads ~$0.20 — verify on the board), that is 200 × $2 + 100 × $0.20 ≈ ~$420/month from one endpoint. Drop the endpoint’s real distribution into the Burnmeter; the counts here are assumptions, the method is not. (The mechanism is the history multiplier.)

Reconstruct spend, then reconcile it

Estimate spend per model with the categories the provider actually bills: uncached input × uncached rate + cached reads × cached-read rate + cache writes × cache-write rate + output × output rate. Take rates from the board, including any batch, long-context, service-tier, or regional rules, and keep separately billed tools, searches, storage, audio, and images out of the text-token subtotal.

Compare the reconstructed subtotal with the provider’s Cost export for the identical UTC window and grouping. Usage and cost reporting can differ slightly because the systems aggregate differently — treat reported cost as the reconciliation target, not a number to force your estimate onto by spreadsheet decree. For a first-pass, drop the normalized, browser-safe export into the usage auditor, then confirm each finding against application traces.

When a suspicious number is legitimate

High input per request is not automatically waste. Document analysis, long-context synthesis, repository review, legal comparison, and multimodal work can genuinely need the context. Low cache usage is unsurprising when prompts rarely share a stable prefix. High output can be correct for code generation, translation, data transformation, or reports whose consumer needs the content.

The export should produce questions, not convictions. Check whether the task succeeded, whether the context was necessary, and whether trimming it changes quality or retries. And rule out scope errors before diagnosing architecture: missing projects, mixed currencies, different time zones, incomplete days, batch traffic, credits, failed requests, or tools left out of your formula. Sometimes the scandal in the CSV is merely two filters disagreeing — less exciting, but considerably cheaper to fix.

Frequently asked questions