Claude Code Token Usage: 97% of 44.6B Tokens Were Cache Re-Reads

Claude wrote 122 million tokens for me last month. To write them, it read 43 billion.

I got that ratio by parsing 30 days of my Claude Code token usage straight from the JSONL session logs on my laptop: 192,178 API requests, 889 main sessions and 5,696 subagents. I wanted to know which habit was expensive. The answer was mostly not the one I would have bet on, and the fix I liked best turned out to be weak.

TL;DR

• 97.03% of my 44.57B tokens were cache reads. Output was 0.27%.
• At API list prices the month comes to $15,290: 56.6% reads, 31.7% cache writes, 11.6% output. I'm on a subscription, so this is a measuring stick, not my bill.
• Subagents were 58% of the cost. Each one started with a median of 68,815 tokens before its first tool call.
• Bash drove 67% of the re-reads I could pin on a tool. Claude ran cat/sed-style commands 42,453 times, more than the Read tool's 29,968.
• Capping tool output at 5K tokens would save about 2.4%. Trimming 10K tokens from the startup context would save about 3.8%, with no change to any tool call.

Where does Claude Code token usage actually go?

Almost all of it goes to re-reading the conversation. Every agent step sends the whole context again, so a long session pays for its history on every request.

Before anyone reads this as "caching is bad": the same 43.24B tokens at normal input prices would cost about $133,000. Caching cut that line by roughly 15x. It's the cheapest token I buy, and it's still the biggest line on the sheet.

Size matters too. Requests above 200K tokens of context were 41.7% of all requests and 59.6% of the cost. My longest session ran 2,436 requests and took 2.3% of the month alone.

How do you measure Claude Code token usage from the logs?

Read ~/.claude/projects/**/*.jsonl and sum message.usage, but key it by message.id. One API response is written as several JSONL lines, one per content block, and each line repeats the same usage object.

That trap is big. My window had 400,880 assistant lines for 192,178 real requests. The naive sum said 93.0B tokens, 2.09x the true 44.6B. Resumed sessions add a smaller version of the same bug: 287 requests appeared in two files.

import glob, json, os, time
from collections import Counter

cutoff = time.time() - 30 * 86400
requests = {}  # message.id -> usage
root = os.path.expanduser("~/.claude/projects/**/*.jsonl")

for path in glob.glob(root, recursive=True):
    if os.path.getmtime(path) < cutoff:
        continue
    for line in open(path, errors="ignore"):
        if '"usage"' not in line:
            continue
        try:
            row = json.loads(line)
        except json.JSONDecodeError:
            continue
        msg = row.get("message") or {}
        if row.get("type") == "assistant" and msg.get("usage") and msg.get("id"):
            requests[msg["id"]] = msg["usage"]  # last line wins

totals = Counter()
for usage in requests.values():
    for key in ("input_tokens", "cache_creation_input_tokens",
                "cache_read_input_tokens", "output_tokens"):
        totals[key] += usage.get(key) or 0

print(len(requests), totals)

This takes about 35 seconds here, against 21GB of logs. The mtime filter keeps whole files, so totals land slightly above a strict 30-day cut. For dollars, I priced each request by its own model: Opus 5.5 and Sonnet 5.5 cache reads are both $0.20 per million, and 5-minute and 1-hour writes are 1.25x and 2x input.

Why does one tool result get billed dozens of times?

A tool result enters the context once and is then re-read on every later request until the context resets. Think of it as rent, not a one-time fee.

The median tool result in my logs was only 865 tokens, and it was re-read 23 times. Mean lifetime was 42.8 requests. The worst row was a 15,183-token MCP resource read that sat in a main session for 334 more requests: 5.07 million cache-read tokens, about $1, from a single call.

Rent is concentrated. The top 1% of tool calls produced 17.4% of it, and the top 10% produced 58.4%.

To estimate it, I took the context growth between consecutive requests, split it across that step's tool calls by character count, capped each at characters / 2.5, and multiplied by the requests left before the context dropped by more than 30%. It's an estimate, and a deliberately low one.

Which Claude Code tool costs the most?

Bash, by a wide margin. It wasn't because each result was huge. There were just a lot of them.

The surprise was inside Bash. I bucketed commands by their first verb, and file-reading verbs (cat, sed, head, tail, awk, nl, wc) won: 42,453 calls and 4.22B re-read tokens. So the shell read files 1.4x as often as Read did and generated 1.6x the rent.

Write is worth a look as well. The file body sits in the tool input, so a big generated file stays in context after it lands on disk.

How much do Claude Code subagents cost before doing any work?

About 19% of my month. The median subagent opened with 68,815 tokens of context and ran only 15 requests, so startup was a large part of its whole life.

The math on all 5,696 subagents:

• First-request cache writes: $923. Only about 22% of first-request tokens were cache hits.
• Re-reading that startup context on later requests: $1,934.
• First-request cache reads: $17.

Total: $2,874, or 18.8% of the month, spent on context that existed before any subagent ran a command. Main sessions added another $856 of startup re-reads. Across everything, startup context accounted for 32.2% of all cache reads. Tool results took 34.4%, and the other 33.4% is assistant text, injected reminders and whatever my low estimator declined to assign.

My global CLAUDE.md is 25KB. Every agent carries it, along with tool definitions and the skill list. That file felt free because I only ever wrote it once.

Is idle cache expiry the real cost problem?

No. It's the obvious suspect, and it came in under 5%.

I counted a cache rebuild as any request that kept at least 70% of the context but read less than half of it from cache. There were 649 of those, rewriting 183.7M tokens. That's 15.3% of all cache writes and roughly $740 at my average write price, or 4.8% of the month.

Idle time doesn't even explain all of them. 257 rebuilds, the largest single group, happened less than 5 minutes after the previous request, and 61 lined up with a model switch. I didn't trace the rest. Worth fixing, but this isn't where the money is.

What would actually reduce Claude Code token usage?

Startup context first. I simulated three changes against the same 30 days, counting both re-reads and writes:

The output cap was the fix I wanted to win. It's easy to explain and easy to build. It lost to deleting 10K tokens of standing instructions, and it would truncate over 10,000 results to do it.

The 2K cap looks best and is the one I trust least. Nearly one call in five would lose data, and an agent missing data runs another command. That's the part this simulation can't see.

The caveats, stated plainly:

• This is one person's month, with a lot of automated subagent work. Your ratios will differ.
• Dollars are API list prices, not what I paid.
• Rent is an estimate, and a third of reads are unattributed.
• The savings are simulated. I did not A/B them, so treat them as a ranking, not a promise.

So where does Claude Code token usage go? In my 30 days of logs, 97% of 44.6B tokens were cache re-reads of context the model had already seen, and output was 0.27%. Cost split 56.6% reads, 31.7% writes and 11.6% output, with subagents at 58% of the total. The biggest levers are how much context every agent starts with and how long sessions run past 200K tokens, ahead of output caps or idle cache expiry.

Written by the developer behind Preterview, an interview prep platform.