Claude Code
Claude Code autocompact: what to set the window to
The autocompact window is the single biggest lever on how far your plan goes. Most people have never touched it, and the default quietly costs heavy users most of what they pay for.
If you use Claude Code all day and keep running out, you have probably tried the usual advice: read fewer files, write shorter prompts, turn off unused tools. We measured all of it. Most of it barely matters.
One setting matters more than everything else combined, and it ships switched effectively off.
What autocompact actually does
Claude Code carries your whole conversation with it. Every turn sends the entire history again, so a message you sent this morning is still being paid for at five o'clock. It is discounted, because it is cached, but it still counts against your limit and it is charged again on every single turn that follows.
Compaction is the fix. When the conversation reaches a threshold, Claude Code summarises everything so far and continues from the summary. The history stops growing, and each turn goes back to being cheap.
The autoCompactWindow setting is that threshold. It accepts anything
from 100K to 1M tokens.
Why the default costs you so much
By default, Claude Code compacts when the conversation reaches the model's context limit. On a model with a one million token window, that means a long session may never compact at all.
So the lever exists, it is switched off, and nothing tells you. You just hit your limit sooner than you think you should and assume that is what the work costs.
Here is the shape of it. In one real session of 866 turns, a single file opened at turn 93 was still being sent with every request until the session ended:
That is not a bug and it is not waste in the usual sense. It is simply how a conversation works. But it means the cost of a session grows roughly with the square of its length, and nobody's intuition accounts for that.
What we measured
We rebuilt four months of real usage from transcript data, 6.3 billion tokens across more than 13,000 API calls, then simulated what different compaction windows would have cost. The simulation reproduces the actual recorded usage to within 0.00 percent, so the counterfactuals are arithmetic rather than guesswork.
| Compaction window | Saving | Worst case |
|---|---|---|
| 200k | 76% | 41% |
| 250k | 72% | 50% |
| 300k | 67% | 50% |
| 400k | 60% | 45% |
| 600k | 44% | 32% |
| 1M (roughly the default) | 0% | 0% |
The worst case column assumes summaries come back three times larger than we measured and that every compaction costs twenty wasted turns rebuilding context. Even under both of those pessimistic assumptions at once, a 250k window still returns half of what the default burns.
Why trimming tool output does almost nothing
This is the part that surprised us, and it contradicts what most optimisation tools sell. We capped every tool result in the same dataset and measured again:
| Cap on each tool result | Saving |
|---|---|
| 8,000 tokens | 1.5% |
| 4,000 tokens | 3.4% |
| 2,000 tokens | 6.9% |
| 1,000 tokens | 11.2% |
The reason is in one number. Of all the context that accumulated, only 26 percent came from outside: tool results, file reads, your own prompts. The other 74 percent was the model's own reasoning and replies, which cannot be trimmed without changing the work it does.
So if a tool promises to save you a fortune by shortening what Claude reads, the ceiling on that is a few percent. Compaction timing is where the order of magnitude lives.
Not sure what your own number is?
The right window depends on how you actually work. UsageOptimizer reads the transcripts already on your machine, works out the value for your usage, and sets it. If your sessions are short and there is nothing to gain, it says so.
One payment of $50. No subscription, and nothing leaves your machine.
Get UsageOptimizerRuns on macOS, Windows and Linux. Needs Node 18 or newer.
The setting is not the hard part
The window is configurable inside Claude Code. That part takes a few seconds.
The hard part is the number, because there is no single right answer. It depends on two things that vary enormously between people: how fast your context grows, and how large your summaries come back. Both are properties of how you work, and neither is visible to you while you work.
Get it wrong in either direction and you are worse off:
- Too high and nothing changes. You carry on burning through your plan exactly as before, except now you think you have fixed it.
- Too low and you spend the day repeating yourself to a model that keeps forgetting what you were doing. People who try this by hand usually overshoot here, decide compaction is not worth it, and give up on the one lever that actually works.
The table above shows the spread. On this dataset, 250k returned 72 percent and 600k returned 44 percent. That is a difference of real money every month, decided entirely by a number you cannot guess from the outside.
And these are one person's figures. Yours will be different, because your sessions are not this person's sessions.
When autocompact seems not to be working
Four things account for almost every case:
- Something else is overriding your value. Settings apply in a priority order, and a value set at a higher level silently wins. On a work machine this is often a policy you did not set and cannot see.
- It compacts constantly. The window is close to the size of the summary itself, so it fills up again the moment it finishes. This is the failure people notice, and it is why so many conclude compaction is not worth it.
- It never compacts at all. The window is above what your sessions ever reach, so the setting is doing nothing. This is the failure nobody notices, and it is the expensive one.
- You cannot script it. Compaction fires on the threshold. There is no hook, no trigger and no way to automate the timing yourself, which is exactly why the threshold is the only lever that exists.
The first two are visible. The third is not, and it is where most of the money goes.
The trade off nobody mentions
Compacting more often means a shorter memory. Claude will occasionally re read a file or ask about something it already knew. Our worst case figures charge you twenty wasted turns for every compaction, and the gains still hold, but no measurement can tell you whether the answers themselves got worse.
That part only you can judge. Set a window, work with it for a week, and see whether you notice. If you do, raise it. The difference between 250k and 400k is real money either way, and it is worth ten minutes of attention.
Or let it work the number out for you
UsageOptimizer measures your own history, stress tests every candidate window against pessimistic assumptions, and only recommends what survives. Then it sets it, and you can check afterwards whether it worked.
Get UsageOptimizer, $50 onceOne payment. No subscription. Runs entirely on your own machine.