2608.07440-Blast Radius

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Blast Radius".

Jane: The paper was written by MY Pitsane and Hope Mogale from Algorithm Reconnaissance Division and Mankind Research Labs and North-West University and University of Pretoria.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Paper summary: Tom: Welcome back to the show. Today's paper attacks a cost that anyone who runs an eye coding agent has felt directly — every turn re-submits the whole conversation, the system prompt, the file dumps, the diffs, and the stack traces, and you pay tokens for all of it, every single time.

Jane: And the painful part is that most of that history stopped mattering long ago. The paper opens with a perfect example — a file pulled into context on turn three to fix a typo, still riding along on turn forty, charging you on every resubmission.

Tom: Right. They call that dead context, and they've built a memory-management layer that gets rid of it by burying it. Before a turn runs, the system estimates how far

Page 1 of the paper: Tom: So to recap where we landed: the paper opens with a painfully familiar observation, that an agentic coding loop re-submits its entire history on every single turn, and most of that history is dead weight by turn forty.

Jane: And page one is where they name the fix. Blast Radius — the estimate of how far an incoming prompt will reach, before the turn actually runs.

Tom: The name is doing real work. There are two channels. The context channel asks how much new context this turn will retain, which sets how much eviction you need. The code channel asks which files and symbols the edits will touch, through the dependency graph.

Jane: So both are asking the same question — what's causally coupled to what I'm about to do? One over tokens, one over code structure.

Tom: What struck me is how they frame the alternatives as lossy. Sliding-window truncation just drops the oldest tokens whether or not they were load-bearing. Summarization compresses history through another model call, and if it compresses something that mattered, you can't undo it.

Jane: Right, both trade a recoverable cost for an unrecoverable one. You save tokens but you destroy information. That's the whole argument for reversibility.

Tom: And the counter-move is to estimate the blast radius first, then perform a forgetting operation whose downside is bounded by construction because it's exactly reversible. If you're wrong, you just dig it back up.

Jane: They're also positioning this beneath an existing framework called HCRC. That gate decides whether a record may replace context at all — verification has to settle something as concluded. Blast Radius decides what to bury and how much headroom to reclaim.

Tom: So one layer says "you may only forget what verification has settled," and the other says "here's the settled dead mass, here's the cheapest reversible sweep." It's a clean division of labor.

Jane: And the teaser in the abstract — 17 to 26 percent token reduction, 450 bodies buried, zero exhumations. That makes me want to look under the hood at how they actually decide something is dead.

Tom: That's exactly where the paper goes next — the formal definition of liveness, and the math that turns "this context is probably dead" into a license to bury it.

Page 2 of the paper: Jane: Right, and the way they carve the space is refreshing. The attention-level tricks like StreamingLLM or H2O all work inside a single forward pass, evicting key-value entries that are just gone. Blast Radius works one level up, on whole messages between turns, so the two aren't even competing.

Tom: And that's the key distinction, isn't it. A cache policy compresses within a turn, Blast Radius decides what survives between turns. They're complementary layers, not rivals.

Jane: They also give credit to MemGPT's paging intuition — treating context like virtual memory, swapping between a working set and external storage. But they highlight two load-bearing differences. First, their eviction is lossless: the archived body is byte-exact, not a summary, so exhuming it restores the original rather than a lossy reconstruction.

Tom: Second, eviction is licensed by the HCRC gate, not triggered by a length heuristic. So something gets buried only after verification has settled it as concluded. That's a huge safety property that MemGPT-style approaches don't have.

Jane: And RAG gets an interesting framing too. RAG pulls external knowledge in on demand; their burial is the dual operation — pushing transient session knowledge out to a store keyed by a scent skeleton, then pulling it back only if a later prompt's blast radius says it's needed.

Tom: The scent skeleton stays resident as a retrieval key. It's like leaving a bookmark where the full page used to be.

Jane: The code channel, meanwhile, descends from change-impact analysis in software maintenance, where you estimate which parts of a program a modification touches. Blast Radius adopts that reachability formulation but weights it by realized churn and renders it as a live pressure signal instead of an offline report.

Tom: So they're not just borrowing scattered ideas. They're deliberately positioning Blast Radius as the scoping layer that sits under the HCRC gate — verification licenses what you may forget, Blast Radius decides exactly what to bury and how much headroom to reclaim.

