Clanker Ledger

Tool

A free tokenomics calculator

Run one 4.7M-token session in two context windows. Every reply re-sends the whole window, so the same tool call costs more at 900k context than at 100k. The 1M window is not a one-time cost.

Context windows

The same workload runs in both windows. A is usually the smaller one.

Price sheet

USD per million tokens. The same list prices apply to both windows.

4.7M unique tokens · 1,567 reads at 3,000 new tokens each · 25% input / 60% output / 15% thinking

Advanced assumptions

A coding agent: 3,000 new unique tokens per reply, 1,567 reads across a 4.7M-token session. Small tool results still re-read the whole window.

The profiles assume 2k, 3k, 10k, and 20k new unique tokens per reply, with a 90% cache hit rate. They are illustrative, not measured. Every reply re-sends the whole context, then adds the new tokens. New tokens per reply sets how many reads fit in the session; more, smaller replies mean more cache reads. Autocompaction runs when the next reply would overflow the window. Every unique token, including thinking, is assumed to stay in the window. The pass is priced as a cold read of the whole window plus the summary output; the window then restarts at the kept size. Thinking is billed at the output price. The simulation caps at 5,000 reads.

Runs locally. Simulation, not a quote. No account, no tracking.

Simulated bill

1,567 reads · 4.7M unique tokens

Context A

200,000 tokens

$0.00

simulated total across 4.7M unique tokens

Context rent
$0.00 (0%)
Compaction passes
$0.00
Unique input
$0.00
Unique output + thinking
$0.00
Cache reads
0 tokens
Tokens transacted
0 (0× unique)

0 compactions · 0 reads

Context B

1,000,000 tokens

$0.00

simulated total across 4.7M unique tokens

Context rent
$0.00 (0%)
Compaction passes
$0.00
Unique input
$0.00
Unique output + thinking
$0.00
Cache reads
0 tokens
Tokens transacted
0 (0× unique)

0 compactions · 0 reads

Enter two windows and a price sheet.

The simulation updates in your browser.

Cumulative simulated spend

X: session length in unique tokens. Y: total dollars spent so far. Green is Context A, the smaller window; red is Context B, the larger. The slope steepens as the window fills; dots mark autocompaction.

The chart needs JavaScript.

It applies the list prices and assumptions above — change any input and the whole bill moves.

What the simulation shows

Each line is cumulative simulated spend. The X axis is session length in unique tokens, not wall-clock time. Both windows start at zero and pay the same list prices. Once a window fills, every reply re-reads it. The larger window keeps more history, so each reply sends more cache-hit tokens; the smaller window resets more often, so it pays for more compaction passes. The slope of either line steepens as its context fills.

Why context is rent

A model does not remember the previous read for free. Every reply re-sends the whole window, then adds the new tokens. At 60k context, a reply with 1k new input and 3k output still re-reads 60k tokens; at the default 90% cache hit rate, most of that is cache-priced and the rest is input-priced. At 900k, the same reply pays nine times as much for that context read. Coding with large contexts is death by a thousand cuts: each tool call is small, but the window behind it keeps growing.

The cache-read price is usually the smallest number on a price sheet, but it is charged on most reads, and each read covers the whole window. A 4.7M-token session in a 1M window can bill hundreds of millions of cache-read tokens. That is how a small rate becomes a large line on the bill.

per read = window × cache price
         + new unique input × input price
         + (new unique output + thinking) × output price
compaction = full window × input price
           + summary output × output price

The default cache hit rate is 90%: nine of every ten context reads pay the cache price, and the rest are billed at the input price. Lower it to model more misses. Thinking is priced at the output rate here.

The five basic numbers

Context A and Context B set the two windows. Input, output, and cache-read prices set the three rates. The advanced panel changes the workload behind the curves: session size, new unique tokens per reply (which sets the number of reads), the input/output/thinking split, the retained summary, and the cache hit rate. The profiles are illustrative assumptions—2k, 3k, 10k, and 20k new unique tokens per reply, with a 90% cache hit rate—not forecasts or measurements.

What this does not model

Quality, cache expiry, retries, batch discounts, tokenizer differences, minimum charges, provider-specific cache-write rules, summarization by a separate model, and taxes. It prices tokens under the stated assumptions, not correctness.