Instead of compaction, has anyone seen a successful implementation of pruning? That is, the agent looks at the conversation history and removes any low-value messages.

For example, sometimes context will be taken up by a side tangent, tool call outputs, or low-value codebase exploration.

Much of the time, I prefer to preserve the history of my conversation instead of summarizing it. I find summarized conversations lead to more frustrating future chats because the LLM misses intent and or context. (Or, the presence of paragraphs and paragraphs of LLM output makes the next token predictor dumber? Unsure.)

I have a few variations of pruning (trimming all long tool outputs, agent-directed trimming, etc) in my aichat collection of session tools:

https://pchalasani.github.io/claude-code-tools/tools/aichat/...

It is kinda a combination of the two:

https://github.com/spott/pi-task-compaction

I’m still playing with it, but it essentially has the model define a region, and mark it with begin_task, and end_task. End_task also requires a fairly hefty summery of the entire region.

It then pulls that entire region and replaces it with the summary. If the model wants it can actually look into the output that was pruned from the conversation, but in practice the summaries have been good enough it hasn’t needed to.

I’ve been using it with 5.6 sol, and even really long sessions have like 6% context used at the end.

I'm very interested in this too. I feel like when my Claude session compacts I immediately have to re-alert it to critical aspects of the task, but it should be possible even to have a secondary low-skill agent crawl over the whole context window semi-continuously and nominate pieces for removal or summarization. Or at a higher level, have something able to decompose, like hey I realised we're actually working on three distinct aspects of this problem, let's split the context into those three and I'll just retain a high level summary of what's in the other ones, enough to know if I should pass off control to one of the others for a particular ask.

I feel like this is kind of subagents, but it doesn't have the clear task -> work -> return result -> die model, rather it's more closely aligned to how I myself multitask, maintaining several long-lived threads of execution, and having to intentionally "forget" about the other ones when it's time to lock in and do real work on the most important one.

I think there are a lot of strategies that will open up when costs come down but right now you take a hit on cache rate and thus costs every time you do anything other than wait until the last minute to compact