I've been leaning on Claude Code hard for a few weeks, with long sessions and lots of sub-agents. I wanted to know where the money actually goes, so I priced every call in my logs at list price. 954 of my 7,802 calls sent more than 400k tokens of context. Those 12% of calls cost 31% of the total.
What I counted
Claude Code keeps a .jsonl file per session under ~/.claude/projects. Each API call is logged with its token counts: input, cache writes, cache reads and output. The same message can show up on several lines, so I counted each message id once.
I took a call's context to be input plus cache reads plus cache writes. Then I priced everything at Anthropic's list prices as of 26 Oct. Opus 5.5 is $4 in and $20 out per million tokens, with cache reads at $0.20. I'm on a plan, so treat these as API-equivalent figures.
The result
band calls % calls cost % cost
<100k 2787 35.7% $114.83 20.3%
100-200k 2898 37.1% $174.04 30.8%
200-400k 1163 14.9% $101.71 18.0%
400k+ 954 12.2% $174.78 30.9%
That's $565 across all the logs. Sub-agents were $289 of it, a bit over half. Output tokens barely matter. Nearly all the cost is context being sent again and again.
Every call re-sends the whole conversation. Cache reads are cheap per token, but at 400k tokens a call even the cheap rate adds up. A session that runs past a few hundred thousand tokens pays that price on every turn after.
The other thing I noticed was limits. I hit the 5-hour limit on 14 separate occasions in about two weeks. In the 5 hours before each one I'd used between roughly $19 and $43 of list-price usage. That spread is too wide to say anything about the limit from my logs alone.
What I'd try, though I haven't tested it: clear the session when a task is done instead of carrying on. Start the next task from a short summary. Use a cheaper model for sub-agents that only read and search. I haven't measured whether any of that saves money yet.
Run it on your own logs
I put the script on GitHub: ctxtax. It's one Python file with no packages to install, and it only reads local files. It prints numbers, never message text.
curl -O https://raw.githubusercontent.com/TrueHorison/ctxtax/main/ctxtax.py
python ctxtax.py
A few limits. It's three weeks of my kind of work. List prices aren't what subscribers pay. The 400k cut-off is my choice. And it only reads Claude Code logs.
The thing I can't work out alone
The usage-limit threads are full of "my limit feels smaller" with no way to compare. python ctxtax.py --meter prints one line per limit hit: the day, the usage in the 5 hours before it, and the model mix. It prints numbers only. If a few people paste theirs in the comments, we'd have a record we can actually compare.
What share of your cost comes from the 400k+ calls?
Written with AI help.
Top comments (4)
The split I'd want is per call, with the size of the context each call re-sends next to its cost. A few calls with a large context usually carry the larger share of the spend, and sub-agents make that worse. Once those calls are visible, sending less back is the lever to try first, before a model change.
Ran the same thing on my last 30 days (since 29 Sep, each message id once, same list prices). 33,957 calls, $3,009.
400k+ was 12.4% of my calls and 24.5% of the cost. So nearly your 12%, but less of the money. Mine sits in the middle instead: 200-400k is 42% of calls and 41% of cost, and hardly anything runs under 100k (9% of calls).
Sub-agents were $1,722 of my $3,009. 57%! Against your $289 of $565. Which makes me think the 400k line isn't really the thing, it's how many helpers you start, because every one of them starts big. The first request of mine is a median 52K tokens before it's done anything.
From your untested list, I'd do the cheaper sub-agent model first. Clearing the session when a task's done is worth it too, mostly for the gaps: 207 times in 33 days I came back after the cache had expired and paid $972 to write the whole thing again.
Your untested idea is the one that worked best for me. In my own logs a reply late in a long session cost about 3.3 times one in a short session for the same kind of work, so I started ending sessions with a short handover (what was done, what is left, what to watch out for) and opening a fresh one from it.
The catch is the handover itself: if it leaves out how the project builds and last week’s traps, the new session spends its first minutes re-reading the repo and gives part of the saving back. A small notes file per project that every session reads first fixed that for me.
Nice breakdown. Did the 400k+ calls cluster in long sessions, or in sub-agents reading big files? That decides whether clearing sessions or limiting file reads is the fix.