Jane: Which naturally raises the question — how do you actually formalize what's dead and what's alive? That's where the next page takes us, with the definitions of liveness, death, and the resurrection probability.

Page 3 of the paper: Jane: So we've seen how they define liveness and death — the tricky part being that you never actually know if a body is dead at eviction time.

Tom: And that's exactly where page five picks up — deciding which bodies to bury, given you're working with predictions, not certainties.

Jane: They frame it as a knapsack problem. You need to reclaim a certain number of tokens before the next turn, and each candidate body has a size you can reclaim and an expected regret — the chance you're wrong times the cost of exhuming it. So you pick the cheapest bodies to sacrifice.

Tom: The greedy approximation makes sense — sort by tokens reclaimed per unit of regret, take the best ones first. But the more interesting part is what happens when they look at production telemetry and realize this whole framework misses something big.

Jane: Right — recurring dead matter. An agentic session isn't a stream of unique missions. It's a loop. The agent greps the same symbols, reruns the same test suite, rebuilds the same project, over and over. Each of those transcripts is near-identical to the one before, and each one dies the moment the next one arrives.

Tom: They call that recognizing the class rather than the instance. You strip out the volatile content — counters, timings, hashes — and keep the generator and stable head. Any transcript with the same normalized signature belongs to the same recurrence class.

Jane: Then comes the clever part. For each class, the system keeps the newest member alive, because that one carries the current state of the routine. Every older member is buried on sight, no threshold, no census wait. And the resurrection probability for the class is estimated by Laplace's rule of succession — essentially the fraction of buried instances that ever came back, smoothed.

Tom: The safety net is that burial is reversible. Even if a class gets misclassified as dead, the worst case is one exhumation cost. And the ledger's own counts adjust the estimate — if a class starts resurrecting, its q̂ rises and it stops being treated as recurring dead matter.

Jane: So the system is self-correcting in both directions. Aggressive in exactly the safe way.

Tom: That's a really elegant loop. Now, all of this has been about the temporal side — context tokens over time. But the paper's other channel looks at the code itself, the dependency graph, and that's what's coming next.

Page 4 of the paper: Tom: So we've seen the context channel decide what to bury and when to sweep, and now the code channel measures the structural reach of an edit across the repository.

Jane: And the nice thing here is they don't build any new machinery. They reuse the abstract syntax tree the editor already parses and the dependency DAG the executor already walks. The turn's edits touch a seed set of files, and then they compute the k-hop impact reach — every node within k dependency hops of that seed.

Tom: So if you edit a utility function, the reach includes every file that imports it, and every file that imports those. It's the classic change-impact analysis idea from software maintenance, but they weight it by realized churn.

Jane: Churn being the actual added and removed lines the session has applied to each file. So a file that's been touched once barely registers, but a file that's been churned three hundred times becomes a big presence on the radar.

Tom: The radar rendering is genuinely thoughtful. Each file is a blip, with the radial coordinate encoding churn, and the angular coordinate just a hash of the path. They take the square root of churn before mapping it to radius, so that the blip's area stays proportional to the actual churn — because people read area, not radius.

Jane: And the risk tiers are concrete — fifty, two hundred, five hundred, a thousand churned lines. Once any file crosses the five-hundred-line risk rim, the commit-pressure signal fires, prompting the operator to checkpoint before the reviewable surface grows too large.

Tom: It's an ambient signal, not a gate. It advises, it never blocks an edit. That feels like a deliberate design choice — you want the human to stay in control of when to commit.

Jane: Exactly. The context channel bounds how much history the model must carry; the code channel bounds how much future review the operator must carry. Both are reach estimates, and both exist to keep an unbounded integral bounded.

Tom: That phrase really lands. The whole paper is about taking things that grow without limit and putting a boundary around them.

Jane: And now they're about to do something more ambitious — taking these two separate mechanisms, the temporal reach and the structural reach, and unifying them under a single mathematical framework. That's the Polish space formulation coming next.

Page 5 of the paper: Tom: So we've seen the two channels get unified in a single Polish space, and page nine shows what that formalism actually buys you — every operation becomes a measurable function, and reversibility becomes a theorem.

Jane: Right, they define the blast radius as one measurable function with two terms: the retention likelihood times the weighted dependency neighborhood, plus the churn term. That's the context channel and the code channel as two projections of the same object.

Tom: And because it's measurable, the eviction budget and the set of candidates are all well-defined measurable sets. That gives the whole system a clean mathematical footing — you can reason about it with probability theory.

