One setting, 29,306 API calls before and after, and a bill that fell by half while the work stayed the same. The numbers I can stand behind, and the parts I can only report as impressions.
In August I made one change to how I run Claude Code. I told it to compress its own memory at 250,000 tokens instead of letting a conversation grow to the model's full million. Then I went back through the logs, 29,306 API calls before and after, to see what the change did.
My bill dropped by half. The amount of work coming out stayed the same. This is the case study, with the numbers I can stand behind and the parts I can only report as impressions.
The whole story is visible in one chart. Every bar is a working day, and its height is how much conversation the average call that day carried into the model.
Every time Claude answers, it reads the whole conversation again from the top, and that re-read is billed. So the 400th message in a session costs several times what the first one did, even when the answer is the same length. Anthropic discounts the re-read heavily through caching, but volume swamps the discount. In my logs, 96% of all tokens were the model re-reading conversation it had already seen.
The waste is easy to see once you sort calls by how much history they carried. The top panel is what a call cost. The bottom panel is how much answer came back.
Calls carrying more than 300K of history were a quarter of my calls and half of my spend.
Left alone, a working session climbed to about 575K of conversation by its 200th call and stayed there for the rest of the day.
One line in Claude Code's settings file:
"autoCompactWindow": 250000
When a session nears that limit, Claude Code summarizes the conversation so far and carries on from the summary, and that was the whole change. No extra tools, no change in habits on day one.
My first pass at the numbers said output had dropped 11%. It had, but all of the drop sat in the last week of August, when I was taking time off and barely using the tool. So I cut those days and matched two windows of normal use instead: the fortnight before the cap and the fortnight after it. The comparison below is about the setting rather than my calendar.
| Per working day | 1M window | 250K cap | Change |
|---|---|---|---|
| Output produced (tokens) | 878K | 901K | +3% |
| Tokens consumed | 241M | 79M | -67% |
| Cost at list prices | $249 | $114 | -54% |
| API calls made | 743 | 589 | -21% |
| Output per call | 1,180 | 1,530 | +29% |
| Context per call | 323K | 133K | -59% |
Read the first row and the third row together. The tool produced 3% more per day for 54% less. Per call, the cost fell 42%.
The mechanism is in the session shape. Uncapped, my average call carried 323K of history. Capped, it carried 133K. Calls over 250K went from 45% of all calls to zero. Plot context against how deep into a session each call sat and the two regimes separate completely.
The measured part comes first. Compression fired at 223K on average, which is 89% of the setting, so "250K" means about 220K in practice. Once a session ran past the limit it fired every 50 calls, 3.8 times per session on my usage, and each one took about two and a half minutes. Over the month that was six and a half hours of watching a progress bar. Sessions under 50 calls never hit the limit and ran as they always had, only cheaper.
The 250K cap compressed too often on my biggest tasks. I run a business on this tool, and plenty of the work needs a lot of context in view at once: a client audit that touches thirty files, a campaign build that spans research, copy and setup in one sitting. That's partly on me, because the right fix is to run shorter sessions and hand the reading to a subagent, and the cap was the tool pushing me toward that. But when you're in the middle of something you want to finish it, so I raised the setting to 500K.
I expect that to give back about half the saving. Compression will now fire near 445K, and by the cost curve above, a call at that depth costs about $0.46. I'll re-run the analysis in two weeks and report the number either way.
Two of the three claims people make about the latest models held up in my logs.
| Model | Input $/M | Output $/M | Cache read $/M | What my tokens cost, blended |
|---|---|---|---|---|
| Opus 4.8 | 5.00 | 25.00 | 0.50 | $0.92/M |
| Opus 5 | 5.00 | 25.00 | 0.50 | $0.78/M |
| Fable 5 | 10.00 | 50.00 | 1.00 | $1.82/M |
| Fable 5.1 | 10.00 | 50.00 | 0.25 | $2.63/M on 216 short-session calls |
| Sonnet 5 | 2.00 | 10.00 | 0.20 | $0.30/M |
Opus 5 replaced Opus 4.8 at the same price, so the upgrade was free. Fable 5.1 cut the price of a cached re-read to a quarter of Fable 5's, and since re-reads are 96% of my tokens, re-pricing my Fable 5 traffic at the 5.1 rate takes 36% off it for identical work. Sonnet 5 dropped from $3 to $2 per million on input.
The third claim, that the latest models are more effective, I can't test with a token log. My impression is yes, and I'll leave it as an impression.
autoCompactWindow in settings.json, or /autocompact inside a session. Start at 250K and see how often it compresses. If it's every few minutes, your sessions are too long, and that's the real finding.The setting takes thirty seconds. The analysis behind this post took an afternoon and is reproducible from the Claude Code transcripts on your own machine, so if your numbers come out differently I'd like to hear about it.
I write about running a small business on AI tools here, and the full version of this argument is in my book, The Artificial Advantage.
The Artificial Advantage: the frameworks behind everything here, written for professionals, not programmers.