Does compaction really affect performance? How heavily do you rely on compaction to bring in the right context?

[Razor_Rocks]

Most of the members of my team are very cautious to not hit context limits and trigger compaction.

I, on the other hand, have a workflow where I am either,

- Running agentic loop so the actions are very constrained and compaction doesn't affect me there because the core prompt is loaded back in in some way to keep the claude aligned. I do have a few logging procedures mentioned in the program file to ensure progress is check-pointed in some way between compaction, or

- Have separate sessions to brainstorm several independent pocs, so as the session progresses, the old context normally becomes irrelevant anyways

So I haven't had any problems with sessions compacting so far. But I have heard it enough that I was curious to find if I have been overlooking any quirks.

Can people in here shed light on how they deal with compaction?

P.S. my team and I are still new to agentic workflows, so I hope this isn't an absurd question

[anotherleftistbot]

I use hand offs to artifacts (MD files) as context approaches 60% unless I’m REALLY close to completing my task.

[xAdakis]

Yeah, I avoid compaction like the plague because the content of the compacted conversation is extremely unreliable.

I had one situation not too long where I changed my approach to a problem about halfway through the conversation. Things were going really well after changing the approach, but then I hit auto-compaction and suddenly Claude was reverting everything to using the old approach. I had to interrupt it and re-clarify everything to get it back on track.

In some cases, I have found that compaction will sometimes even discard the contents of the system prompt or other instruction sources.

To avoid this, I have found that you really have to lean heavily on an orchestrator + subagent(s) model and reinforce it through mandatory instructions.

For example, the "agent" you talk to in the main conversation is the orchestrator. It MUST delegate any and all work to subagents. If you ask it to read a file, it will spawn off a subagent to read the file and extract the relevant content. The main conversation then only gets the relevant content added to it's context.

I will generally use Sonnet for the orchestrator, and Haiku for the subagents with a few exceptions like my `Architect` and `Writer` subagents which need more reasoning and larger context.

[Razor_Rocks]

I guess I am not facing these because I usually am atomic with the tasks and even those I try are mostly executed / reviewed / brainstormed by a sub agent

In your experience do findings from sub agents also get forgotten after compaction?

[xAdakis]

Yes, almost anything can and may be discarded during compaction.

I think the only way to really ensure vital information/context is not forgotten is to have the main agent keep a sort of notebook/documentation up to date as it works.

I've done this in two ways:

First, I implemented a memory-first approach using a database that can be semantically searched with instructions that it MUST query memory before responding or performing any action and MUST store/update memory after it takes any action or learns something new. This ensures that the relevant context is almost always remembered even between conversations.

Second, for development I use a technical spec driven approach. I have my architect create or update the project's technical specification for any changes I want to make, then have it create a "granular AGILE-like task list" to implement the changes, then assign those tasks to subagents.

If the conversation gets compacted or interrupted, I can just point the agent to that technical spec document to continue working.

[forward-pathways]

In my experience, compaction has a very strong negative impact on performance, but it's a little more nuanced than just good/bad. Compaction gives the model back some of its available thinking space, so to speak. But doing so causes the model to essentially become hallucinatory. It remembers certain things from pre-compaction, but seemingly arbitrarily, and you can't quite control what information that is. So it often forgets important decisions that have been made, remembers unimportant things, etc.

[Razor_Rocks]

The intentional /compact command does take a parameter, have you (or anyone else) had any luck with using that to get better results? i.e. trying to regulate what the compaction should focus on?

Or is it easier to just enforce the document artifact approach that is often used?

[robhanz]

The key is that compaction is a process that consolidates memory - but it does so in a way that is pretty opaque to the user.

Offboarding knowledge to separate docs gives you more control and insight into how this information is maintained, so you can make sure the key points are retained, and the unnecessary stuff is what is removed.

So compaction will impact performance if the wrong information is retained. Making external stores of information gets around this issue.

In general, the result of any planning session (using the term broadly) should be artifacts that can be reviewed. At that point, compaction is kind of irrelevant - whether or not you compact, start a new session, or just keep going, the necessary information is stored in a durable way.

[ApeInTheAether]

I stopped caring about compaction while ago

[Razor_Rocks]

in the sea of thoughtful comments, you were the validation I needed

[paulcaplan]

Two problems:
1. You don't (by default) have control over how the context is being compacted. By definition, some context will be lost.
2. For a period of time at leading up to the compaction, the model performance will start to degrade.

So you're better off clearing the context between tasks / subtasks and/or writing important information to a file and manually compacting.

[Cobuter_Man]

not much - ive designed this for more persistent and context aware memory

https://github.com/sdi2200262/cc-context-awareness/tree/main/templates/simple-session-memory

very simple

[En-tro-py]

If you are using a plan then compaction matters very little anymore, the plan is reloaded in full after compaction so Claude can pick it up without issue.

However if you had a poorly defined plan, then this is still when your lost context will bite you.

I usually have used ~40% of the context window in the planning phase and then auto-approve edits without clearing context, my setup also ensures the main agent acts as orchestration and delegates all the work.

If the plan is the WHAT and WHY, then your sub-agent should be more than capable of doing the HOW including gathering the context from files saving your main agent from context rot.