/p/2026-07-30 · explainer
Paper explainer · 2607.25431 · Yu, Yu, Yuan, Zhao, Chen et al.

Stop making the agent
rediscover the repo.

A coding agent opens every task the same way: search, read, follow a definition, read again — rebuilding a picture of the codebase that it throws away the moment the task ends. This paper builds that picture once per commit instead, as three views over the same source ranges (a text index, embeddings, and a symbol graph), and serves the agent ranked search, symbol navigation and a bounded slice of context from one runtime. Across five models, the cheapest arm that still found the right code used 50–87% fewer trajectory tokens than letting the agent grope its way there. And keeping the views current beat rebuilding by 8.7× and 25.4× — on the changes where the incremental update provably matched a fresh build, which the paper counts and reports rather than glossing.

01 · The problem

Every ticket pays for the same exploration

Nothing an agent learns about a repository survives its own task. The definition it chased, the file layout it worked out, the three dead ends it ruled out — all of it exists only as tool calls in a transcript that is about to be discarded. Three ways to hand an agent the code it needs, measured on the same tasks with the same models:

Interactive · three ways to deliver contextsame issue, same model, same commit
what it costs
high
what it fixes

The measured claim is careful and worth restating exactly: for each of five agent models, the lowest-token arm that still met a common accuracy margin — the right code among the first five source spans it committed to, within five points of the best arm — used 50–87% fewer trajectory tokens than searching and reading. Not "the agent got better". The same answer, for a fraction of the context.

02 · The mechanism

Three views, one address space

The trick that makes the views composable is boring and load-bearing: every result from every view is expressed as the same tuple — path, start line, end line, kind. A keyword hit, an embedding neighbour and a graph node all name a region of source in the identical way, so results can be fused, ranked together and expanded into each other. Pick the kind of question and watch which route serves it.

Interactive · which view answers which questionfour routes over one address space
What is built per committhree views, one manifest

The manifest is the part to steal for your own tooling. It records, per view, which commit it was built from and what it is capable of — so a caller can tell whether what it is holding is current, instead of finding out from a wrong answer. What it deliberately does not provide is a transaction across the three stores after an edit.

03 · Freshness

Repair the index, don't rebuild it

An index for a repository that nobody commits to is easy. The cost is in the update, and the naive answer — rebuild everything on every commit — is what makes teams give up and go back to grep. Against that baseline the paper measures two repair strategies over a single Python edit; step between them and watch the work shrink as the repair gets more surgical.

Interactive · one edit, two repair strategieslanguage-server requests needed
0510 requests
What the repair bought, when it was provably rightmedian speedup over a fresh rebuild

Read the fractions, not just the multipliers. The symbol graph repair provably matched a fresh rebuild on 15 of 33 source-changing commits; the embeddings on 28 of 31. A transition that failed the check contributes no speedup at all, even when it was fast — which is the right way round, and rarer than it should be.

04 · The honest number

A speedup on the subset where it works isn't a speedup

Static symbol navigation — answering "where is this defined" from the prebuilt graph instead of a running language server — is 4.7× faster. It is also wrong to quote that alone, and the paper says so. Flip the switch and watch the same measurement change meaning.

Interactive · how the result is reported1,000 navigation requests · five languages
what you would claim
4.7×
requests it holds for
63.2%

Because the static path fails a full-coverage test, the system keeps the live language server in the loop and does not silently route unseen requests to the fast path. That is a design decision falling straight out of an honestly reported number — the version that quotes 4.7× alone would have shipped the wrong architecture.

05 · Your repo

What serving context is worth on your codebase illustrative

The reduction is reported as a range across five models, not a single figure, so the useful question is where in that range your setup lands and what it is worth. Set your agent volume and how much context a task burns today, then slide through the reported band.

Interactive · monthly context burnedillustrative — the 50–87% band is the paper's
tokens per month
259M
saved per month
551M

What this does not price is the index itself: building the views per commit, keeping them fresh, and running the embedding and reranking models that make ranked search work. The paper measures those costs separately and does not pretend they vanish — the claim is that they amortise across sessions, not that they are free.

The numbers

What the paper actually reports

What this does not show

In practice