A few days ago I tested three Claude Code token-saving tools, and all three raised my cost. So this time I stopped testing tools and measured where my cost actually comes from.
How I measured
- My local Claude Code session logs, numbers only, 7 days (about 4,400 model calls per day)
- Cost-weighted tokens: input 1, cache write 1.25, cache read 0.1, output 5
Where it goes
| Where | Share of daily cost |
|---|---|
| Cache reads (re-reading context every call) | 66% |
| Cache writes | 18% |
| Output | 15% |
- The average call carried about 184K tokens of context. Calls with more than 200K were 56% of the cost.
- The median session starts at about 62K tokens before I type anything (system prompt, instructions, tool and skill lists).
- Cache breaks cost 6.5%. Three quarters of that came after a gap of more than 60 minutes.
- Command output was about 6.8% and file reads 2.6%. That's why compressing tool output didn't help me.
- Moving bulk work from subagents to plain scripts cut subagent cost by 78%.
- My manager session (the one that coordinates other sessions) costs 11.3% per day. My hooks cost 0.8%.
Replaying my real calls with different habits
| Rule | Upper bound | Expected (half, for re-reading) |
|---|---|---|
/clear + short handover when context passes 150K |
−29.0% | about −14% |
| Start fresh after a gap of more than 60 minutes | −14.8% | about −7% (overlaps with the above) |
| Trim the always-loaded context from ~62K to ~32K | −9.4% | about −5% |
| All three | −42.6% | about −21% |
I keep auto-compact off and use /clear with a handover note, because a compacted conversation can't be undone.
Full numbers: https://github.com/awesomefred0827-hash/claude-token-log/blob/main/FINDINGS-2026-10-08.md
Questions
- When do you
/clear: at a token count, at a task boundary, or after a break? - Has anyone measured how much re-reading a fresh session needs after
/clear? That decides whether my "half" assumption is too optimistic.
Top comments (2)
Your trim row checks out against the table. Taking 30K off the always-loaded prefix is 30 / 184 = 16% of the average context, and cache reads are 66% of cost, so the ceiling is about 0.16 × 66 ≈ 10.8%. Your 9.4% sits just under it, which is what you'd expect if some calls run below 184K. That also makes it the cheapest of the three rules, because it needs no change in habit and applies to every call.
One place that 62K can come from, which a log of tool output won't show, is tool definitions. A large tool list is paid on every call, and picking the right tool from a long list is its own failure mode. In our case we measured 306 tools exposed directly at about 34,508 tokens, against 1,109 tokens through three front tools that search the rest on demand. If your 62K contains MCP servers you rarely use, a per-server token count would show how much of the 30K you could trim is there.
That is what canli-mcp does for market and filings data: free, MIT, no key, runs locally (
npx -y canli-mcp, repos at github.com/arhancanli/canlicapital and github.com/arhancanli/alphac). I built it.On your question: after /clear I'd measure the rereading per task type, not on average. A handover note is read at full price once and then cached, so the "half" probably holds for tasks that need the same files and fails for ones that don't.
yep, almost the same shape in 33 days of mine: cache reads 62%, cache writes 29%, output 8% ($4,560 API-equivalent). The big difference is the writes, 29% against your 18%. Every one of my main-session cache writes was the 1-hour kind, which costs 2x the input price against 1.25x for the 5-minute one, and I think that's most of the gap. Your finding that the breaks happen after gaps over 60 minutes is the flip side of it, the 1h cache only pays if you come back inside the hour.
Not measured the re-read after /clear yet, but it's going on my list. :)