# What is token accounting? > Token accounting is tracking input, output and cached tokens per call and pricing them exactly. Why rounding and float math corrupt LLM cost data. URL: https://getculpa.com/what-is-token-accounting Last reviewed: 2026-08-01 ## Answer Token accounting is recording input, output, and cached tokens for every call, then pricing each category at its own rate in exact decimal arithmetic. The three categories bill differently, so one combined count can't produce a correct figure. Culpa, a local-first LLM cost, margin, and forecast ledger, meters all three per call and prices them from a versioned book. ## Why this happens Two things break token accounting in practice. The first is collapsing the categories, treating tokens as one number when input, output, and cached tokens carry rates that differ by an order of magnitude. The second is floating-point money. A per-call cost of a fraction of a cent, summed across millions of calls, accumulates float error into a figure that no longer reconciles with anything. Both failures are silent, which is what makes them expensive. ## What this usually looks like - Your totals disagree by small amounts depending on which report ran them, with no code change in between. - Per-call costs display as long trailing decimals, which is the visible symptom of float arithmetic underneath. - You track a single token count per call, so you can't say whether input or output drove a change. - Cached tokens either aren't recorded or get counted at the standard input rate, overstating spend. ## Common mistakes - Storing money as a floating-point number. Why it hurts: Float can't represent most decimal fractions exactly, so millions of tiny costs accumulate an error you can't audit away. Do instead: Store money as an exact decimal type, and do the arithmetic at a fixed precision from token counts and rates. - Rounding each call to cents before summing. Why it hurts: Most calls cost well under a cent, so per-call rounding either zeroes them out or inflates them massively. Do instead: Keep full precision per call and round only at the point of display, never in storage or in a running total. - Trusting a provider-reported cost field as the source of truth. Why it hurts: Not every provider returns one, formats differ, and a field you can't reproduce from tokens and a rate can't be audited. Do instead: Compute cost yourself from tokens and a versioned rate, then use any provider figure as a cross-check rather than the answer. ## Self-check - Check whether your cost column is a float or an exact decimal type. If it's a float, that's the first fix. - Take one call and recompute its cost by hand from its token counts and the rate. It should match to the last digit. - Confirm you store input, output, and cached tokens as separate fields rather than one total. - Sum a day of per-call costs and compare against your own daily aggregate. A drift means rounding is happening somewhere. - Check what your system records when a model isn't in your rate book. Silent zero is worse than a flagged gap. ## The same call, priced three ways One Claude Haiku 4.5 call at real rates of $0.001 per 1k input, $0.005 per 1k output, and $0.0001 per 1k cached input. The call sends 3,000 input tokens of which 2,000 hit the cache, and returns 500 output tokens. Collapsed count (3,500 tokens at the input rate) = 3.5 x $0.001 = $0.0035, which is wrong in both directions Correct split: 1,000 uncached input = 1 x $0.001 = $0.001 2,000 cached input = 2 x $0.0001 = $0.0002 500 output = 0.5 x $0.005 = $0.0025 Correct total = $0.001 + $0.0002 + $0.0025 = $0.0037, and rounding this call to cents would record $0.00 The collapsed count under-read by 5% on one call. Rounding to cents would have recorded nothing at all. Across a million calls, either error is the whole number. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - $0.0037 — correct cost of a single cached Claude Haiku 4.5 call, priced by category [calculated] Source: (1 x $0.001) + (2 x $0.0001) + (0.5 x $0.005), using Claude Haiku 4.5 rates per 1k tokens from the price book, effective 2026-07-02. - 5% — understatement produced by collapsing the three token categories into one count [calculated] Source: ($0.0037 - $0.0035) / $0.0037, from the two calculations shown in the teardown. ## FAQ Q: Why can't I just use floating-point for LLM costs? A: Because a per-call cost like $0.0037 has no exact binary representation, and the error compounds across millions of rows. Financial systems have used exact decimal types for this reason for decades, and LLM billing has the same shape. Q: What happens when a model isn't in my price book? A: It should record zero cost and flag the record as incomplete, so the gap is visible rather than silently understating your spend. A system that guesses a rate for an unknown model is producing a number nobody can defend. Q: Should I count cached tokens as input tokens? A: Count them separately. On several providers the cached rate is an order of magnitude below the input rate, so folding them together overstates spend badly. On Anthropic models you also need to track cache writes, which bill above the input rate. ## Sources - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=what-is-token-accounting&cluster=metric Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.