<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Will Gwyn]]></title><description><![CDATA[Will Gwyn]]></description><link>https://wrg32786.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Tue, 03 Nov 2026 14:42:20 GMT</lastBuildDate><atom:link href="https://wrg32786.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Why I stopped using Claude Code context compaction (and what replaced it)]]></title><description><![CDATA[This is not a post about how compaction works under the hood. There are good write-ups on that already. This is about a narrower question I had to answer…]]></description><link>https://wrg32786.hashnode.dev/why-i-stopped-using-claude-code-context-compaction-and-what-replaced-it</link><guid isPermaLink="true">https://wrg32786.hashnode.dev/why-i-stopped-using-claude-code-context-compaction-and-what-replaced-it</guid><category><![CDATA[Developer Tools]]></category><category><![CDATA[claude]]></category><category><![CDATA[ai agents]]></category><category><![CDATA[llm]]></category><category><![CDATA[Git]]></category><dc:creator><![CDATA[Will Gwyn]]></dc:creator><pubDate>Wed, 28 Oct 2026 05:37:42 GMT</pubDate><content:encoded><![CDATA[<p>This is not a post about how compaction works under the hood. There are good write-ups on that already. This is about a narrower question I had to answer for myself: when an agent runs for hours, is a summary of the conversation the right thing to carry forward at all?</p>
<p>My answer ended up being no. Here's the reasoning, and what I use instead.</p>
<h2>Two different jobs</h2>
<p>Claude Code context compaction is trying to do two jobs at once:</p>
<ol>
<li>Free up room in the context window.</li>
<li>Preserve whatever the agent needs to keep working.</li>
</ol>
<p>The first job is easy. The second is where it gets shaky, because the thing doing the preserving is the same model that is about to lose the details. It's grading its own memory under pressure.</p>
<p>When I split those two jobs apart, the design got simpler. Freeing room is just <code>/clear</code>. Preserving state is a separate, explicit step the agent does on purpose, before the clear, while it still has the full context in front of it.</p>
<h2>Summary vs capsule</h2>
<p>Here's the comparison that convinced me.</p>
<p><strong>A compaction summary</strong> is generated at the moment the window fills. It lives in the conversation. You can't easily diff it, review it, or roll it back. If it dropped something, you usually notice only when the agent does something odd an hour later.</p>
<p><strong>A capsule</strong> in <a href="https://github.com/wrg32786/aigent-os">aigent-os, my alternative to Claude Code context compaction</a>, is a file the agent writes at 80% context and commits to git. It's written while there is still room to think. It has a history. If a resume goes wrong, I can open the commit and see exactly what the agent believed about its own state at that moment.</p>
<p>That last part matters more than I expected. Debugging a bad resume used to be guesswork. Now it's reading a file.</p>
<h2>Making the clear safe</h2>
<p>The obvious risk with replacing compaction by clearing is that you clear too early and lose everything. So the handoff has two hard checks.</p>
<p>First, after the capsule is committed, the agent prints an exact ack line. The runner, which lives outside the agent, only sends <code>/clear</code> when it sees that exact line. No fuzzy matching.</p>
<p>Second, after <code>/clear</code>, the runner waits for a SessionStart receipt before it tells the new session to resume. That way it knows a fresh session is really there.</p>
<p>Capsule, ack, clear, receipt, resume. Each step has a signal, and nothing moves on without it.</p>
<h2>Failure modes I watch for</h2>
<p>Being honest about this is the only reason it's useful to anyone else.</p>
<ul>
<li><strong>A thin capsule.</strong> The protocol guarantees the handoff happens. It doesn't guarantee the capsule is good. If the agent writes "continuing work on the task," the next session has very little to go on. Clear instructions about what a capsule must contain help a lot.</li>
<li><strong>Known open issues.</strong> aigent-os is at v1.1.0. There are open issues for known limits, #104, #98, and #99. If you're evaluating it, start there.</li>
<li><strong>Not everything needs it.</strong> For a 20 minute session, compaction or a manual clear is fine. This is for agents that run long enough that drift becomes a real cost.</li>
</ul>
<h2>Where this runs</h2>
<p>I didn't build this as an experiment. Four agents run parts of my actual business: The AIgent newsletter with around 9k subscribers, courses, an avatar video engine that posts to Instagram, ad deals, Meta ads, and email funnels. Titus oversees, Pheme owns the newsletter business, Davinci builds and designs, and Metis handles task assignments and clerical work. Those are workflows where a forgotten decision costs money, which is why compaction drift was worth fixing.</p>
<h2>How to think about it</h2>
<p>If you're deciding between compaction and something like this, I'd ask one question: can I inspect and trust what the agent carries across the gap? With a summary, mostly not. With a committed capsule, yes.</p>
<p>You don't need my repo to apply that idea. A PreCompact hook that writes a handoff file gets you part of the way. A runner that owns the clear and waits for explicit signals gets you the rest.</p>
<p>If you want a working version to read or borrow from, it's at <a href="https://github.com/wrg32786/aigent-os">github.com/wrg32786/aigent-os</a>. I'd genuinely like to hear where it breaks for you.</p>
]]></content:encoded></item></channel></rss>