Blast Radius: Predicting How Far a Prompt Reaches Before You Pay For It

Paper: 2608.07440 Authors: MY Pitsane, Hope Mogale Categories: cs.AI

The Gap

Everyone building coding agents hits the same wall: the context window fills, and then you have to throw something away. The existing answers are all reactive and lossy.

Sliding windows and truncation drop the oldest turns regardless of whether they mattered — you lose the stack trace from turn 3 that explains the bug you’re chasing in turn 40. Recursive summarization (the MemGPT / self-editing-memory lineage) compresses old turns into prose, which is a one-way door: “there was an auth error” does not get you back the line number. RAG-style memory retrieves by embedding similarity, which helps recall but keeps no account of what was evicted or why, and chunking is itself lossy. KV-cache eviction work (H2O, StreamingLLM, SnapKV) is rigorous but operates at the attention-token level, below the semantics of “this transcript is dead,” and is likewise irreversible. And on the code side, most agents either dump a repo map or let retrieval decide, with no budget on how far into the dependency graph a given request is allowed to reach.

So there are two unaddressed boundaries. First, eviction is treated as an accident (we ran out of room) rather than a prediction (this request will never touch those files, so don’t load them). Second, eviction is treated as destruction rather than a reversible operation with an address you can come back to. Blast Radius attacks both.

PROBLEM:  agentic coding burns tokens
          context grows > window fills > truncate or summarize > info lost
             |
             v
PRIOR:  [sliding window]  [recursive summary]  [RAG recall]  [KV eviction]
         lossy tail        lossy + one way      no ledger      token level
             |                 |                   |               |
             +-----------------+---------+---------+---------------+
                                        |
                                        v
ASSUMPTION: a prompt's future reach is predictable *before* expansion
            and dead context is identifiable *and* highly repetitive
                                        |
                                        v
METHOD:  [radius estimator: context channel + code channel]
         [NECROPHORESIS: verbatim reversible burial]
         [RDM: detect + bury recurring transcripts]
         [formal layer: Polish context space ~ entropy vs resurrection]
                                        |
                                        v
EVIDENCE: 7 OpenAI models  ==>  -17% to -26% tokens
                                lowest overflow rate among tested policies
                                450 buried / 378 RDM / 0 recalled
                                byte exact restore verified
                                        |
                                        v
CLAIM:    eviction can be cheap *and* reversible
          caveat: 0 recalls means the reverse path never ran under load

The Increment

One sentence: Before this paper, context management was damage control after the window overflowed; after it, you estimate how far a prompt will reach *before loading anything, and everything you drop goes into a byte-exact archive with an address instead of into a shredder.

Core Mechanism

Three parts, stacked. The blast radius estimator takes an incoming prompt and predicts its reach along two independent channels. The context channel asks how deep into the transcript this request needs to go — a follow-up like “now do the same for the other file” reaches back a few turns; “why did we choose this schema?” may reach back forty. The code channel asks how far into the codebase it propagates — editing a docstring has radius one, renaming a public interface has radius equal to every importer, transitively. The output is a reach budget, and that budget becomes an *admission control decision: records inside the radius get loaded, records outside never enter the window at all. This is the part that saves tokens, and it saves them on the input side, before generation.

NECROPHORESIS handles what’s already in the window and has gone dead — records with no live reach under the current radius. Instead of summarizing them (lossy) or truncating them (gone), it archives them verbatim with a key. The claim, and the paper verifies it, is byte-exact restoration: what comes out of the archive is bit-identical to what went in. Eviction becomes a move operation rather than a delete.

Recurring Dead Matter (RDM) is the dedup layer. In real agent loops the same dead content shows up over and over: identical tool outputs, repeated file headers, the same failing test log, boilerplate system preambles re-injected each turn. RDM identifies transcripts that recur and buries them permanently rather than paying to re-evict them each cycle. Empirically this dominated: 378 of 450 buried items were recurring dead matter, which tells you most context bloat in agentic coding is *repetition, not novelty.

Underneath sits a formal layer: contexts live in a Polish space so that conditional probabilities are guaranteed to exist, eviction is modeled as a measurable map with a measurable inverse on the archive, and context entropy is tied to resurrection probability — the more unpredictable the context stream, the more often you should expect to go dig something back up.

        incoming prompt
              |
              v
    +===========================+
    |   BLAST RADIUS ESTIMATOR  |
    +===========================+
      |                        |
      v                        v
 [channel A: context]     [channel B: code]
  turns / transcripts      files / imports / defs
      |                        |
      +----------+-------------+
                 |
                 v
      reach budget  R = < r_ctx : r_code >
                 |
      +----------+-----------+
      |                      |
      v                      v
 ADMIT inside R          DENY beyond R
      |                      |
      v                      v
 live working set        never loaded (token savings)
      |
      | staleness cue: no live reach under R
      v
 +=======================+  bury   +=======================+
 | NECROPHORESIS         | ------> | ARCHIVE / midden      |
 | verbatim eviction     |         | byte exact + key       |
 +=======================+ <------ +=======================+
      ^                   resurrect ( observed count: 0 )
      |
 +=======================+
 | RDM DETECTOR          |
 | recurrence count n    |
 | n >= k  ==>  bury deep|
 +=======================+

 layer above:  [ HCRC governance ]
 layer below:  [ Blast Radius: who gets buried + how far to reach ]

