Guides / token accounting
What is token accounting?
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.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Storing money as a floating-point number. | Float can't represent most decimal fractions exactly, so millions of tiny costs accumulate an error you can't audit away. | 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. | Most calls cost well under a cent, so per-call rounding either zeroes them out or inflates them massively. | 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. | Not every provider returns one, formats differ, and a field you can't reproduce from tokens and a rate can't be audited. | Compute cost yourself from tokens and a versioned rate, then use any provider figure as a cross-check rather than the answer. |
Run this check tonight
- 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.
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.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $0.0037 | correct cost of a single cached Claude Haiku 4.5 call, priced by category | calculated | (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 | ($0.0037 - $0.0035) / $0.0037, from the two calculations shown in the teardown. |
What a generic answer can’t know
A dashboard built on a provider's aggregate can only be as precise as the aggregate. It can't re-derive a single call's cost from its tokens, so it can't show you the working or let you audit a figure you doubt. Culpa computes each call from tokens and a dated rate on your own infrastructure, where your prompts and responses stay, and counts the calls to run your plan.
Questions founders ask next
Why can't I just use floating-point for LLM costs?
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.
What happens when a model isn't in my price book?
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.
Should I count cached tokens as input tokens?
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.
On your infrastructure
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.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.