EXPERIMENT_024 // TOKEN-REUSE.COST.VISUALIZER
Upload a token-log export or load the bundled sanitized sample, and this experiment charts reuse ratio over time, reused-versus-fresh token composition, and an estimated cost split — entirely in your browser.
LOADING EXPERIMENT...
This one reads a file, not a paste box. Open the experiment and the dashboard renders immediately from a bundled, sanitized sample dataset of synthetic agent-run token records, clearly labelled as sample data throughout. Upload your own JSONL or JSON token-log export and every chart recomputes from your file instead — parsed entirely in your browser, never sent anywhere. The dashboard turns a single reuse-ratio headline into four inspectable views: how much of each day's input tokens were served from prompt cache, the reused-versus-fresh-versus-cache-write split across the whole set, which category of work reuses context the most, and what all of it is estimated to cost.
HOW IT WORKS
A single parseTokenLog() function accepts a JSON array, a { records: [...] } wrapper object, or newline-delimited JSON (JSONL) — the same shapes a real per-request token-usage export is likely to arrive in. The bundled sample and an uploaded file both run through this one parser; there is no separate 'demo' code path that can drift out of sync with the real one.
Each record carries inputTokens (freshly read), cacheReadTokens (served from cache — the 'reused' quantity), and cacheCreationTokens (newly written to cache). Reuse ratio for any day or category is cacheReadTokens divided by total tokens touched (input + cache read + cache write) — the same three components a prompt-caching provider's own usage accounting reports, not an invented metric.
Instead of a second hand-rolled pricing model, the cost split and estimated-savings figure are computed with @diabolicallabs/llm-pricing's computeCost() — the same package the fleet's other experiments and production routes already use. Reused tokens are re-priced at their model's fresh-input rate to derive what reuse actually saved, rather than asserting a flat percentage.
An uploaded file that fails to parse, or one where no record survives shape validation, throws an explicit error naming the exact expected schema and falls back to the bundled sample dataset — relabelled 'Sample data' in every panel. The dashboard never renders a blank or half-drawn chart from bad input.
The bundled dataset is entirely synthetic — generated from a seeded script mirroring how Claude Code's prompt caching actually behaves (a session's first turn writes context to cache, later turns read it back), not a copy of any real fleet session. Every panel carries a visible 'Sample data' tag whenever it's the active source, so a visitor can never mistake it for live telemetry.
WHAT THIS PROVES
Nate Jones's Token Saver post reports a single headline number — 95.73% of 3.77B tracked input tokens reused. This experiment doesn't reproduce that number; it tests whether a more useful question can be answered instead: what is actually being reused, and does it vary by the kind of work being done. Breaking one flat percentage into a per-day trend, a three-way token composition, and a per-category comparison turns a single statistic into something a practitioner can actually inspect and act on.
A visualizer over a bundled sample is a smaller claim than a live dashboard over real session data, and that's deliberate — this experiment reads exactly one class of external data at runtime, a static bundled file or a file the visitor supplies, and sends nothing anywhere. The interesting engineering question isn't whether reuse can be visualized at all; a prompt-caching provider's own usage API already reports the raw numbers. It's whether a client-side-only parser, applied identically to a synthetic sample and a real personal export, can make the composition of that reuse legible without ever needing a server in the loop.