u/chocolateUI

Back in February, I was reverse engineering Claude Code's source code from the minified JS bundles shipped on NPM. Over a series of turns, we had progressively built up a map of the codebase: what symbols meant, what different functions did under the hood, the main conversation loop, reverse-engineered Ink TUI modules, permission system, etc.

Then the context got filled up, OpenCode's compaction kicks in, and the entire conversation was compacted. All tool calls, all file reads and writes, all the decisions we made and secrets we uncovered gets replaced with a single summary blob generated from OpenCode's compaction prompt.

Of course, I had my agent constantly document its findings and recreate source files whenever possible, but that wasn't enough. After compaction, the agent woke up with basically no memory of the codebase at all. The quality fell off a cliff. All symbol mappings, structural inferences, module separations, hours of untangling minified garbage, all flattened into a generic template that captured maybe 10% of what mattered. It started re-reading the same minified files, re-deriving the same mappings we'd already worked out, undoing everything.

Thus, I decided to build a better replacement for OpenCode's built-in compaction system.

Comparison

The core idea was simple: standard compaction destroys information because it tries to summarize the entire conversation at once into a single Markdown summary. But what if you kept the conversation structure intact and only compressed the parts that actually needed it?

That's what Magic Compact does. It preserves every user message, replaces old assistant turns with lean summaries, and strips out large tool I/O into a cache while keeping the tool calls themselves visible. The conversation reads like the original, just condensed. Same flow, same decisions, same memory.

The difference in agent quality post-compaction is night and day. Per-turn summaries preserve the thought process and decisions for each turn, so the agent retains its working memory instead of waking up blind. It knows what files it explored, why it made certain choices, what the user actually asked for. Pruned tool calls means maximum savings, and past results can be reread from the cache at any time.

And since compaction is basically lossless in quality, you can run it way more aggressively than built-in compaction. I run /magic-compact constantly. Whenever I'm implementing adjacent features, I would compress after each feature and work on the next. If I'm working on a multi-phase plan, I would compact after each major phase. If I'm mid-implementation, I can pass an argument to keep the last few turns and only prune earlier ones.

In addition to lossless compression for long conversations, Magic Compact also helps me make my coding plan last at least 2-3x as long. For anyone on coding plans, this is a big deal. I've probably saved hundreds of billions of cached read tokens and thousands of dollars in billed token costs, letting me code 2 or 3x as much than before using the cheapest plans from Z.ai and OpenAI.

I've been using Magic Compact daily since March and it's become an integral part of my workflow, and today I've decided to open source it to share with the community.

UI

Install it now with:

opencode plugin magic-compact --global

Run /magic-compact [N] to compact, where N is the number of recent assistant turns to keep. If not provided, by default N = 0. Run /magic-stats to see token and accumulated cache read savings for the current conversation.

Magic Compact is also open source, fully open to contributions and feedback: https://github.com/aerovato/magic-compact

PS: You may have also heard of another plugin called OpenCode DCP; while DCP asks the model to periodically summarize conversations via distracting prompt injections which results in constant cache churn, Magic Compact takes a different approach: comprehensive compacting and pruning of the entire conversation on your command.

Compared to DCP, Magic Compact is much more cache and token friendly with its aggressive summarization while being better at preserving quality. Magic Compact also doesn't periodically inject notices into the conversation, forcing the agent to compact and invalidate caches, so your agent stays 100% on task. You can use Magic Compact as a superior replacement over DCP.

Back in February, I was reverse engineering Claude Code's source code from the minified JS bundles shipped on NPM. Over a series of turns, we had progressively built up a map of the codebase: what symbols meant, what different functions did under the hood, the main conversation loop, reverse-engineered Ink TUI modules, permission system, etc.

Then the context got filled up, OpenCode's compaction kicks in, and the entire conversation was compacted. All tool calls, all file reads and writes, all the decisions we made and secrets we uncovered gets replaced with a single summary blob generated from OpenCode's compaction prompt.

Of course, I had my agent constantly document its findings and recreate source files whenever possible, but that wasn't enough. After compaction, the agent woke up with basically no memory of the codebase at all. The quality fell off a cliff. All symbol mappings, structural inferences, module separations, hours of untangling minified garbage, all flattened into a generic template that captured maybe 10% of what mattered. It started re-reading the same minified files, re-deriving the same mappings we'd already worked out, undoing everything.

Thus, I decided to build a better replacement for OpenCode's built-in compaction system.

Comparison

The core idea was simple: standard compaction destroys information because it tries to summarize the entire conversation at once into a single Markdown summary. But what if you kept the conversation structure intact and only compressed the parts that actually needed it?

