Coding agents waste a large share of their budget rediscovering repositories they have already explored, and two papers published a day apart go after that waste from opposite ends. CodeNib builds reusable lexical, semantic and structural views of a codebase for each commit and reports preserving the agent's ability to find the right code while using 50 to 87% fewer exploration tokens than the usual grep-and-read loop. Agent Retrieval Bench, meanwhile, provides the missing measurement: a benchmark for the file-finding stage itself.
Key facts
- The headline number: 50 to 87% fewer trajectory tokens across five models, with localization preserved.
- The limit: CodeNib's static navigation matched a live language server's normalized locations on only 63% of 1,000 requests.
- When: CodeNib submitted July 28, 2026; Agent Retrieval Bench submitted July 27.
- Primary sources: CodeNib and Agent Retrieval Bench on arXiv.
Anyone who has watched a coding agent work has seen the pattern. It greps for a function name, reads a file, greps again, reads three more, gradually rebuilding a mental model of a codebase -- and then the session ends and all of it evaporates. Next task, same repository, same rediscovery. The tokens are real money, the latency is real waiting, and the model's context window fills with exploration transcript instead of the actual problem.
CodeNib's proposal is to treat repository context as a data system rather than a per-session activity. For each commit it builds three complementary views: a lexical index for literal text matching, a dense index for semantic similarity via embeddings, and a structural graph of symbols and references. All three map their outputs to repository-relative source ranges, and one runtime serves ranked search, symbol navigation and bounded context requests. Selected views are maintained incrementally across edits rather than rebuilt from scratch.
The key insight is that these three views fail in different ways, so an agent needs all of them. Text search finds the exact string and misses the concept. Semantic search finds conceptually similar code and cannot tell you which definition is authoritative. A symbol graph knows exactly what calls what and nothing about intent. A librarian who only had a keyword catalog, or only a subject map, or only a citation index, would be a poor librarian; the useful one has all three and knows which to consult.
The results are reported with commendable precision about their conditions. Across 100 repository snapshots, graph and vector updates were 8.7 and 25.4 times faster at the median than full rebuilds -- but that figure applies specifically when the incremental output matched an independent rebuild, which is the right way to state a freshness-versus-speed tradeoff. The token savings, 50 to 87% across five models, came from selected context policies while preserving the agent's ability to localize the relevant code. And the honest limit is stated too: static navigation agreed with a live language server on 63% of 1,000 requests, so this augments live tooling rather than replacing it.
The companion benchmark addresses why nobody noticed this problem sooner. Coding agents are almost always scored on whether the final patch is correct, which bundles together reasoning, editing and the earlier step of finding the right files. Agent Retrieval Bench isolates that upstream step at the file level, against frozen base-commit repositories, with relevance defined as "what the agent needs next" rather than surface similarity between query and file. It spans four positive-retrieval tasks -- finding tests for code, finding the context a comment refers to, tracing from a stack trace to the responsible code, and identifying what an edit ripples into -- plus a fifth subset that tests whether a system knows when not to retrieve. That last one matters more than it sounds: an agent that always returns something is an agent that will confidently hand you the wrong file.
There is a real boundary dispute here worth flagging. A vendor post argues that exposing tools over a protocol does not resolve authority, freshness, conflicts, permissions or synthesis across tickets, pull requests and design documents -- that connectors are transport, not a context engine. That is marketing, and it is also correct about the boundary, which CodeNib does not dispute since it scopes itself to repository context and treats the protocol as an adapter.
The caveats: both are fresh preprints without peer review or independent reproduction, all numbers are author-reported, and CodeNib describes a research system rather than a shipping product. But the direction is unambiguous, and it matches what production tooling has been converging on all year -- from agents that edit files instead of screenshots to Anthropic cutting 80% of Claude Code's system prompt. The scarce resource in an agent is not intelligence, it is attention, and rediscovery is the largest avoidable tax on it.
Originally published on Ground Truth, where every claim is checked against the primary source.
Top comments (0)