Now the metaphor — and the authors handed it to us, since necrophoresis is the real behavior of ant colonies removing dead nestmates from the nest.

Think of the agent as an ant colony. The nest chamber is the live context window: finite, crowded, expensive to keep clean. A task order arrives (the prompt). Before the colony mobilizes, scouts assess how far this job actually extends — how far out into the terrain (the codebase, along import trails) and how far back along the existing pheromone trails (the transcript). That assessment is the blast radius, and it determines how many workers leave the nest. A colony that sends every ant in every direction for every crumb starves; that is today’s agent loading the whole repo map for a typo fix.

Inside the chamber, some occupants are dead — records that no live trail leads to anymore. Undertaker ants carry them out *intact. This is the load-bearing distinction: they do not eat them, chew them up, or compost them into something smaller. Composting would be summarization — lighter to store, impossible to reconstruct. Instead the bodies go to the midden, the refuse pile outside the nest, laid out and labeled, so if the colony ever needs one back it can be carried in unchanged. That is NECROPHORESIS and the byte-exact archive.

RDM is the colony noticing that the same corpse keeps blowing back into the chamber — the same tool output, the same log — and burying it deep in the midden instead of re-carrying it out every hour. And the striking empirical fact fits the metaphor uncomfortably well: real ants essentially never retrieve from the midden. Zero of 450 bodies were recalled. Either the undertakers have excellent judgment about what is truly dead, or the colony maintains a carefully labeled graveyard it never visits.

Key Concepts

• Blast radius of a prompt: the set of things a request will actually end up touching before it’s done — both conversation history and source files. The point is that this is *estimable in advance from the request’s shape. “Fix the typo in this docstring” touches one file and zero prior turns. “Rename UserSession to Session” touches every file that imports it, plus everything those files re-export, plus the tests. Same length prompt, radius differing by three orders of magnitude. Today’s agents largely load the same amount of context for both. If you can classify the request into a radius bucket, you can set a budget instead of discovering it by overflowing.

• Reversible eviction (and why verbatim beats summarized): normal eviction is a delete; a summary is a lossy compress. Both are one-way. Reversible eviction is a *move with a forwarding address — the record leaves the window, goes to cheap storage, and a key stays behind. The test that matters is whether restoration is bit-identical, because near-identical is useless for code: a stack trace missing its line numbers, a diff missing its hunk headers, a JSON payload with reordered keys. Concretely: turn 3 dumps a 4000-token failing test log. Summarize it and you keep “test_auth failed on token expiry.” Twelve turns later the agent needs the exact assertion values. Summarized: gone forever, and the agent re-runs the test at full cost. Archived verbatim: one key lookup, byte-identical, no re-execution.

• Polish space, and why anyone would drag topology into this: a Polish space is a space that is *not weird in two specific ways — you can approximate any point using a countable list of reference points (separable), and any sequence that keeps getting tighter actually converges to a point that is still in the space (complete). The real numbers are Polish; so is the space of infinite text sequences under a reasonable metric. Why bother? Because the conditional probability you want to write down — “given the current memory state, what is the chance this specific buried record gets resurrected?” — is not guaranteed to exist on arbitrary measurable spaces. Polishness is the standard hypothesis that makes the disintegration theorem apply, so conditioning is well-defined. It licenses statements like “high context entropy implies high resurrection probability” rather than making them hand-waving. Honestly assessed: this is bookkeeping hygiene, not the paper’s engine.

Framework Shift

Before (mainstream approach):        After (this paper):

 prompt                              prompt
   |                                   |
   v                                   v
 load everything plausible          estimate reach R first
   |                                   |
   v                                   v
 window fills                       admit only inside R
   |                                   |
   v                                   v
 O V E R F L O W                    evict dead -> ARCHIVE
   |                                   |     (verbatim + key)
   v                                   v
 truncate / summarize                restore on demand
   |                                   |
   v                                   v
 info gone (one way)                 state recoverable (two way)

 reactive + lossy                    predictive + lossless
 cost discovered at runtime          cost budgeted up front

From reactive lossy compression to predictive reversible relocation, the core shift is: stop asking what do I delete now that I am out of room and start asking how far does this request actually reach, and where do I park everything outside that radius so I can get it back unchanged.

Framework Shift, One Line

Eviction stops being a failure mode and becomes an addressable operation.

Expert Assessment

Caveat up front: I am judging from the abstract and the numbers it reports, so treat the method-internals commentary as a reading rather than a full audit.

