Blog · 2026-09-06 · 7 min

The 8.59M-Token Session.

What one observed coding session reveals about the re-reading tax, and how memory ends it.

Direct answer

An observed Claude Code session burned 8.59 million tokens at 97.2% cache hit rate, and roughly 90% of them re-read files the agent had already seen. This is the canonical shape of agent waste, and the reason memory layers exist.

01

The numbers

8.59M input tokens in a single session. 97.2% served from prompt cache, the bill was already discounted about as far as caching can discount it. Input-to-output ratio around 175:1. And the split that matters: on the order of 90% of tokens spent re-reading repository content, ~10% on actual reasoning toward the goal.

At 2026 Claude-class pricing ($2–5 per million fresh input tokens, ~10% for cache reads), that session cost tens of dollars, nearly all of it paying the agent to re-learn what it had already learned. Multiply by sessions per week per developer and the re-reading tax becomes a budget line.

02

Why it happens

Three compounding mechanics. First, every token loaded is re-billed on every later turn until compaction, a 10K file read at turn 3 costs another 10K at turns 4, 5, 6. Second, agents over-read by design: opening a whole file is safer than opening nothing, so navigation defaults to dumps. Third, nothing persists, the next session starts from zero and pays the orientation bill again, in full.

Caching cannot fix this. The session was already 97.2% cached. Cache discounts price; it does not shrink attention load or orientation repetition. Only memory (durable, curated, retrieved under budget) attacks the quantity side.

03

What memory changes

With a compounding memory graph, the same work looks different: first session pays orientation and records typed nodes (decisions ~16x, bugfixes ~24x, threads ~25x, per-node design estimates). Session two can retrieve instead of re-reading. Typical turns target 2–4K packed tokens instead of ~50K raw. What is measured: micro-fold cut median uncached tokens −11.0% (n=5, verification 19/19), and headless fix tasks landed −11%…−21% across 24/24 verified pairs.

The 8.59M-token session becomes, by construction, a ~1M-token session at worst, and its successors keep shrinking as corroborated knowledge replaces exploration. That is the compounding thesis: session N+1 cheaper and sharper than session N.

04

What you can do today (any agent)

One task per session, a 3-hour mega-thread costs 3–5x the history tax of three focused sessions. Reference spans, not files. Scope test commands and pipe verbose output through head. Keep AGENTS.md/CLAUDE.md to non-inferable rules. Then add the layer files can't provide: a memory graph that remembers why, not just what.

Questions

Asked About This Post.

Q

Is the 8.59M figure from Anvaya?

No, it is from one observed Claude Code session, used here as a canonical waste example, not an industry-wide average. Anvaya's own per-node ratios (12–25x) are design estimates; the measured end-to-end lever is published at /benchmarks/records (micro-fold −11.0% median uncached, n=5).

Q

Would a bigger context window have helped?

No. The session fit in the window, that was the problem. It paid to attend to 8.59M tokens regardless of ceiling. Windows are headroom, not efficiency.

Q

Does 97.2% cache mean it was cheap?

Cheaper than fresh, still expensive: cache reads cost ~10% of fresh, and 8.59M × 10% across hundreds of turns is real money, before counting the attention cost of noise.

Run Agents That Fit On Your Laptop.

25.6 MB median RSS. 25 agents ran in parallel on a Core 2 Duo with 4 GB RAM. Hundreds on your machine. Zero cloud required on the Ollama path.

Requires Rust/cargo to build from source. Linux and macOS today, Windows not yet supported. Pre-1.0, public beta. Pricing TBD.