/p/2026-07-11 · explainer
Paper explainer · 2607.01916 · Luk et al.

Index the evidence,
stop re-reading whole files.

Repair agents burn most of their context re-reading whole files, running broad searches, and scrolling verbose terminal logs — noise that inflates cost and dilutes the few lines that actually matter. This system indexes the codebase and the agent's own action history at three levels of detail, ranks evidence with a mix of retrieval signals, and filters tool output into a compact packet before it reaches the prompt — the full source stays one lookup away. Tested on two production coding agents against real GitHub bug-fix tasks, that cut tokens by up to 51.5% and cost by up to 36.4%, with the repair rate essentially unchanged.

01 · The problem

Every read-try-fail-reread loop leaves more noise in the prompt

An agent repairing a real repository issue doesn't get handed the ten relevant lines — it has to find them. So it reads whole files, runs broad searches, and scrolls long terminal output, and "as interactions accumulate, the active context grows with both useful evidence and stale exploration residue." Every extra round trip costs tokens, and every extra page of noise dilutes the lines that actually matter for the fix.

Interactive · what's in context, mid-repairOpenClaw · 50 matched SWE-bench Lite tasks
avg. tool calls per task
32.1
more round trips hunting for the right evidence
avg. tokens per task
1.36M
whole files, search hits, and logs, all kept in context
02 · The mechanism

Three levels of memory, one hybrid ranker, one context gate

ContextSniper indexes both the codebase and the agent's own action history the same way, at three levels of abstraction — a compact view for everyday recall, a structured index for locating things, and the full content kept in reserve. Step through what each level actually holds.

Interactive · the three-level memory hierarchyAGFS-backed, per code & per action

A hybrid ranker decides what surfaces from that index: it fuses semantic embeddings, BM25 lexical scoring, ctags-style symbol metadata, and graph relations (imports, calls, containment) into one ranking via weighted reciprocal rank fusion. Toggle signals off and watch it fall back to plain text search once the fused ranking has nothing left to work with.

Interactive · the hybrid ranker's signalsweighted reciprocal rank fusion

Before anything reaches the prompt, an intention-aware context gate strips what it can from long reads and command output. Pick a source to see what it keeps versus what it removes.

Interactive · the context gatekept vs. stripped, by source

When content is shortened, ContextSniper keeps the original in action memory and attaches a marker — the agent can explicitly ask for the full version if the compact one turns out not to be enough.

03 · The payoff

Roughly half the tokens, the same fix rate, on two different agents

The comparison is matched: same 50 tasks, same host agent, only the context layer differs. Pick a host agent and watch tokens, cost, tool calls, and the resolved-task rate move together.

Interactive · matched 50-task comparisonSWE-bench Lite · raw access vs. ContextSniper
tokens/task
1.36M
cost cut
baseline
tool calls
32.1
1.36Mtokens/task
32.1tool calls/task
26.0%tasks resolved

It also beats bolt-on memory and RAG systems

A separate, smaller check ran the same repair task through six existing memory- and retrieval-augmented-generation integrations on five Django-repository tasks. ContextSniper still used the fewest tokens of the group. The paper flags this as exploratory given the small sample.

Interactive · vs. memory/RAG baselines5 Django tasks · exploratory
ContextSniper
~450K
no memory
~700K
mem0 / Letta / etc.
~600–800K
OpenViking
~800K

Approximate tokens per task. All methods but one resolved 4 of 5 tasks (OpenViking resolved 5 of 5) — too small a sample to claim a repair-quality edge, only a token-efficiency one.

04 · Where it costs more

When retrieval misses, sniping backfires

ContextSniper used fewer tokens on 45 of the 50 matched OpenClaw tasks. On the other 5, it used more — either fixed retrieval overhead outweighing a very short task, or the compact packet simply missing the file that mattered. Toggle between the two failure shapes.

Interactive · the 5 token-increase outliersOpenClaw · 50-task comparison
overhead
+9.6–17.3%

On short tasks, retrieval's fixed overhead can outweigh a small file read — a 9.6–17.3% token increase, still a small absolute cost.

Retrieval quality also varies by repository — some codebases index cleanly, others don't. Recall for the actual target file ranged widely across repos:

Interactive · target-file recall, by repobest repo vs. weakest repo
recall@1
~100%
recall@5
~100%

On the best-indexed repos the target file is nearly always found; on the weakest, recall@1 falls to around 40% — that gap is what shows up as the retrieval-miss outliers above.

The numbers

What it bought, on two production coding agents

−51.5%
tokens, OpenClaw
1.36M → 0.66M tokens/task. Resolved rate 26.0% → 24.0% (13 → 12 of 50) — essentially unchanged.
−38.9%
tokens, Claude Code
1.45M → 0.79M tokens/task (85.97M → 52.55M across 50 tasks). Resolved 32.0% → 30.0% (16 → 15 of 50).
−36.4% / −27.3%
logged cost
OpenClaw and Claude Code respectively. Claude Code: $15.09 → $10.97 across 50 tasks.
−46.4% / −35.7%
tool calls per task
OpenClaw 32.1 → 17.2; Claude Code 29.9 → 19.2. Fewer round trips to find the right evidence.
45 / 50
tasks used fewer tokens
OpenClaw. The other 5 used more — fixed overhead on short tasks, or a retrieval miss (up to +152.3%).
~450K
tokens vs. bolt-on memory/RAG
Lowest of 7 systems tested on 5 Django tasks, vs. 600K–800K for mem0/Letta/OpenViking/etc. (exploratory).
05 · Why you care

Any agent that pastes whole documents into context has the same problem

Coding agents aren't the only ones that dump raw material into the prompt — a support-ticket agent pasting entire threads, a codebase-QA bot pasting whole files, an ops agent pasting full log dumps, all pay the same tax. Flip the same step between raw and indexed access. Illustrative walkthrough — the panel is simulated; the paper's measured effects are the direction, not these exact numbers.

Interactive · one support-ticket lookup, two waysstep: pull relevant history before replying

How to try it on your own agent

Where it stops — stated honestly

The paper's own validation is noisy: SWE-bench Lite has known validation-error imbalance, so the near-identical resolution rate is suggestive, not a strong repair-quality claim — the authors recommend a more standardized benchmark for that. Retrieval quality still depends on embeddings, chunking, and symbol extraction, and evidence that's weakly signaled or spread across unusual files can be missed entirely. The filtering rules are hand-crafted, not learned, and commit history isn't used yet. What's real: matched, same-task comparisons across two different production coding agents and 100 real GitHub bug-fix tasks.

In practice

Index what your agent reads, don't just paste it in

When you catch your agent pasting whole files, full logs, or entire threads into context, split what it reads into a compact view, a structured index, and a recoverable full copy — then gate what actually enters the prompt by the intent of the call, keeping the full version one lookup away. In this paper's repair agents that cut tokens up to 51.5% and cost up to 36.4%, with the fix rate essentially unchanged.