Jane: Then they formalize burial as a map from active context to an archive and a skeleton. Theorem six point four shows it has a measurable inverse, so exhumation is a bijection — you get back exactly what you buried, byte for byte.

Tom: That's the same reversibility we've been discussing, but now it's proven in the formalism rather than just asserted. The active and archived regions become disjoint measurable subsets, and the operator is a homeomorphism between them.

Jane: The other new piece is how recurrence classes generalize. In the deployed system, two transcripts are recurrences only if their normalized forms match exactly. In the Polish space, a recurrence class is a closed ball — everything within a distance epsilon. So you can capture near-identical transcripts, not just identical ones.

Jane: And the Laplace recurrence probability still applies, with the posterior mean falling as the class count grows. The domination threshold from Corollary seven point two gets restated here as a measurable condition.

Tom: But here's the honest part — the deployed system doesn't use the full metric. It replaces it with the hard normalization map and a hard classifier for retention likelihood. The Polish-space generality is kept as the target for a learned estimator down the road.

Jane: So they're explicit: the fancy formalism is the goal, the shipped rules are the conservative boundary case where the domination threshold is satisfied by construction.

Tom: And that builds the bridge to the paper's central theoretical claim. Because now that reversibility is proven, they can show why it dominates lossy forgetting — and that's the next section, the theory of why reversibility wins.

Page 6 of the paper: Tom: So we've built up the whole framework — the two channels, the reversible sweep, the Polish space — and now page eleven states the central claim: reversible forgetting has an asymmetric payoff.

Jane: That's the heart of it. Theorem seven point one: if you bury a body and it stays buried for m turns, you save the token difference every single turn. But if it turns out you needed it, you pay exactly one exhumation cost — a small constant.

Tom: So the two curves are completely lopsided. The downside is capped at that one-time κ, while the savings grow linearly with how long the body stays buried.

Jane: And that's the contrast with lossy forgetting. Truncation or summarization can lose something load-bearing, and then the turn fails outright. No way back. The downside there is unbounded.

Tom: Reversibility bounds it. You might pay a small tax for being wrong, but you can never be catastrophically wrong.

Jane: Then they turn that into a decision rule. Corollary seven point two: burying a body has non-negative expected token value whenever its resurrection probability is below a threshold — the token saving times the expected burial length, divided by the exhumation cost.

Tom: And here's the kicker — because the body is usually much bigger than the skeleton, and the expected burial length is at least one, that threshold is typically above one. Since probabilities can't exceed one, the inequality holds for every possible q.

Jane: Which means carrying any candidate body is dominated by burying it. Even if you're almost certain it'll be needed, the math says bury it anyway, because the one exhumation cost is cheaper than carrying it turn after turn.

Tom: But they're careful not to just leave that as a theoretical statement. Remark seven point three — the threshold is measured, not assumed. The ledger records every burial and every exhumation, so the realized resurrection rate is a direct running estimate of q.

Jane: So the system watches its own behavior. If that rate starts climbing, you shrink the candidate set. If it stays low, the policy is well-calibrated.

Tom: Exactly. The quantity the theory needs is the quantity the instrument reports.

Jane: That's a tight loop. And now that they've shown reversibility dominates in tokens, the next step is what that means in information-theoretic terms — and eventually, in dollars. That's where the paper goes next.

Page 7 of the paper: Tom: So we've built the full theoretical case — reversible forgetting caps the downside while the savings grow with every turn — and now we're getting into how they actually test this thing.

Jane: Right, and the first thing that stands out is how seriously they take preregistration. They fixed the questions, conditions, and metrics before running, so the numbers are confirmatory rather than constructed. That's still rare enough in this space to be worth celebrating.

Tom: And the setup is clean — five context policies, identical in every other respect. Carry-all as the baseline, truncation, summarization, the deployed Blast-Radius census, and the full policy with recurring dead matter added.

Jane: What I really like is the routine traffic design. Every single turn, the agent rebuilds the project from zero, reruns the full test suite, and checks version control — and those three transcripts enter context exactly as they would in production. So conditions A through D have to carry or lossily discard that recurring load, while condition E reclassifies it.

Tom: That's what makes the comparison honest. The earlier experiments in the paper showed the census alone gave a modest eight percent saving, because mission burial can't touch those routine transcripts. Adding RDM is what unlocks the full twenty percent.

