Claude Code cost, and what the number means

Every tool in this space will show you a dollar figure, and almost none of them are showing you what you paid. That is not dishonesty; it is the only thing they can compute. Understanding the gap is the difference between a number you can act on and a number that just makes you anxious. This page is about how ccclub builds its figure, line by line, and what you can legitimately conclude from yours.

On a subscription, nobody is charging you per token

If you are on Pro or Max, your tokens are not priced individually by anyone. The dollar amount any tracker shows is what those tokens would have cost had they been billed at public API list rates. Call it API-equivalent value. It is a real quantity and a useful one — it is comparable across days, across people and against a monthly plan price — but it is not an invoice and nothing reconciles against it.

Claude Code says the same thing about its own screen. Its cost documentation describes the session figure as computed locally from token counts at list price, calls it an estimate, and points at the Console's usage page for authoritative billing. (code.claude.com/docs/en/costs, read 2026-09-19.) Any tool reading the same logs inherits the same caveat.

Where the prices come from

ccclub ships with a price table baked into the package, so a fresh install can compute costs before it has spoken to anything. On top of that it fetches an updated table from ccclub.dev/api/pricing at most once a day, using a conditional request so an unchanged table costs a round trip and nothing more. The server side of that endpoint refreshes nightly from the LiteLLM price feed. The fetched table is overlaid on the bundled one rather than replacing it, so a model the feed has dropped keeps its price instead of silently becoming free.

Two consequences worth knowing. The table is keyed by normalised model ID, and a dated or suffixed variant the feed has not picked up yet falls back to a representative model from the same family — usually correct, and a great deal better than counting those tokens at zero. And because the fetch is never on the critical path, being offline does not break cost calculation; you simply keep using the table you already had.

The formula

Prices are per million tokens, and each bucket is charged at its own rate:

cost = ( input       x input rate
       + output      x output rate
       + cache write x cache-write rate
       + cache read  x cache-read rate ) / 1,000,000

Four refinements sit on top of that. Cache writes made with a one-hour lifetime carry a premium over the standard write rate, so ccclub prices every write at the standard rate and then adds the difference for the one-hour subset only, clamped so a malformed log cannot claim more long-lived writes than it reported writes. Models that price the whole request differently once its input passes a threshold switch every rate for that request rather than applying a marginal band. Reasoning tokens, where a source reports them separately, are charged at the output rate. And if your ~/.codex/config.toml sets service_tier to fast or priority, every Codex request is priced on that tier: the whole total is multiplied at the end, by 2 unless the price table carries a different multiplier for that model.

The arithmetic happens once, in the collector that parsed the entry, and the result is summed into 30-minute blocks. That is deliberate: the raw token counts are what gets stored, so a corrected price table can reprice history without anyone re-reading multi-gigabyte logs.

When the source reports its own cost

Some agents write a cost into their own logs. Where a source has historically treated that number as authoritative, ccclub uses it in preference to its own calculation — the provider knows its contract and ccclub only knows a public rate card. The rule is presence, not truthiness: a reported zero is a real answer, meaning the request was included and cost nothing, and the price table would have invented a figure instead, because its fallbacks never return zero. A negative number is not a price at all — a refund line, or a parser reading the wrong field — so it is treated as absent and the calculated cost wins.

The ROI column

If you tell ccclub which plan you are on, the leaderboard adds a column comparing the two. Set it with ccclub profile --plan pro, max100, max200 or api. The definition is exactly one division: your estimated cost over the last 30 days, divided by the plan's monthly price, as a percentage. A row reading $200/1610% means a $200 plan against $3,220 of tracked usage at list prices.

It is a blunt instrument and worth naming the ways it misleads. It is denominated in list prices, so it inherits every caveat above. It counts every agent ccclub tracks, not only the one your plan pays for, which flatters anyone running several. And a percentage below 100 does not mean you are wasting money — plenty of people get their money's worth from a plan they use lightly but at exactly the right moments.

How to read your own number

Do not go looking for a normal figure to compare against; the spread between people doing similar work is enormous, and ccclub is not going to invent a benchmark for you. Anthropic's cost documentation does publish one calibration point, for enterprise deployments — an average of around $13 per developer per active day — but that population is nothing like someone on a personal plan, and reading it as a target would be a mistake.

Your own number is more useful read as a trend and a ratio. Compare this week with last week rather than with anyone else. Watch the per-turn column — $/Turn in the CLI, Avg Turn on the web dashboard — which divides cost by the messages you actually typed: when it climbs, it usually means sessions are running longer before you clear them, not that the work got harder. And if you want the comparison against other people anyway, that is what a group board is for — a handful of people you know is a far better reference class than an average.

What it will never tell you

Not real spending, not per-project attribution, and not whether the money was well spent. ccclub has no per-project cost report at all: the project chips on a leaderboard row are labels a member attaches to themselves, never anything derived from usage. And cost, like tokens, is a measure of activity. A cheap week where the right thing shipped beats an expensive one, and no column here can tell the difference.

Last updated 2026-09-29. Corrections welcome on GitHub.