Problem choice: Real gap, not manufactured. Token cost dominates agentic coding economics, most of the waste is context you loaded and never needed, and prior work is genuinely split between lossy compression and unaccounted retrieval. The predictive-scoping framing is where the field is heading — Aider’s ranked repo map and various agent budgeters gesture at it without formalizing it. Good instincts on the target.

Method maturity: A clever insight wrapped in far too much costume. The load-bearing ideas are two: predict reach before loading, and make eviction a move rather than a delete. Both are sound and both are cheap to implement. But the paper is carrying a lot of weight it doesn’t need: “NECROPHORESIS,” “buried bodies,” “resurrection probability,” “Algosophy,” and an undefined “HCRC” that the reader is expected to know. Neologism density this high usually signals a system being branded rather than positioned, and it actively obscures how much overlaps with existing work — MemGPT already pages between a main context and an external archival store. The differentiation is real (predictive rather than reactive, verbatim rather than summarized, plus recurrence detection) but the paper’s naming makes it harder, not easier, to see.

And there is a simpler approach hiding in plain sight. If 378 of 450 buried items are recurring transcripts, then a content hash plus provider-side prompt caching captures a large share of that win with almost none of this machinery. I would want an ablation isolating RDM-alone against plain dedup and against prefix caching, because it is plausible that most of the 17-26% comes from the boring dedup component rather than the radius estimator or the reversibility layer.

Experimental integrity: Mixed. Seven models is decent breadth but all from one vendor, which is a problem when your headline metric is token consumption — tokenizers, cache pricing, and system-prompt overhead differ across providers, and the effect could shrink or grow on open-weight models you can actually instrument. The abstract never says what the *task suite is, and for agentic coding that is the number that matters most: a 20% token reduction is worthless if task success drops 5%, and the abstract reports no quality metric at all. “Lowest overflow rate among tested policies” is only meaningful with the policy list, and comparing against LRU/FIFO/sliding-window is a much softer bar than comparing against a tuned summarization agent.

The zero-recall result deserves a hard look. It’s presented as vindication, but it is ambiguous in an important way. Either the eviction policy is genuinely precise, or the evaluation runs were too short and too shallow for anything buried to ever be needed again — in which case the entire reversibility apparatus, the paper’s most distinctive contribution, was never exercised in the loop and only verified offline. Those two readings have opposite implications for whether NECROPHORESIS earns its complexity, and the abstract does not let you distinguish them. I’d want long-horizon runs with deliberate callbacks, plus a report of what happens to task success when resurrection is disabled entirely.

Writing quality: The formalism section is where the corners got cut in the direction of *more rather than less. Invoking a Polish context space is legitimate — you need it for conditional distributions to exist — but as presented it reads as rigor-signaling rather than doing work, because nothing in the reported results depends on the topology. The entropy-to-resurrection connection is the interesting formal claim, and it should have been the centerpiece with an empirical curve attached: measure context entropy, measure resurrection rate, show the relationship holds. Instead, with zero observed resurrections, the theory’s key prediction is untestable against the paper’s own data. Rewriting that section around a falsifiable, measured entropy-recall relationship would elevate the whole paper from a system report with vocabulary to a contribution with a spine.

Verdict: borderline — the two core ideas are genuinely useful and the token savings are plausible, but the evaluation omits any task-quality metric, the zero-recall headline may quietly mean the reversibility mechanism was never actually needed, and the theoretical layer is decorative rather than predictive.

Takeaways

Things worth stealing regardless of what you think of the paper:

Budget context reach as an admission-control problem, not a garbage-collection problem. Classify incoming requests into radius buckets before retrieval fires. Cheapest possible version: a small classifier or even a heuristic that routes “single-file edit” vs “cross-cutting refactor” to different retrieval budgets. Most of the win is in never loading, not in cleverly dropping.

Two channels, not one. Reach along the conversation and reach along the code graph are genuinely independent axes and most systems conflate them into one relevance score. A request can be shallow in code and deep in history (“why did we do it this way?”) or the reverse. Separating the budgets is a small change with immediate effect.

Make eviction a move, and make byte-exactness the acceptance test. This is the most transferable piece. Summarize-to-forget is popular because it’s easy, but verbatim archive plus a key is cheaper than people assume — cold storage is orders of magnitude below context tokens — and it eliminates a whole class of agent failure where the model re-runs an expensive tool because the output was summarized away. Test it the way the paper does: round-trip and diff bytes, not embeddings.

Instrument recurrence before you build anything sophisticated. The 378/450 finding is the most actionable number in the paper: most context bloat is the same content arriving repeatedly. Hash your context records and count duplicates over a week of real traffic. If your distribution looks like theirs, plain dedup plus prefix caching may get you most of the way, and you can skip the rest.

Transferable framing: “blast radius” is a good name for a general question that shows up well beyond context windows — in CI test selection, in incremental build scoping, in permission granting. *Estimate the reach of an operation before authorizing its cost. That framing is worth more than this specific implementation.