In my experience, the best approach to compaction is to never get to the point where you need compaction and to generally stay below about 30% context window utilization. Even for long agentic workflows this can be accomplished for quite a while, much longer than most people might think.
Here's what I do for each of my sessions:
1. For asides, off-topic work, or repetitive work that has already been done in the session, branch backwards (with /tree) and summarize.
2. If I've exceeded 30% or the 'price-doubling' multi-tier pricing, prune (my custom extension).
3. If I've already pruned and I'm still close to 30%, 'prune all' (more extensive prune).
Definition:
'/prune': Removes ~50% context on a fresh session (not previously pruned)
- Keeps: User messages, normal assistant prose, commands/status markers, extension receipts, model settings, and a plain-text receipt for each tool call.
- Removes: Thinking, signatures, actual tool calls/results, tool output, images, compaction summaries, and other extensions’ state.
- Keeps: User messages, normal assistant prose and conclusions, commands/status markers, extension receipts, and model settings.
- Removes: Thinking, signatures, all tool calls/results and output, images, compaction summaries, other extensions’ state, and any tool-activity receipts created by /prune.
Using these I can keep a session going for weeks (or longer), even with extensive use and almost all the important context is preserved while dumping the less important context. Neither command requires an LLM summarization so they execute quickly.
I am surprised at 'removes actual tool calls/results, tool output'. Your approach with /prune seems to be 'keep the WHAT, remove the HOW (we got here)'. I would have thought that the HOW contains some useful signal.
The regular /prune command leaves tool call 'receipts', which includes the command executed and whether it succeeded or failed, but not results. The extended prune removes both.
The how is important, but I've found all of the decisions, question, answers, and results are the most important and the tool calls themselves secondary. When necessary, the tool calls can be deleted without much being lost.
What is that 30% number based on? Surely that's a model specific limit, and is based more on the absolute token length, not percentage, right? I'm not sure it makes sense for e.g. Opus 0.2M and Opus 1M to both degrade at 30% of their respective context lengths.
https://www.producttalk.org/context-rot this article summarises several papers that have explored this, and it does seem to be related to both the absolute number of tokens and the % of the window
People nowdays have no shame and completely forget the art of plug.
What does this mean? I'm not plugging anything.
Shameless plug (link to the repo) of your extension :)
This is terrible. Models have been RLed on looking at the previous tool call chain, and reasoning. No chance this does not reduce performance. The point of compaction is that it also includes useful signal from the tool outputs itself so agent does not repeat it afterwards
Long context windows reduce performance and exceeding your context window is impossible. It should be a given that deleting context.. is just that. You do it when you must to preserve your session without compaction.