XERJ: Letting Coding Agents Retrieve Code Instead of Reading Files One by One

Why agents waste context on "reading files"

Ask an AI coding agent to change a small function, and it pulls the entire file—or even the whole directory—into context. This is a familiar scenario for many developers. According to episode 598 of Bilibili's "Daily GitHub Express," the local AI search engine XERJ aims to change this workflow: instead of having the agent open files one by one, build the project into an index first so it can retrieve the relevant snippets directly, just as a person would look something up.

The value of this approach lies in the context budget. An agent's context window is limited; stuffing whole files into it is not only expensive but also dilutes the truly useful information. XERJ replaces "reading files" with "retrieving snippets," letting the agent locate code outside the context.

Context window refers to the total token limit a large model can accept in a single inference pass; the input (system prompt, conversation history, tool return content) and output share this budget. Every file an agent reads occupies the window in its entirety, reducing the reasoning space available. Once the window is filled with large amounts of irrelevant code, the model's attention to key information is diluted, and "lost in the middle" can occur—content positioned in the middle of a long context is more easily overlooked. This is exactly the problem that retrieval-based context injection solves: put only the snippets relevant to the current task into the window and leave the limited tokens for reasoning itself.

What XERJ is: a code search engine that runs locally

According to the video, XERJ is an AI search engine that runs in a local environment, building an index specifically for your own code and documentation so coding agents can query it directly.

The objects it can index are not limited to source code; they also include documentation, logs, and PDFs, and indexing is completed with a single XERJ Auto Index command. This means the agent's retrieval scope expands from a single codebase to all kinds of project-related materials, with the greatest benefit when working with private, internal, or unfamiliar codebases—exactly the scenarios where agents lack prior knowledge and are most prone to blindly rummaging through files.

Because the index is built locally, code does not need to be uploaded to external services, which is a practical consideration for internal projects.

Code indexing and code retrieval differ from traditional keyword search in that the indexing stage splits code into semantic units such as functions, classes, and comment blocks, and generates a vector representation or inverted index for each unit; at query time, the most relevant snippets are returned by semantic similarity or keyword matching rather than whole files. Such systems usually need periodic index rebuilds to keep up with code changes, and index quality directly determines retrieval recall. Running locally means both the embedding model and the index store are deployed on the developer's machine, and query requests never leave the internal network—suitable for private code that cannot be shared externally.

Integration and returned results

The integration cost is deliberately kept low. According to the video, a single XERJ Init command connects it to mainstream coding agent tools such as Claude Code or Cursor.

How retrieval results are presented is equally important: the returned content directly includes File and Line information—that is, the file path and line number. For an agent, this is far more useful than returning a large block of text with no source—it can jump precisely to the target location based on this without having to read the file in full again.

File and Line information refers to the source file path and line range annotated in retrieval results, effectively giving the agent a coordinate it can navigate to directly. Most coding agents can read file snippets by line number—for example, reading only lines 120 to 180 without loading the entire file. Returning references with line numbers also lets the agent land accurately on the target location in subsequent edits, reducing repeated full-file reads caused by missing location information. This is one of the mechanisms by which retrieval-based approaches can significantly compress token consumption.

Measured data: an order-of-magnitude difference in token consumption

The core quantitative conclusion given in the video is that measured output tokens are about 1% of those in a Graph workflow. It should be noted that the original material repeats this figure with incomplete wording ("1% date" is a transcription error from the spoken script), so only the order-of-magnitude comparison of "1%" can be confirmed here; the details of the specific baseline workflow are not elaborated in the material.

Even looking only at the order of magnitude, this figure points in a clear direction: in agent workflows, retrieval-based context injection may bring order-of-magnitude token savings compared with graph-structured full traversal. Of course, measured data from a single source still needs more independent verification, and readers should not treat it as a universal benchmark.

Graph workflow here refers to a workflow that organizes code or knowledge in a graph structure: first parse the repository into a graph of nodes (files, functions, classes) and edges (calls, references, inheritance), and the agent traverses the graph to locate relevant code. Such methods have high localization accuracy, but the traversal process often requires multiple rounds of tool calls, and the content returned in each round accumulates in the context, amplifying token overhead. The "1%" comparison in the article puts the cumulative output of such multi-round graph traversal against the snippet volume returned by a single retrieval, so it can only serve as a directional reference and is not equivalent to a general ratio for the same task.

Three new projects with similar ideas

At the end of the video, several projects with similar directions are previewed as references for observing this trend:

• A "context layer" for coding agents that organizes code and team experience into a map;
• A self-hosted Harness unified interface platform that runs agents such as Codex through a single API and supports switching;
• An AI-native knowledge base that clips social media and web content into notes and syncs across devices.

These projects share the same judgment as XERJ: the bottleneck for agents is not model capability but "what you feed it." Whoever can control what enters the context more precisely will gain an advantage in both cost and effectiveness.

Applicable boundaries and caveats

XERJ's benefits are not unconditional. The index needs maintenance; when code changes frequently, index freshness affects retrieval quality. The retrieval step itself also introduces new failure modes—failing to find something or finding the wrong thing both send the agent down the wrong path. For simple, small projects, the extra overhead of reading files directly may not be significant, and introducing a retrieval layer may instead add complexity.

More noteworthy is how it changes the workflow: the agent shifts from "sequential browsing" to "on-demand localization," which requires retrieval quality to be sufficiently stable. In scenarios such as private codebases and legacy systems that lack public corpus support, the advantages of a local index truly emerge.