Elvin Peters
- +3%output per working day
- -54%cost per working day
- 5×price of a 750K call vs a 75K call
- 157compactions in 27 days
In this post
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.
- 1M window
- 250K cap
- faded: fewer than 100 calls that day
Why a long chat costs more per message
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.
The change
One line in Claude Code's settings file:
"autoCompactWindow": 250000When 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.
What the numbers did
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.
| Change | Measure | Before, then after |
|---|---|---|
| ↑ +3% | Output produced per working day | 878K tokens, then 901K |
| ↓ -67% | Tokens consumed per working day | 241M, then 79M |
| ↓ -54% | Cost per working day, list prices | $249, then $114 |
| ↓ -42% | Cost per API call | $0.335, then $0.194 |
| 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.
- 1M window, mean
- 250K cap, mean
- dashed: 90th percentile
How the machine reacted
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.
- before the cap: 13 compactions at the 1M edge
- after: 157 compactions at about 220K
I got a sense that the model works differently at the smaller window. In uncapped chats that ran for hours it seemed to get forgetful and a bit dumb, repeating questions it had asked an hour earlier. Capped, it seemed more careful with its work. Fewer questions back to me, fewer tangents, and far fewer of the redundant re-checks and post-checks it liked to run at the full window. Those checks were never expensive in tokens. They were expensive in my time, waiting for a verification pass nobody asked for. The logs are consistent with that impression, since calls per day fell 21% while output held, but they don't prove the mechanism. Treat it as one person's observation.
Why I moved to 500K anyway
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.
The newer models help, for a specific reason
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.
What to do if your Claude bill feels wrong
- Cap the window. In Claude Code it's
autoCompactWindowin settings.json, or/autocompactinside 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. - One task per session. The cap enforces this for you, which is most of its value.
- Hand file-heavy reads to a subagent. In my logs subagents made 26% of the calls and cost 19% of the money, because they start from an empty window every time.
- Match the model to the job. The cheapest call is a small one on any model.
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.
