Why I Turned Off Auto-Compact

One line in my settings that surprises people:

{
  "autoCompactEnabled": false,
  "model": "opus[1m]"
}

Auto-compaction is the feature that keeps a long session alive. When the context window fills, it summarises what came before and continues with the summary. Without it, long sessions eventually hit a wall.

I turned it off anyway. Here is the actual trade.

What compaction costs

Compaction is lossy, and the loss is invisible.

Everything before the compaction point gets replaced by a summary. The summary is good — it keeps the decisions, the file paths, the current task. But it is a summary, so it drops detail, and you do not get told which detail.

The failure mode is specific: the assistant becomes confident about something that is now wrong.

Say early in a session you established that a bug only reproduces when a particular Cloudflare setting is on, then ruled that out as the root cause. Post-compaction, the summary might retain "investigated Cloudflare settings" but lose "and eliminated them". Twenty minutes later you are back to Cloudflare, because as far as the current context knows, that thread is unresolved.

You will not notice this happening. You will notice work getting subtly worse and assume you are having a bad session.

What running out costs

Nothing, actually. That is the part that changed my mind.

Hitting the limit is loud. The session stops, you see it, and you deal with it deliberately — start a fresh session with a summary you wrote, or fork the conversation from before things got long.

Loud failure beats quiet degradation. A wall you can see is easier to work around than a slow leak you cannot.

This is the same instinct behind turning off any automatic recovery that hides a problem. The recovery is not free; it just moves the cost somewhere you are not looking.

The million-token caveat

Fair disclosure: opus[1m] is a one-million-token context window. That is a lot of room, and it makes this position much cheaper to hold than it would be on a smaller window.

With a large window, a normal working session — read a dozen files, make changes, run tests, iterate — does not come close to the limit. Compaction would rarely fire anyway, so disabling it costs me almost nothing and removes a whole class of confusing behaviour.

On a smaller window the calculation genuinely differs, and auto-compaction may be the right default. This is a preference, not a universal recommendation.

What replaced it

Three habits, none of them clever.

Start sessions narrow. One task per session. The instinct to keep a long-running session going because it "knows the project" is backwards — it knows the project and three abandoned approaches, a stack trace from a bug you fixed, and a file you read for unrelated reasons. Fresh context with a good opening prompt beats accumulated context almost every time.

Write things down outside the window. This is where the memory vault earns its keep. If the important conclusions from a session are in a note on disk, losing the conversation stops being expensive. The window becomes working memory rather than the system of record.

Delegate the reading. When something needs a lot of file reading — where does this pattern appear, what does this subsystem do — that is a subagent's job. It reads thirty files in its own context and hands back a paragraph. Thirty files never enter my window, so the thing that fills windows fastest stops filling mine.

The third one is the highest leverage by a wide margin. Most context exhaustion is file-reading, and most file-reading can be delegated.

When I do compact

I still compact — manually, at a moment I choose.

Good moments: a distinct phase just finished, tests pass, the next task is different from the last one. Compacting there means the summary is written at a natural boundary, and I can read it and correct it before continuing.

The difference is not summarisation versus no summarisation. It is who chooses the boundary. Automatic compaction fires when a token counter crosses a threshold, which is uncorrelated with anything meaningful about the work. Half a debugging session on one side and half on the other is the worst possible cut.

Should you turn it off?

Probably not, immediately.

If you are on a standard context window and your sessions routinely hit the limit, auto-compaction is doing real work and removing it will just make sessions die.

The transferable idea is not the setting. It is noticing that a feature marketed as convenience is making a decision for you — what to forget — at a moment it chooses, without telling you what it dropped. That is worth knowing about even if you leave it on.

If you want one thing to try: next time a session feels like it has gone strange, check whether it compacted. The correlation is higher than you would expect.

Next: which MCP servers actually earn their place in a working setup.