Theo calls Jev instant compaction a terrible strategy
A per tool call probability filter is not compaction, and the cache math runs the wrong way.
tamara posted a Jev demo she called instant compaction, scoring every tool call in an agent thread and dropping the ones that score as irrelevant, with a runnable fast-jev-compaction recipe. Theo took it apart in six points and called it a terrible compaction strategy that fundamentally does not understand how compaction and context management work.
if you think this style of bs filtering on a probability threshold is actually a compaction strategy, I highly recommend you just use the defaults in tools like Claude Code and Codex
Every history edit requires a cache rewrite for ANY data past the history edit.
The objections
His first is definitional. Compaction cleans up history to keep an agent focused and should run sparingly when context gets long, not constantly to keep context small. A filter is not a summary.
Second, Theo says the judge does not know what it is judging. The scoring model works per tool call, carries a 32k token context, and in this implementation does not even see the result of the tool call it is scoring. His predicted failure mode is the agent losing track of what it already tried and falling into repeated attempts at the same thing.
Third, reasoning. Theo notes that 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 drops. He adds that Anthropic requires the entire history to be preserved to get any reasoning data back, so he expects a model in Claude Code to act noticeably worse under this scheme.
Fourth and fifth are economics. Theo says frontier labs have spent the last year training compaction and long runs into the models themselves, and that cache writes are the dominant agent cost, over 60 percent of his personal LLM spend in Claude Code and Codex. Editing history invalidates everything after the edit. Delete item 2 from a history of 1 through 6 and you pay to rewrite 3 through 6, which he argues costs more than leaving item 2 alone.
What he concedes
Theo calls the experiment cool and genuinely interesting, and says the better question is what harnesses and LLMs would look like if they never had to think about KV caching at all. He credits that framing to Diogo in a reply.
This is argument, not measurement. Nobody in the thread posted a token count or a cost delta for the compaction recipe either way, so what is on the table is a mechanism critique against a demo.
For people building on it, the pattern matches Theo's earlier complaint. Jev is being asked to judge an option it cannot inspect, and the sharper limit here is not accuracy, it is that any edit upstream in the history bills you for a cache rewrite of everything downstream.
