ContextSniper
Definition
ContextSniper is AntTrail’s code-repair module for precision evidence selection in repository-level program repair (arXiv 2607.01916, Luk et al.). LLM agents repairing real repository issues spend large context budgets on whole-file reads, broad searches, and long terminal outputs where useful evidence is mixed with irrelevant code and logs.
Key Points
- Four-step pipeline: (1) index code and action memory as three abstract levels; (2) retrieve candidates with a hybrid ranker; (3) filter long tool output through an intention-aware context gate; (4) return compact evidence packets, with full source kept recoverable on demand.
- Results (matched 50-task-per-condition, SWE-bench Lite): OpenClaw — token use −51.5%, logged cost −36.4%; Claude Code — token use −38.9%, logged cost −27.3%; submitted-resolution rates “essentially unchanged.”
- Mechanism contrast: unlike naive compression, evidence packets are selected by an intention-aware gate and full source stays recoverable — the information is not destroyed, just deferred.
- Benchmark: beats existing memory- and RAG-style integrations on token efficiency in a five-task comparison.
Implications
ContextSniper is the strongest measured counterexample to the paper’s warning: it reduces both tokens and logged cost (−36.4% / −27.3%) because it preserves evidence recoverability (select, don’t destroy). The design difference is exactly what RTK’s issue #582 lacked: full source is recoverable on demand, so the model can re-read when needed. It validates the “success-adjusted billed cost” lens as the right evaluation metric.
Implementation (confidence: medium)
The GitHub repo Calluking/ContextSniper (capture 2026-07-31) is the same project family as the arXiv paper — identical name, 3-stage pipeline, dual Claude Code + OpenClaw hosts, matched SWE-bench Lite methodology, near-matching headline numbers. The relationship is never declared in the repo (no arXiv citation, different author handle, paper points to gitcode.com), so authorship is unverified at medium confidence.
- Ships two local plugins:
claude-plugin/(MCP tools:contextsniper_search_code,contextsniper_edit_file,contextsniper_index_codebase,contextsniper_health) andopenclaw-plugin/(native tools + prompt policy injection). Both start a local backend + AGFS service (c4pt0r/agfsviapyagfs), stopped when host exits. - Repo numbers: Claude Code −39% total tokens (−47% with Filter); OpenClaw −41% (−52% with Filter); embedding via
text-embedding-3-large. Repo omits cost figures that the paper reports. - Config:
CONTEXTSNIPER_FILTER_ENABLED(default 1),CONTEXTSNIPER_INJECT_FILTERING_PROMPTtoggle for the shipped prompt-policy injection files (claude-plugin/prompts/code_policy_injection.txt,openclaw-plugin/prompts/code_policy_injection.txt). License MulanPSL-2.0. Requirements: Python 3.11+, Go 1.22+, Claude Code/OpenClaw CLI, OpenAI-compatible embedding endpoint.
Open Questions
- Whether “logged cost” is provider-billed or an estimate (methodology not fully specified in capture).
- Repo availability (gitcode.com) vs the GitHub ecosystem used by other tools here.
- Authorship unverified: repo never cites arXiv 2607.01916 or AntTrail; paper’s
lukchiwang/ContextSniperlives on gitcode.com while this isCallukingon GitHub; whether Calluking = author Chiwang Luk is unverifiable from captures. - Number discrepancy: repo −39%/−41% (plain) and −47%/−52% (Filter) tokens vs paper −38.9%/−51.5% tokens and −27.3%/−36.4% cost; repo omits cost entirely. Token %s roughly align; treat as config/version-sensitive, not a hard contradiction.
Related
token-reduction-is-not-cost-reduction — the evaluation lens this tool passes rtk-rust-token-killer — the compression failure mode ContextSniper avoids token-usage-reduction — the cost-lever space it operates in codebase-memory — analogous knowledge-graph memory approach context-mode — mechanism parallel: select-don’t-destroy intent filtering at tool-output scale
Sources
- raw/external/arxiv-org-2607-01916-96bad417.md
- raw/external/github-com-contextsniper-7749d2f0.md