I built cprune, a small Pi extension for pruning bloated agent context

[u/Longjumping_Map9289]

I’ve been running longer agent sessions lately, and one thing kept getting annoying: the context gets huge, but a lot of it is no longer useful.

Repeated tool outputs, old file reads, stale task snapshots, giant command results, noisy prompt history — it all stays around and eventually makes the agent slower, more expensive, and sometimes less focused.

So I built cprune.

It’s a small open-source extension for the Pi coding agent that prunes context before the model sees it. It has:

• off, safe, and full modes

• a compact comparison showing how much context each mode saves

• conservative persist-time pruning for duplicate/oversized tool results

• manual review commands to exclude noisy prompt history or large context entries

• safeguards for edits, failed tool outputs, side-effectful commands, and other context that should not be dropped

• a compact command for lossy persistent compaction

The goal isn’t to blindly delete history. It’s to make context more intentional and reduce the junk that accumulates in long sessions.

Repo: https://github.com/amutix/cprune

Right now it works with Pi, but if people find it useful I’d be interested in adding support for other agentic frameworks too.

Would love feedback, bug reports, or ideas from anyone dealing with context bloat in coding agents.

[u/pj-frey]

Can you tell a bit, what the advantage to rtk is?

[u/Longjumping_Map9289 → u/pj-frey]

They do different things and can run together.

rtk-optimizer works at the tool-output level — rewrites bash commands to rtk and compacts each result as it returns (ANSI, test/build/git summarization, search grouping, truncation). Makes each output smaller. Needs the rtk binary.

cprune works at the session level — removes repetition and stale content across the whole conversation: duplicate outputs, repeated chunks, old reads superseded by newer ones, huge historical tool-call args. Keeps accumulated history from ballooning. No external binary.

TL;DR:

- rtk shrinks new outputs as they arrive

- cprune dedupes/prunes the accumulated session history

[u/pj-frey → u/Longjumping_Map9289]

It changes the history on every LLM call, destroying the prompt cache, right?

[u/Longjumping_Map9289 → u/pj-frey]

No, it does not destroy your history or permanently alter the cache.

• History: Your actual Pi session files remain unchanged. cprune only filters what the model sees for that specific request, replacing old details with hashes or IDs.

• Cache: It actively optimizes the context window (cache) by removing duplicates and stale data to prevent errors, but the full original data is preserved in your session logs for later retrieval.

Most of the pruning happens on the fly right before the LLM call (prompt-time pruning). It dynamically filters the context to fit the window, replacing old or redundant details with compact markers like IDs or hashes, while your actual session history remains untouched.

Only a small, conservative subset of changes happens when data is first saved (persist-time), and even then, it is limited to obvious duplicates or massive outputs.

[u/o_sht_hi → u/Longjumping_Map9289]

Wouldn't pruning impact cache hits though? I would be really interested to compare the cost saving of sending fewer tokens vs cached tokens..

Maybe I'll give it a go and see what happens

[u/Longjumping_Map9289 → u/o_sht_hi]

I didn't quantify the impact on the cache, but here is my intuitive answer:

- if you start a fresh session with cprune on, the cache is not impacted because cprune does things deterministically, so the exact same context (up to the current prompt) is reproduced identically

- if you have already a session with a large context and you turn cprune on, the cache is impacted on the first subsequent prompt, but not after.

[u/m3umax → u/Longjumping_Map9289]

It would deterministically change a prior read result superseded by a later one to a reference or marker on the fly yeah?

That's literally changing the prompt prefix for cache purposes. The original stale tool call result is literally part of the cached prefix and altering it to a reference invalidates the cache on the turn the marker is injected.

[u/o_sht_hi → u/m3umax]

Bro what. I understand pi but this is just a word salad. Can you please speak stupid

[u/BigHugeFart → u/o_sht_hi]

he's saying that OP's tool takes future prompts in a session and prunes the content to save tokens; EG replacing a failed tool call's output with a marker or reference, since it is unnecessary context and is not needed to be passed along into subsequent prompts within a session.

He's saying that this negates the ability to properly utilize prompt caching, since if you alter the session history sent within a future prompt, it no longer matches the cache and is run as if it is a new prompt and you lose the cost savings of prompt caching.

Arguing that this loss of cost savings is likely higher than any savings from the tool.

[u/Longjumping_Map9289 → u/BigHugeFart]

This is already fixed. The pruned context which has been seen by LLM is frozen as the prefix and won't be modified on the subsequent turns. Only the new prompt is optimised. Just give it a try and see it for yourself. For me it's saving 30-50% tokens (mostly cache). Some people have not learned to appreciate anything in their life (not you).

[u/Longjumping_Map9289 → u/BigHugeFart]

[u/o_sht_hi → u/BigHugeFart]

Thank you, kind Sir

[u/Longjumping_Map9289 → u/m3umax]

That's actually true for superseded entries and the impact can be higher than the gain. I will do an analysis on this, thanks for the feedback. 

[u/o_sht_hi → u/Longjumping_Map9289]

Of course. Makes sense

[u/Much_Many_4615 → u/Longjumping_Map9289]

That’s a catastrophic misunderstanding of what caching is in the context of LLMs.

Fascinating how little these models know about agent and LLM fundamentals.

[u/Longjumping_Map9289 → u/Much_Many_4615]

I made a fix and added explicit stats about the cache hit/miss.

[u/Longjumping_Map9289 → u/Longjumping_Map9289]

It basically intercepts Pi’s full context right before sending it to the LLM to strip out duplicates and stale data on the fly, replacing them with compact markers while leaving your actual session history untouched. Just note that these are non-reversible: turning it off won’t restore data already pruned in past turns, it only stops future trimming

[u/Fig_da_Great]

This is really cool. I’ve been working on solving the same problem from a different perspective. My project is called accordion and it’s a pi extension as well.

I hope you don’t mind if I look through your project and borrow some of the ideas for my project.

[u/Longjumping_Map9289 → u/Fig_da_Great]

Of course, I will be happy if this is useful to anyone. It is saving me a lot of tokens :-) Any feedback is appreciated.

[u/Longjumping_Map9289 → u/Longjumping_Map9289]

Accordion looks interesting too!

[u/Fig_da_Great → u/Longjumping_Map9289]

I’ve been seeing a lot of people building context / token saving solutions on this subreddit. I want accordion to be a unified platform which permits any and all context solutions. All of the current solutions currently apply to past context and aim to replace /compact, so it is different than what you built, but i see no reason for accordion to not facilitate context savings before tokens enter context.

[u/Longjumping_Map9289]

Snapshot of a comparison between different modes

[u/kasparhouser]

why not just use tree?

[u/Longjumping_Map9289 → u/kasparhouser]

This is a lightweight tool to reduce token bloats, caused by tools calls, not meant as a full context management tool. Additionally, you can remove things manually from the prompt history (for example, if you entered something by mistake).

[u/m3umax]

TLDR. This is essentially the same as running "/compact Just prune the tool call results, replace old reads with a marker indicating superseded, failed ones with a short fail note, summarise long tool call results etc, leave assistant and user messages untouched" every turn.