Fewer tokens is the part of the story I believe. On SWE-bench Pro, handing Claude Code a repository map cut average token use from 3.12M to as low as 2.31M per task. Resolution did not move: 49.0% for the baseline, 44.3% to 50.6% across the five map variants.
That is the headline of How Should Agents See Code?, a controlled comparison of five ways to show an agent a repository. The authors hold the agent fixed (Claude Code with Haiku 4.5 at low effort, built-in tools pinned) and change only one MCP server: AST, call graph, module dependencies, documentation-enriched search, or a hybrid of those. Four benchmarks: LinuxFLBench, SWE-bench Pro, SWT-bench and SecBench.
Maps pay for themselves when the hard part is finding code#
Fault localization is where it works cleanly. All five maps beat the baseline on recall@10 (0.757 to 0.829 against 0.717), and all five cut tokens by 25 to 39%. The mechanism is visible in the tool counts. The baseline averages 8 reads, 6 greps and 10 shell calls per task. The map agents swap that for 9 to 13 map queries and almost no grep or glob.
The hybrid map is the standout here: 17 instances won, zero lost against the baseline, and the cheapest runs at 39% fewer tokens. If you have been tempted to pick one view, this is mild evidence for merging them.
Recall@1 tells a different story. The differences are small and mixed, so maps widen the candidate set more than they sharpen the first guess.
The patch step does not care how good your map is#
On SWE-bench Pro the map workflows win or lose a similar number of instances against the baseline (net between −12 and +4). The authors' trajectory reading explains why: the dominant loss category for every representation is correct localization, wrong patch (for example 20 of 20 hybrid losses). The agent found the right file and still wrote the wrong fix.
SWT-bench makes the same point harder. Test generation hinges on writing a discriminating assertion, and no repository view helps with that directly. Hybrid and Docs reached 47.8% and 47.2% against 44.7%, but every map variant used more tokens, and the call graph fell to 37.9%.
representation tools can slightly change outcomes, but the decisive step is often writing the right assertion rather than finding the right code
That is the sentence I would pin above any agent-tooling roadmap. Better retrieval lowers the cost of reaching the decisive step. It does not make the decisive step easier.
Why a map sometimes makes the run more expensive#
The trajectory coding is the most useful part of the paper for anyone building a tool server. Two authors read every divergent paired run and sorted the reasons into categories. Where maps saved tokens, the dominant reason was read displacement: the agent asked the map instead of opening files (for example 184 of 190 fewer-token AST runs on SWE-bench Pro).
Where maps cost tokens, the reasons were self-inflicted. The hybrid map's top category on SWE-bench Pro was verbatim-source explosion (44 of 72 costlier runs), where a query returned a large dump of source the agent then had to carry. Docs showed over-exploration (53 of 72), and the dependency map suffered from generic or popular symbol names (51 of 63). Those are design bugs in the tool output, not limits of the idea.
The authors call these categories patterns, not causal proof, and I agree. Still, it tells me to cap and rank what a map query returns before worrying about which graph to build.
Latency and the cheap-looking security result#
Token savings are not time savings. On LinuxFLBench, wall time rose from 66.7s to between 82s and 106s. On SecBench it went from 66s to 136 to 290s. SWE-bench Pro was the exception, where time fell from 269s to roughly 194 to 209s because the agent browsed less.
SecBench is also where the call graph looks best, at 34.3% resolved against 28.9%. Take that gently. On that benchmark, more instances used more tokens than fewer for every representation, and the AST map dropped below baseline at 25.3%. A single sample of 166 tasks is not enough to crown the call graph.
What I would build from this#
I would not ship a map server as a default for every task. The paper's own conclusion is task-dependent, and the numbers back it. My rule would be:
Use a map for triage, bug-report-to-file work and large repos where reads dominate the bill. Prefer the hybrid view.
Skip it, or make it opt-in, for test authoring. The paper shows more tokens and mixed success there.
Budget for latency if the agent is interactive. Cheaper does not mean faster.
The limitations are real. One small model at low effort, one agent harness, samples of 152 to 253 tasks per benchmark, and one figure per cell with no variance in the tables. The treatment also includes a prompt steer telling the agent to use the representation tools, which the baseline did not get. A stronger model might already navigate well enough to shrink the gap, or might use the maps better. I do not know which.
My bet is that the next real gain comes from the other side of the bottleneck: tooling that checks the patch or the assertion, not another way to see the code. Maps got the agent to the right file for less money. Nobody has shown yet what gets it past the file.