Jane: The task suite is also deliberately structured — scripted feature requests against a synthetic repository, so early context provably becomes dead as later turns supersede it. Success is adjudicated by held-out unit tests.

Tom: And they're upfront about a limitation already. Success came out at one hundred percent everywhere, because each task is answerable from recent context. So the discriminating signal was cost and overflow, not correctness.

Jane: That's an honest caveat. It means the evaluation doesn't stress the risk of wrong eviction — but that's also exactly why the zero-exhumation result matters so much.

Tom: Now let's get into what they actually measured — the tables with token consumption, overflow incidents, and that striking number: 450 bodies buried, 378 recurring dead matter, zero exhumations.

Page 8 of the paper: Tom: So we've walked through the experimental setup, and page fifteen delivers the per-model breakdown — the token savings, where they come from, and the first look at the preregistered predictions.

Jane: The first thing that jumps out is how uniform the savings are. Carry-all sits at around fifty thousand tokens per episode across every model, and the full policy with RDM brings every single one down to the mid-thirties, from gpt-4 point 1 all the way to the gpt-5 point 6 family.

Tom: That uniformity is the point. Routine traffic — the build log, the test rerun, the version-control check — is a property of the session loop itself, not of which model happens to be running. So the RDM saving doesn't change as models get smarter.

Jane: And the reclaimed-mass figure makes that concrete. Mission dead from the census reclaims a solid chunk, but recurring dead matter contributes thirty-nine percent of the total and all of the improvement from condition D to condition E.

Tom: That's why the growth curves separate from the very first turns. Mission burial waits for a census threshold — you need four thousand reclaimable tokens before a sweep fires. But RDM buries every older instance of a recurrence class on sight, the moment a newer one arrives.

Jane: So the routine transcripts get reclaimed immediately, not after accumulating. It stops the bleeding at the source.

Tom: Then the results confirm what the abstract promised. The deployed census alone cut tokens by eight percent, because it can't touch the recurring load. Adding RDM gives the full twenty percent — or seventeen to twenty-six percent per model — at identical one hundred percent success.

Jane: And the full policy matches the token economy of lossy truncation while remaining byte-exact reversible. That's the headline — you get the cost of forgetting without paying for the information loss.

Tom: It also posts the lowest overflow rate of any condition, which makes sense — it's actively reclaiming context each turn instead of waiting for the window to burst.

Jane: There's one more table coming that ties this all back to the theory. The burial and exhumation counts, and whether the realized resurrection rate stayed below the domination threshold.

Conclusion: Tom: So to wrap it all up — Blast Radius takes the growing token cost of agentic coding and treats forgetting as a reversible operation, archiving dead context instead of destroying it.

Jane: And the whole argument rests on that simple asymmetry: the worst case of burying something is one small exhumation cost, while the savings keep compounding on every turn it stays buried. That's what makes it dominate lossy truncation and summarization.

Tom: Their experiments back it up pretty convincingly too. Across seven Openeye models, the full policy cut tokens by seventeen to twenty-six percent at identical one hundred percent success, with the lowest overflow rate of any condition.

Jane: And the calibration result is striking — 450 bodies buried, 378 of them recurring dead matter buried on sight, and zero exhumations. The aggressive policy was exactly as safe as the conservative one.

Tom: That zero-exhumation number is the one I keep coming back to. It validates not just the mechanism but the entire framework of liveness prediction and the HCRC gate licensing what counts as concluded.

Jane: The impact here goes well beyond one tool. Every agentic coding loop pays this tax on re-submitted history. A reversible memory layer like this could become a standard component, not a research curiosity.

Tom: They're honest about what's still open, though. The deployed system uses hard rules, not the learned estimator, and RDM isn't yet integrated into the shipped census and radar. The cross-provider matrix is planned but not yet run.

Jane: And the success metric didn't stress correctness — every policy got every task right, so the real test of wrong evictions hasn't come yet. Maybe on harder tasks, exhumation rates will rise.

Tom: That's exactly the kind of question the field will want answered. A reversible memory layer with measured resurrection rates could become the standard way we think about agent context.

Jane: Nicely put. That's Blast Radius — a strong, honest step toward making agentic coding sustainable.

Tom: And we're already looking at the next paper to bring you. It's on the arXiv pile, and after this one, we're curious to see how deeply the field is digging into context efficiency. Stick around.