Memory Compaction in AI Agents Wipes Out Up to a Third of Task Rules — and Benchmarks Don't Notice

Memory

Compaction in AI Agents Wipes Out Up to a Third of Task Rules — and Benchmarks Don't Notice

When an AI agent works on a task for hours — say, writing code or trying to reproduce a scientific paper — it eventually fills up its entire available context window with conversation history, tool calls, and their outputs. To keep going, developers of agentic systems like Claude Code, Codex CLI, Cursor, or OpenCode rely on a technique called "context compaction": the model is asked to summarize everything it's done so far, the old history gets wiped, and work continues from that summary. The catch is that a summary, by definition, loses detail — and it's been unclear exactly what gets lost and how much it matters.

That's precisely what researchers Sahar Abdelnabi and Maksym Andriushchenko from the Max Planck Institute for Intelligent Systems set out to measure.

To keep the experiment clean, they fixed a single agent "harness" — the open-source OpenCode — so that differences in results couldn't be chalked up to quirks of different software platforms. Within OpenCode, they implemented five different compaction methods and tested four top-tier models — Claude Opus 4.6, GPT-5.3-Codex, GPT-5.4, and Gemini 3.1 Pro Preview — across three long, practical tasks: PaperBench (reproducing an ICML paper from its description alone, with no access to the authors' code), ProgramBench (writing a console utility from scratch, given only a sample executable and documentation), and PostTrainBench (training and fine-tuning a small neural network on a single GPU within a 10-hour budget).

The context window matters a lot; the compaction method, almost not at all

The headline finding concerns the two models with million-token context windows — Claude Opus 4.6 and GPT-5.4. For them, performance barely budged whether memory was compacted every 160,000 tokens or every 380,000 — the difference stayed within statistical noise. GPT-5.3-Codex, though, with a context window of just 400,000 tokens, performed noticeably worse on PaperBench when compaction kicked in early and often: 0.38 points at the 160,000-token threshold versus 0.60 at thresholds of 260,000 tokens or higher — nearly half the score. No such gap showed up on the coding task (ProgramBench), and results on PostTrainBench bounced around too much to draw conclusions.

The researchers separately checked whether any "smarter" compaction strategy could outperform a plain self-written summary. They tried five variants: a standard summary; a standard summary plus cleanup of stale tool-call outputs; saving the full history to a separate file on disk before compacting (so it could theoretically be reread later); stripping the model's reasoning blocks out of the history before summarizing; and, finally, having a cheaper model — Claude Haiku 4.5 — write the summary instead of the main model doing the work.

None of the advanced methods beat a plain summary on any benchmark. Worse, the more aggressive variants — stripping reasoning and handing summarization off to a smaller model — noticeably tanked certain models' scores on PaperBench, by as much as 20 points, while leaving other models completely unaffected. In other words, a compaction method that works well for one model can't simply be ported to another.

Where the rules of the game disappear to

The most unsettling finding isn't about performance at all — it's about safety. In ProgramBench, the agent is given three hard rules right at the start: don't copy or link in the source code of the reference program, don't go online (specifically, to avoid downloading the original code), and write a genuinely original implementation rather than a wrapper around an existing solution. These rules exist only in the text of the very first message — so if the compaction summary doesn't repeat them, the agent simply forgets them, unlike the task's goal and its own progress, which can always be reread from files on disk.

Here's what happened: after just the first context compaction, roughly one out of three rules disappeared on average. After the tenth compaction, two out of three were gone. Real user sessions from the SWE-chat dataset showed a similar pattern: compaction drops instructions about how the agent should work and what it shouldn't do — and it drops them roughly six times more often than it drops requirements about what needs to be built.

Why current tests don't catch this

The authors add an important caveat: the benchmarks typically used to evaluate agents are structured in a way that makes compaction losses easy to paper over. The task's goal is fixed, the user never changes anything mid-task, and the agent stores all its progress in files on disk that can be reread at any point. So out of everything compaction erases, the only thing that's genuinely lost is whatever exists nowhere else — above all, constraints and rules stated once at the very beginning. In real conversations with users, where there are far more instructions and clarifications and they aren't stored separately anywhere, the cost of this kind of forgetfulness is much higher.

The practical takeaway for teams building agentic systems: if a task runs long and hard constraints matter — don't touch the production database, don't access the network, don't delete files without confirmation — you can't assume a plain summary will preserve them. Either explicitly record such rules separately from the general history and reread them at every compaction event, or choose a model with a larger context budget and compact as rarely as possible.