That's what Magic Compact does. It preserves every user message, replaces old assistant turns with lean summaries, and strips out large tool I/O into a cache while keeping the tool calls themselves visible. The conversation reads like the original, just condensed. Same flow, same decisions, same memory.

The difference in agent quality post-compaction is night and day. Per-turn summaries preserve the thought process and decisions for each turn, so the agent retains its working memory instead of waking up blind. It knows what files it explored, why it made certain choices, what the user actually asked for. Pruned tool calls means maximum savings, and past results can be reread from the cache at any time.

And since compaction is basically lossless in quality, you can run it way more aggressively than built-in compaction. I run /magic-compact constantly. Whenever I'm implementing adjacent features, I would compress after each feature and work on the next. If I'm working on a multi-phase plan, I would compact after each major phase. If I'm mid-implementation, I can pass an argument to keep the last few turns and only prune earlier ones.

In addition to lossless compression for long conversations, Magic Compact also helps me make my coding plan last at least 2-3x as long. For anyone on coding plans, this is a big deal. I've probably saved hundreds of billions of cached read tokens and thousands of dollars in billed token costs, letting me code 2 or 3x as much than before using the cheapest plans from Z.ai and OpenAI.

I've been using Magic Compact daily since March and it's become an integral part of my workflow, and today I've decided to open source it to share with the community.

UI

Install it now with:

opencode plugin magic-compact --global

Run /magic-compact [N] to compact, where N is the number of recent assistant turns to keep. If not provided, by default N = 0. Run /magic-stats to see token and accumulated cache read savings for the current conversation.

Magic Compact is also open source, fully open to contributions and feedback: https://github.com/aerovato/magic-compact

PS: You may have also heard of another plugin called OpenCode DCP; while DCP asks the model to periodically summarize conversations via distracting prompt injections which results in constant cache churn, Magic Compact takes a different approach: comprehensive compacting and pruning of the entire conversation on your command.

Compared to DCP, Magic Compact is much more cache and token friendly with its aggressive summarization while being better at preserving quality. Magic Compact also doesn't periodically inject notices into the conversation, forcing the agent to compact and invalidate caches, so your agent stays 100% on task. You can use Magic Compact as a superior replacement over DCP.

I've been using GLM-5.2 heavily over the past few days, and in terms of programming ability it's right there at the frontier. Its ability to write quality code, spot bugs, and handle complex reasoning tasks is basically on par with the best closed-source models from maybe 2 months ago and I have high hopes for the future of open models.

But I've been noticing a worrying behavior in open models that most benchmarks don't capture: thinkslop.

I've been using GLM through their coding plan since December, first 4.7, then 5, 5.1, and now 5.2, and with every release, this problem has gotten worse. Every time I ask GLM to perform a non-trivial task, GLM hesitates, second-guesses itself, and runs through endless internal reasoning chains about whatever the fuck instead of just doing something.

>Ok, let me do this...
But wait, what about this...
Actually let's see...
Wait, but then...

Ok, now let me write this
<drafts entire code section>
But wait... actually nevermind lol

Alright, now for this file, I would do this:
<drafts another code section>
...

And then, after all that thinking, it finally writes the actual answer. I've had cases where GLM burned through five times the tokens that GPT-5.5 needed for the same output because it was stuck in this loop of overthinking and considering non-existent edge cases because it is afraid of making mistakes.

Compare that with GPT models, especially 5.5, which almost never does this; it understands immediately what it has to do and just does it. It writes solid code by default without needing to draft everything out first or verify every branch or think about every single edge case.

I believe that this happens because current open models have less "intuition" or innate intelligence compared to closed models. Open models have less built-in instinct for what the right approach is, so instead of relying on their instincts, they compensate by doing more runtime "searching" or "thinking".

For those who are interested in chess programming, it's almost as if open models have a worse evaluation function, so it has to do more tree searching to keep up with engines with better evaluation functions on the leaderboard.

Unfortunately, I think this last frontier may be one that is very hard to overcome. Intuition in LLMs seems to come from good training data. Labs like OpenAI, Anthropic, and Google have insane amounts of money that they can throw around and use to generate quality data that these open labs in China just can't replicate. We already know they're doing this through companies like Scale AI or Mercor that pay PhDs $80/h just to solve random problems and generate reasoning traces.

In addition, since OpenAI and Anthropic have a dominant position in enterprise in AI coding markets, they can continue using their position to generate a continuous stream of high-quality real-world data that the Chinese labs just can't do.

And because of that, I think that this intuition gap may be here to stay and I think that we shouldn't get our hopes up yet about open models surpassing closed ones.

But that's just speculation on my part. What do you all think? Do you think that this intuition gap can be closed soon, or if there even is an intuition gap at all?