How the numbers are worked out
Which figures are exact, which are estimates, and how each one is derived.
Token counts in Pulse Code are exact — they are read straight from the usage data Claude Code writes to disk. Per-tool context cost is an estimate, because Anthropic does not report a token cost per tool call; it is derived from the byte length of each tool result. Estimated figures are always labelled and never shown in the same column as billed ones.
Last updated 14 September 2026
Where the data comes from
Claude Code writes a newline-delimited JSON transcript for every session, on your own disk. Each assistant turn carries a usage object with four token counts and a model name. The agent reads those files, takes the counts, and uploads nothing else.
What is exact
- Input, output, cache-write and cache-read token counts, per turn
- The model used for each turn
- When each turn happened
- Which project directory the session started in
- How many times each tool was called, and how many of those errored
- The byte length of each tool result
What is an estimate
One thing: the context cost of a tool call. Anthropic does not report a token cost per tool, so it cannot be read. What can be measured exactly is how many bytes a tool result added to the transcript. That byte count is divided by a configured characters-per-token figure to approximate tokens.
This is an approximation and is treated as one. Every estimated figure carries a ~ marker, the MCP page carries a permanent note, and no estimate is ever placed in the same column as a billed number without a label between them.
Two counting mistakes that make most token maths wrong
1. One API response becomes many lines
Claude Code writes one transcript line per content block — thinking, text, each tool call — and repeats the entire usage object on every one of them. Add up the lines and you roughly double the real figure.
Measured across 708 real transcripts on one machine: 43,205 assistant lines carrying usage collapse to 21,773 actual API responses. That is a 1.98× overcount for anyone summing lines. One turn in that set was spread across 27 lines.
2. Resuming a session copies its history forward
When a session is resumed or forked, Claude Code copies the earlier turns into the new transcript and gives the copies a new request id. Deduplicating on the request id therefore counts every resumed session twice.
Pulse Code deduplicates on the message id alone, and enforces it with a database constraint rather than application logic — so re-uploading the same data, from any machine, in any order, changes no total.
How cost is calculated
The agent uploads token counts and a model name. It never uploads a dollar figure. Cost is worked out on the server from a dated price table, which means a pricing correction applies retroactively to every turn ever recorded instead of leaving history frozen at an old rate.
All four token buckets are priced separately. Cache reads are far cheaper than fresh input — at typical rates, roughly a tenth — so collapsing them into one "input" number overstates cost dramatically. Money is stored as integer millionths of a dollar, because cents are too coarse: a single cache-read token costs a small fraction of one cent, and rounding to cents would quantise millions of turns to zero.
What "scheduled" means
Claude Code marks headless runs itself, so a claude -p invocation is separated from interactive work without any configuration. What it cannot know is what you call that job — so cc-run records the name, working directory, start and end time and exit code, and the server matches those to sessions by directory and time window.
When we are not sure, we say so
If a model has no price in the table, it falls through to a catch-all rate rather than being counted as free — a zero would look like a free turn, which is worse than an obviously wrong number. And while any rate in the table is still a placeholder, the product refuses to present figures as money: dollar columns are greyed and every page carries a warning.