the ledger turns a raw session log into a stack of bars — one bar per API call. this page walks the exact path it takes: split each call into four token buckets, follow how this turn's reply becomes next turn's cheap history, then watch the numbers line up. the chart is just… drawing them.
Each call resends the whole conversation: the system prompt, your tools and skills, then every turn so far — and every prior turn carries both your inputand the model's output. Call 3 ships input1+output1, input2+output2, and the fresh input3 — not just input3. Nothing is remembered server-side; the transcript is the memory, and you pay to ship it every time.
Resending the whole transcript every call would be brutal at full price — so providers let you mark the stable prefix as cacheable. The first time the provider sees a chunk, they store it (a small one-time surcharge: a CACHE WRITE). Every later call that resends the same prefix gets billed at a fraction of the normal rate (a CACHE READ). The full transcript still gets shipped every time — it's just billed at different rates depending on whether the provider has already seen it. So every call splits into four token buckets:
Widths ≈ token volume. The cache breakpoint slides forward each turn, promoting yesterday's WRITE into today's READ — so most of every resend rides in the cheap READ lane while only your new message pays full input price. Stack these four on top of each other and you have one bar in the chart.
History keeps accruing in the cheap READ lane — each turn just hands its WRITE down to the next.
Your message is queued as fresh INPUT, on top of the cached READ and WRITE — nothing’s generated yet. Hit run to add the OUTPUT.