Why can't I see how many tokens my AI agent used?

You usually cannot see how many tokens an AI agent used because the session was interactive and nothing captured its usage, the run ended before usage was reported, your totals count only some token categories, or part of the work happened in subagents or earlier sessions that your numbers do not include. Each is a gap in recording, not a sign that nothing was used. The most important rule follows from that: a missing number is unknown, not zero. Adding a zero for every run you could not measure produces totals that look precise and are wrong in one direction. This page explains where each gap comes from, how to tell which one you have, what can realistically be recorded per run, and how to report usage honestly when coverage is partial. It is about why numbers go missing; for setting up measurement from scratch, see measuring AI agent token usage.

Check first: what kind of session was it?

Start with how the work ran, because that decides whether usage could have been captured at all.

Interactive terminal. You opened the agent CLI and worked in it. The tool may show usage to you on screen, but unless something wrote it to a record, your project has nothing. This is the most common source of missing numbers, and it cannot be fixed after the fact. Interactive versus unattended sessions covers the wider difference.

Non-interactive run. Claude Code's print mode and Codex CLI's codex exec run a task without a conversation, and their output can be captured by a wrapper. If usage is missing here, the cause is narrower: the wrapper did not parse it, the tool did not report it for that run, or the run failed before it was reported.

Resumed or chained sessions. Work continued across several sessions, and you have a number for only the last one. Budget estimates can behave the same way: Claude Code's documented budget option for print mode does not include totals from earlier sessions on resume.

Note which of these applies to each missing run before trying to fill the gap.

Failed runs, subagents and other gaps

Failed or interrupted runs. A crash, a timeout, a cancelled session or a lost connection can end a run before any usage summary is written. The provider may still have processed most of the requests. Record the run with usage unknown and the reason, and do not drop it from the list, since a run that disappears from the ledger is invisible in every total.

In BRAIN FLUID's own benchmark testing, one failed run's usage could not be recovered, and it was kept in the records as unknown rather than counted as zero; its replacement run was explicitly authorized, not retried automatically.

Subagents and helper calls. Some agents start child sessions or helper processes for parts of a task. Their usage may be reported separately, folded into the parent, or not reported at all, depending on the tool. Check whether your totals include them before comparing runs that used them with runs that did not.

Outside the agent. Gateway retries, editor extensions and other tools on the same account all appear on the invoice and nowhere in the agent's numbers. Per-run records and the account bill measure different things.

Cache categories change the total

Usage is not one number. Providers report several categories, typically input, output, cache creation and cache read, and they are counted and often billed differently. A tool or script that adds only input and output tokens reports a total that can be a fraction of what was processed, because in agent sessions the same project context is sent again and again, and much of it is served from cache.

In long agent sessions, cache reads can be the largest category by a wide margin. That is not waste in itself; it is how repeated context is served. But it means a total without cache categories describes a different thing from one with them, and two runs measured with different category sets cannot be compared.

To tell whether this is your gap, look at what the record contains. If it has only two fields, input and output, the cache categories were never captured. Record all four separately, keep the category names your provider uses, and never sum them into one figure without saying which were included. Converting tokens into money is a separate step with its own assumptions about rates, and it belongs with the invoice, not the run record.

What to record, and how to report gaps

For each run, record what you can and mark what you cannot. A useful run record has the run ID and task, the tool and model, start and end time, usage by category where reported, and a coverage field with one of three values: complete, partial or unknown, plus a short reason for anything less than complete. 'Unknown: interactive session' and 'Partial: subagent usage not reported' are both honest records.

When you total usage, total the coverage too. A line such as 'measured usage for 40 of 52 runs; 12 interactive runs unknown' tells a reader exactly how far to trust the figure. A bare sum invites them to treat it as complete.

Reconcile against the invoice separately and expect a gap, since the account sees requests the run records never will. Do not adjust run records to match the bill.

To shrink future gaps, run measured work through a non-interactive path that a wrapper can record, and treat interactive sessions as unmeasured by default. Run history and reports covers keeping these records alongside the work, and spending limits covers why recorded usage alone does not cap anything.

QUESTIONS

Should I count a run with no usage data as zero tokens?

No. A run with no usage data used an unknown amount, and counting it as zero makes your totals look complete while understating them. Keep the run in your records with usage marked unknown and a reason, and report totals with their coverage, such as how many runs were measured out of how many ran.

Why is my token total much smaller than my provider's usage page?

Your total may leave out cache categories, subagent or helper calls, failed runs, interactive sessions, and requests from other tools on the same account. Check which categories your records include first; totals of input and output alone often miss the largest part of agent usage, which is cached context read again on each turn.

Can I get token usage from an interactive Claude Code or Codex session?

Only if something captures it while the session runs, or the tool writes it somewhere you can read later. The interactive screen is for you, not your records. For work you want measured, use a non-interactive mode that a wrapper can record, and mark interactive sessions as unmeasured rather than estimating them.

RELATED GUIDES

• How to read BRAIN FLUID reports and provenance

RELATED HARNESS PAGES

• Measuring token usage of AI coding agents fairly Measuring token usage of AI coding agents fairly: whole-session ledgers, separate categories, deduplicated records, failed runs kept and unknown never zero.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.
• Interactive vs unattended AI coding sessions Interactive vs unattended AI coding sessions: terminal pairing, single unattended tasks and authorized multi-task runs compared on authority and failures.
• Can you put a hard spending cap on an AI coding agent? Client-side budget flags in agent CLIs are estimates that can overshoot. A hard cap needs a reservation before each request. Here are practical limits instead.