Robert Ta argues that hand-rolling compaction for LLM agents is flawed. Jev's line-by-line approach loses reasoning context and can cause infinite loops, while aggressive filtering cripples frontier models like Claude. Cache writes cost over 60% of LLM spend, and custom filtering degrades performance more than using built-in platform defaults.
So this person found the perfect use case for Jev instant compaction. In 2026, why is compaction still a summarization prompt? Jev can make it instant by scoring every tool call and dropping what's irrelevant. Here's Theo that came back. So it seems like a lot of people are confused. So let's break this down. This is complete misinformation, by the way. If you're an AI builder, don't think about Jev for compaction. Compaction is not a filter. The role of compaction is to clean up history to keep the agent focused, not just deleting noise. Should be used sparingly when context gets too long. Number 2, Jev doesn't even know what it's deciding on. So models use the context of the thread to decide what to keep or not to keep. That's model-specific, harness-specific. This implementation goes through on a line-by-line per tool call basis to decide what should be left or deleted. Not only does this 32K token context model know very little about what happened before, but in this implementation, it doesn't even know what the result of the tool call is. Deleting these things randomly will keep the model from knowing what it's tried and dooms you to end up in stupid loops where the model keeps trying the same thing over and over. Number 3, you're giving up the reasoning entirely. Frontier models from OpenAI, Anthropic, xAI, and Google do not share reasoning traces over the API. They share encrypted payloads, which Jev cannot see, and often will drop. Anthropic is even stricter with this, requiring you to preserve the entire history in order to get any of the reasoning data. As a result, using this in Claude code guarantees the model will act way dumber. Number 4, models are tuned on their compaction flows. For the past year, Frontier Labs have been including compaction and long runs as part of the training process. These models have learned ways to compact that are more effective than any rudimentary solution. Fun fact, if you switch models in Codex and compaction is necessary, compaction will run on that model that was previously used in the thread. Why? Because models are tuned on their compaction flows. Number 5, cache writes are more expensive than cache reads. Cache writes are the biggest cost by far for agents. I often see cache write costs go over 60% of my total LLM spend in my personal use of Cloud Code and Codex. Cache writes are insanely expensive when data earlier in the history has changed. Every history edit requires a cache rewrite for any data past the history edit. If your history is 1, 2, 3, 4, 5, 6, and you delete 2, you have to rewrite 3, 4, 5, 6. This is more expensive than leaving 2 in the history. But good news, since we're already killing all the reasoning tokens by doing the stupid compaction strategy, the rewrite cost won't actually be that high. So in this case, you do get some benefit for using this stupid tool for the stupid non-tool for A non-problem. Number 6, the implementation is hot garbage. Whatever is not kept is deleted permanently, but the assistant can always rerun a tool or reread a file. Good luck with that one. To be clear, this is a cool experiment. I think it's genuinely interesting. That said, if you think this style of BS filtering on probability threshold is actually a compaction strategy, highly recommend you just use the defaults in tools like Cloud Code and Codex. You're much less likely to hurt yourself that way. Well, I think the tone is a little off, but honestly, you kind of deserve it for spreading misinformation at scale. So try better next time, I'd say.
