How Does Compaction Work in Builder?
Today I shipped the 0.10.0 update to Builder CLI, and it landed huge improvements to compaction and cache efficiency.
Why Builder’s Compact Is Better Than Native
By default, when you go through onboarding, Builder recommends the local proprietary compact, which is far more detailed than the native one. Native compact can still be selected or configured in the config file if your provider supports it. I recommend local - here’s why.
The native compact algorithm for Claude Code and Codex was reverse-engineered a long time ago, and it’s literally 5 - 7 lines of instructions along the lines of: “write a description of the work, idk, make no mistakes.” I reverse-engineered the native compact myself to make sure of this and to pull out the best parts.
The only real advantage of native compact is preserving reasoning traces from previous conversation, but that can be achieved another way (described later). The local compact in Builder uses a carefully crafted prompt that I’ve been polishing for several months, covering all the important details that affect the agent’s ability to continue working. Because of this, the compact can survive literally dozens of sessions without losing the overall task context. I have large refactors that ran autonomously through more than 37 compacts in a row, all night long - without any issues.
All of Builder’s code is open source, so you can read the prompt. But without the harness improvements I also made for the compact, and without the ability to change this prompt in official harnesses, it won’t get you very far.
Example: Builder ran through 22 compacts
The compact in Builder is also better than the original because it saves the entire conversation history no matter how many compacts you’ve had - but the model only sees the fresh history. That means you can roll back 19 compacts at any point, start a new conversation, fork it, and go off into a separate branch. On top of that, unlike some providers, Builder preserves cache, so it ends up being much cheaper. This is offset by the fact that my compact is more detailed - but as I’ve said, Builder’s main goal is quality, not price tag or speed. In future versions I plan to optimize the compact so it contains nothing unnecessary and costs less than other providers.
Proactive Compact - New in 0.10.0
Beyond the prompt itself, the compact in Builder is proactive. Version 0.10.0 ships the first experimental tool that lets the model decide on its own when to run a compact. The model in Builder knows it has limited memory, knows how much space is left, knows when to make checkpoints - and gets a notification about remaining context.
Enable via:
[tools]
trigger_handoff = trueAnd this isn’t implemented the way it is in Claude Code, where it freaks the model out and it refuses to work. And not the way Codex does it, where it constantly stops to “take a breather.” In Builder, it’s just one of the agent’s autonomous processes - one that doesn’t cause unnecessary pauses or degrade work quality!
Proactive compact prevents losing changes, breaking builds, tests, or overwriting your decisions in situations where the model runs out of context and compact gets triggered at a bad moment - causing it to forget that it has a file partially edited or a spec half-implemented. In my tests, the model knows on its own when it needs to hand off to the next agent, and prepares the workspace for that, which makes agent-to-agent collaboration across compacts much better.
Plus, the main agent can pass what’s called a letter to the future to the next agent. The general compact prompt, especially the native one, often doesn’t include specific things from the model’s internal reasoning - things it knows but hasn’t gotten to implement yet. Since reasoning traces aren’t saved, my solution lets the model save them itself and pass them forward.
Builder prepared for compact, passed instructions for saving important info, triggered native compact, and continued working
Pre-Compact Before Starting a Task
Another UX improvement you won’t find in other harnesses: pre-compact before starting a task. The harness constantly checks, whenever you send any command to the agent, whether there’s enough context to complete the task - and based on heuristic analysis decides: should the task run now, or should it compact first and then move on to the next part of the plan?
This way your command is saved directly, doesn’t go through an LLM summarization loop, doesn’t waste tokens, and the agent starts fresh with clean context and no hallucinations. This lets you just talk to the model without thinking about compaction - the harness figures it all out alongside the model, freeing you from having to manually trigger slash commands or worry about hitting the “dumb zone.” This is enabled by default.
Queues Across Compacts
The last improvement I really love - queue support across compacts. Your prompts, slash commands, and any processes, including background subagents, can survive compacts and transfer ownership to the next agent without any loss.
For example, you can queue up: right after a task completes - a compact with a custom prompt, then a slash command, and also spin up three background subagents. When the compact finishes, the model automatically receives your prompt, the summary, the message from the previous agent, your slash command, and the output from all three subagents - and picks up from that point as if nothing happened. No lost information, no stops, no limits on what you can do while the agent is running.
This seriously simplifies the workflow: give the agent a task, immediately schedule a compact, and then tell it to open a pull request and fix the comments in it with background agents for planning and execution. You won’t find this in any harness out of the box. Maybe some allow it through hooks, but Builder’s advantage is that all of this is implemented natively - with maximum integration out of the box.