On Jev-Scored Compaction: A Critique

That the scorer never sees what it is scoring. The implementation judges history line by line, per tool call, without the tool's result in the prompt, so a 32k-context model is deleting things largely at random from its own point of view, which is how you get loops redoing work it already did.

It is a real mechanism, not just taste. Editing history invalidates the prompt cache for everything after the edit, so dropping item two of a six-item history forces a rewrite of items three through six, and cache writes are the dominant line item in long agent runs. Filtering can cost more than the tokens it saves.

The author does not say that. He calls it a cool experiment and genuinely interesting while rejecting the strategy, and his recommendation is practical: use the built-in compaction in tools like Claude Code and Codex, whose models were trained on their own compaction flows rather than a homemade filter.

No. The critique argues from the implementation's design, what the code deletes, what it refuses to preserve, and how it handles encrypted reasoning payloads, with no loop rate, token cost, or task-success numbers for the approach. Read it as a strong design objection from someone who did not instrument it.

The reasoning. His third point argues frontier models from OpenAI, Anthropic, XAI and Google return encrypted reasoning payloads rather than plain traces, so Jev cannot read them and will often drop them. He adds that Anthropic is stricter still, requiring the entire history to be preserved to expose any reasoning data at all.

Because the frontier labs trained for it. His fourth point is that compaction and long runs have been part of model training for the past year, so those models have learned compaction behaviour. He notes as a fun fact that if you switch models in Codex, compaction runs on the model previously used in the thread.

He does not think so. The critique quotes the claim that whatever is not kept is deleted permanently but the assistant can always re-run a tool or re-read a file, then answers good luck with that one and calls the implementation hot garbage. His position is that losing the record of what was tried is what produces the repeated-work loops.