Skip to content
DAbuild-your-owncontext-compaction

I don't clear my context anymore

The standard advice was: clear the context and start over. Then I looked at 239 of my own compaction notes — and stopped doing it.

For a year the standard advice has been the same: when your agent gets dumb, clear the context and start over. I've handed that advice out plenty of times myself — and I don't do it anymore.

The point of this post is really just the one line: clearing is amnesia — compacting is a handover. The rest is how I changed my mind, and why I stopped giving the old advice.

A moment in a studio

I was in the Verbos podcast studio recording episode 113 about "loop engineering" when the conversation hit exactly this. Kasper, one of the hosts, said the line we've all been repeating for the past year: clear that freaking context window. And I heard myself answer "I don't do that anymore" — and then I had to explain why.

Here's the stretch of the conversation. The chapters jump to the four turning points.

Verbos #113 — compact vs. clear
2026-06-17
0:00 / 6:30

6½ minutes from the "Loop Engineering" episode where we land on clear-vs-compact. Unedited, in Danish. Transcribed with MAI-Transcribe 1.5.

Listen to the full episode #113 "Loop Engineering" on Verbos Podcast →

Chapters

The line that stuck with me was about compaction, near the end of the clip:

You should compact with some kind of prompt — what is it you actually need to carry forward? So it isn't just random what gets compacted.

I went home and checked whether I did that myself. I didn't.

So I looked at 239 of my own

I have a little tool, pks brain, that reads all my Claude Code sessions. It didn't treat compaction as anything special — a compaction summary just sat in the pile as one long "prompt". So I spent an evening teaching it to tag them: is this a compaction? Did it fire automatically because the context window filled up, or did I type /compact myself?

Afterwards I had 239 real compactions from my own machine to look at. 218 automatic, the rest manual. Across 39 different versions of Claude Code.

The first thing that surprised me: how alike they are.

It's not a summary. It's a form

I thought compaction was a sort of "write a recap of our conversation". It isn't. It's a fixed form with nine fields, in the same order, every time. 214 of the 239 used the exact same nine headings. The output is roughly the same length every time — the median is 14,405 characters. A model that just "summarized freely" would never land that consistently. This is a prompt baked into the tool.

The nine fields are a handover, not a recap:

  • Primary Request and Intent — what we're trying to achieve
  • Key Technical Concepts and Files and Code Sections — what exists, down to file paths and code
  • Errors and Fixes — what broke, and what fixed it
  • Problem Solving — how we reasoned
  • All User Messages — my own words, verbatim
  • Pending Tasks, Current Work, and last of all Optional Next Step

That last field is the important one. The single next action sits at the bottom — the freshest thing in the model's head when it resumes. Here's a real one from the bottom of one of mine (about resuming a timed-out session, of all things):

7. Pending Tasks:
   - Investigate why `claude --resume <sessionId>` causes the "main"
     tmux window to exit immediately

9. Optional Next Step:
   ... the next step is to find the actual command Claude was run with ...

If you need specific details from before compaction (like exact code
snippets, error messages, or content you generated), read the full
transcript at: /home/node/.claude/projects/.../6b3d5582-....jsonl
Continue the conversation from where it left off without asking the user
any further questions. Pick up the last task as if the break never happened.

Notice the last two lines. The summary isn't written for me. It's written for the next instance of the agent, with an order to pick the thread back up as if the break never happened. And it leaves a path back to the full transcript if it's missing a detail. Lossy by default, but never a dead end.

What clear throws away

Here's the number that changed my mind: of my 239 compactions, 239 had a filled-in "Pending Tasks" field and a concrete "Optional Next Step". Every single one. That's the list of what's left and what the next move is — plus the files, the errors, and my own words.

clear keeps none of it. Every time. That's the whole argument in two numbers: 239 to 0.

The best way I can put it: clear is the new shift walking in cold. compact is the outgoing shift leaving a handover note — and the same person carrying on. Most of the time you want the handover.

The one lever I wasn't using

Back to the line from the studio: you should compact with a prompt. It's the only thing you actually control about compaction. Auto-compact runs the fixed form. But when you type /compact yourself, you can hand it a line about what matters to carry forward — so it isn't random what comes along and what gets dropped as noise.

Out of my 239 compactions, I had done that twice. Here's one of them, verbatim:

human prompt
1 lines
Seems like a good place to compact - fokus on what is the next step

Twice out of 239. I left the most important lever untouched almost every time — and it was exactly the one the podcast said you should use. It's probably the simplest habit I've changed since: when I compact on purpose, I add a sentence about where I'm headed.

When clear still wins

I haven't stopped clearing out of religion. There are still times a clean slate is right:

When the thread is done — the task is solved and committed — there's no reason to pay for a 14,000-character handover note that carries nothing forward. When I'm starting something entirely new and unrelated. And when the context is poisoned: I've gone down a hole I don't want to bring along, and a fresh session is the whole point.

And compaction isn't free. It costs an extra model call, it fires automatically whether you want it to or not, and it preserves what better than why — discarded alternatives and the reasoning behind a choice rarely survive. The dangerous failure mode is when a summary is confidently wrong: it doesn't look broken, it looks perfect. So trust the forward-looking stuff — Pending Tasks, the next step, the file list — but re-verify any claim that something works before you build on it.

But the standard advice — clear often — is wrong now. The models have gotten good enough to hold the thread far down the context, and compaction has become a proper handover. So I don't clear my context anymore. I let it compact — and once in a while I tell it where we're headed.