What they found
Suman Chatterjee shows that long-running SI coding agents can fail even when the cache still holds the tokens they need. In 100K-token sessions on Qwen3-8B with a 2,048-token budget, one policy kept over 99% of needed tokens, yet its accuracy fell from 93% to 64% as the gap between a definition and its use grew from 2K to 90K tokens. The author's explanation is that the growing rotary-position distance to the query makes those tokens hard to retrieve. PACE combines two parts: the agent's planner tells the cache what future steps will read, and kept tokens are renumbered so their distance to the query stays below 8K. PACE passed 97% of hidden unit tests at 100K tokens, against 42% for H2O and 3% for SnapKV, and 99% and 100% of checks in 1M- and 2M-token sessions on one 24 GB GPU. Each part alone reached 63%. These are the author's reported results, and I have only read the abstract.
Why it matters
SI agents that work for a long time build up far more memory than one GPU can hold, so systems must throw most of it away. This paper says that choosing what to keep is only half the problem. The abstract reports that PACE holds under 0.7 GB of KV state where a full cache would need 147-295 GB. It also says renumbering is exact, costs no measurable perplexity, and adds 9% wall time.
How it changes the race
If the results hold, long-horizon SI agents could run on a single consumer-grade GPU at session lengths that now need far more memory. This lowers the hardware bar for building long-running agents. The abstract tests mainly coding tasks on Qwen3-8B and Mistral-7B, so wider claims are not supported yet.
The abstract, by the authors
Long-horizon LLM agents accumulate sessions of up to millions of tokens, far more key-value (KV) cache than one GPU holds, so serving systems keep a small budget of tokens and evict the rest. Eviction methods differ in which tokens they keep but share one goal: that the tokens a later step needs are still cached. We show this is not enough. In 100K-token coding sessions on Qwen3-8B with a 2,048-token budget, a planner-guided policy that keeps over 99% of the needed tokens resident still fails late steps increasingly often: its accuracy falls from 93% to 64% as the gap between a definition and its use grows from 2K to 90K tokens, at residency 0.996. The needed tokens are resident but unretrievable: what grows is their rotary-position distance to the query. We present PACE (Planner-Aware Context Engine), a KV-cache engine that couples plan-aware retention, in which the agent's planner tells the cache which context future steps will read, with bounded positions, which renumber kept tokens so their rotary distance to the query stays below 8K at any session length. In a pre-registered evaluation on fresh tasks, PACE passes 97% of hidden unit tests at 100K tokens, against 42% for H2O and 3% for SnapKV under the same budget, and needs both components: either alone reaches 63% (the combination beats each, p < 10^-4). The result holds with length: in 1M- and 2M-token sessions on one 24 GB GPU, with definitions written 0.9M and 1.8M tokens before use, PACE passes 99% and 100% of checks and recalls every session fact, while bounded positions without foresight falls from 33% to 13%; PACE holds under 0.7 GB of KV state where the full cache would need 147-295 GB. Renumbering is exact, costs no measurable perplexity, and adds 9% wall time. On Mistral-7B, whose coding ability caps it at 40% even with nothing evicted, PACE stays at that ceiling while retention alone falls below it.
Quoted from arXiv:2611.10240. The research and its words belong to its authors.