Your cost tracker rewrites history every time a price changes.

The bug you cannot see

Look inside ~/.claude/projects/ and you will find token counts. Input tokens, output tokens, cache reads, cache writes, per event, with a timestamp. What you will not find is a single dollar amount, because Claude Code does not record one.

So every cost tracker computes the money itself. Tokens times a rate. That makes the price table the most important file in the tool, and it makes the date the join key nobody talks about. A tracker carrying one current-price table joins your past against the present. Its history is correct right up until the first price change, and then it is quietly wrong for every day before it. Each later change rewrites those same past days again, so the error compounds rather than settling.

Nobody ships this on purpose. It is what a price map frozen in the source at release time does on its own, and because the number still looks like a number, nothing warns you the day it starts lying.

Watch it happen

Claude 3.5 Haiku is the clearest case in the ledger. It ran at $1.00 per million input and $5.00 per million output from 2024-11-04, then dropped to $0.80 and $4.00 on 2024-12-03. It was retired on 2026-02-19.

Take one session on 2024-11-20: 4.2M input tokens and 380K output tokens. The token counts are an illustration. Every price below is from the dataset.

The day before the cut, your tracker said 2024-11-20 cost $6.10. The day after, it said the same session cost $4.88. Nothing about that November day changed except the tool's price table. 20 percent of your recorded spend vanished overnight, and once the model retired the whole row went to zero.

Three ways a frozen table lies

The direction of the error depends on which way the price moved, which is what makes it hard to notice. It is not a consistent bias you can correct for.

• A price cut shrinks your history

  The extreme case in the ledger is the o3 cut on 2025-06-10. A 2M-in, 500K-out session from before it cost $40.00 at the rate then in force. A current-table tool reprices that same session at $8.00 today: a 80 percent cost reduction you never actually received, applied retroactively to work you already paid for.

• A price rise inflates it

  Prices do go up. Reading old months at a newer, higher rate makes past work look more expensive than it was, which is the version that makes you distrust your own budget.

• A retirement erases it

  When a model is withdrawn it leaves the current table entirely, so sessions that used it price at zero or throw. 7 models in this index are already in that state, 6 of them Claude models that Claude Code users actually ran.

The fix is a dataset, not code

No amount of care in a cost tracker fixes this, because the missing thing is not logic. It is a record of what the price used to be. That record has to be dated, and it has to keep old values instead of overwriting them.

Every row in the AI Price Index carries an effective_from and an effective_to. A price change does not edit a row; it closes one window and opens the next. The two Haiku input rows above are literally this:

{ "model_id": "claude-3-5-haiku-20241022", "variation": "input",
  "price_usd": 1, "effective_from": "2024-11-04", "effective_to": "2024-12-03" }
{ "model_id": "claude-3-5-haiku-20241022", "variation": "input",
  "price_usd": 0.8, "effective_from": "2024-12-03", "effective_to": "2026-02-19" }

That is 105 models across 11 providers, every value carrying a first-party source and a validation date, with pre-index windows reconstructed from web archives and labelled as archived rather than claimed as first-party. It is published as an open dataset under CC BY 4.0 with a citable DOI, so you can check any number here against the record, or build your own tool on the same ledger.

Scope, stated plainly: this prices LOCAL usage computed from your own logs, at list price. It is an estimate of what those tokens were worth, it is always labelled LOCAL, and it is never summed with BILLED invoice figures from a provider.

Audit your own history

Your existing logs are enough. Nothing needs to have been running at the time, because the token counts were recorded whether or not you were watching.

curl -fsSL https://roninforge.org/get | sh
budgetclaw report --by-month

If you would rather stay inside Claude Code, the claude-code-cost plugin reports the same figures from the same dataset. For spend across several machines and people, the hosted dashboard applies the same dated pricing to a twelve-month history.

All of it reads the JSONL that Claude Code already writes to ~/.claude/projects/. No API keys, no prompt contents, no API traffic touched, and the price data is embedded at build time so the pricing works with no network at all.

Boundaries and honest limits

What if a session spans a day when the price changed?

Windows are dated, and each usage event is priced by its own day. A session that ran across a change boundary is priced on both sides of it, not averaged.

What about cache reads and cache writes?

They are separate variations in the ledger with their own dated windows, so they are priced from their own history rather than inferred from the input rate.

I am on Claude Max or Pro. There is no API bill. What does this price?

Subscription usage has no marginal API bill, so a LOCAL figure is what the same tokens would have cost at list price. It is always labelled LOCAL, and it is never added to a BILLED invoice total.

What happens when the index gets a correction?

Your history gets more accurate, not different. Corrections supersede a value inside its dated window without deleting the window, so a recomputed month moves toward the truth rather than toward today.