XERJ: Local Search Engine Cutting AI Agent Tokens

Background and Context

Most coding agents share one habit. When they enter an unfamiliar project, they map it with grep, sed and a long series of file opens. Each file read costs tokens. A wrong guess costs another round. The larger the repository, the more the bill grows, and the more likely the model is to lose its way among irrelevant text. XERJ targets exactly this problem.

XERJ is an open-source, local AI search engine written in Rust. Its idea is simple: let the agent learn the data through an index first, then fetch precise content on demand instead of scanning by brute force. It is not another vector database. It sits between a classic full-text search engine and the agent toolchain. It is compatible with Elasticsearch, so existing clients can connect without rewrites. It also targets agent integration paths such as MCP and skills.

The project tags include bm25-search, which suggests that classic term-frequency ranking remains its base. The documentation also has a dedicated vector page, so semantic retrieval is not ruled out. The project calls its main use case reference coding. The agent first finds the open-source repository closest to the task, indexes it, and then borrows from that solution while writing code.

Deep Analysis

The most important feature is autoindex. According to the project, one command indexes code, docs, logs and PDFs. The same index then serves search, RAG, security audits and agent memory. A team does not need to build a separate system for each purpose. Search results come back as ranked snippets with file:line locations. The agent therefore receives a citable source, not a whole file. There is also a def command for jump-to-definition. It returns the file line and the function signature, which helps code navigation. Another notable design is the xerj gain command. It reports what the tool actually did for you, and the project stresses that these are real counts, not estimates. Many efficiency tools stay at the level of concept. A statistic you can check is easier to trust. What does XERJ claim about token savings compared with grep? The project says it uses 40x fewer tokens than grep. In a controlled study of a reference coding scenario, agent output tokens fell 2.7x while the solve rate stayed at 16/16. Daily users report roughly 5x. These three figures use different measures, so readers should treat them separately and not blend them. The project also says the savings are large enough for a smaller, cheaper model to beat a pricier model that writes code from memory. The setup path is short. There are two routes. In the first, you hand a prompt to your agent, and it reads llms.txt and completes installation, indexing and the reference coding setup by itself. In the second, you do it by hand. You run the curl install script, start the xerj service, run xerj init to connect Claude Code or Cursor, and then point xerj autoindex at the project directory. After that you can ask questions with xerj search, for example how a project rotates its log segments. Windows users, and anyone who wants to verify the install manually, will find notes in the README.

The docs cover the command line, query syntax, agent-memory recipes, vector search, benchmarks and installation. There is also an llms.txt written for models to read. One flag needs care: --insecure. It turns off TLS and API key authentication. Any caller that can reach the port becomes a superuser. That caller can read and delete every index, including every /_memory namespace. The project positions this mode for a single-person development machine. New nodes bind to 127.0.0.1 by default. Binding to other interfaces in plaintext refuses to start unless you explicitly allow it. The security model is written in docs/SECURITY_MODEL.md, and it is worth reading before you begin.

Industry Impact

XERJ treats "read less, read the right thing" as separate infrastructure. Agent cost is now a real line on a team's bill. Moving retrieval out of the model's context window and into a countable, reusable index layer is a practical idea. Elasticsearch compatibility also lowers the barrier to migration. Existing operations experience and client libraries can stay in use.

The project uses the Apache-2.0 license. Its community approach is somewhat unusual. It asks users to submit a short usage report as proof of taking part, and it openly welcomes both humans and agents. This can collect real feedback. Whether the reports will stay consistent in quality and in how they measure results is still to be seen.

The tool fits developers and engineering teams who want lower agent costs and need to keep their current Elasticsearch clients. A single-developer machine is the safest starting point, given the default local binding.

Outlook

The risks are clear. First, the effect figures come from the project's own study and from user accounts. The study sample is small, at 16 tasks, and independent verification is still pending. A team should measure the result on its own codebase. The xerj gain command offers a way to count.

Second, the index gathers code, logs and agent memory in one place. If the security settings are wrong, the exposure is large. Third, letting an agent download and index outside open-source repositories raises questions about licenses and about how far the source can be trusted.

Three things deserve attention next. The first is how openly the benchmarks are published. The second is how mature vector retrieval becomes. The third is how authentication and permissions are designed for larger, multi-user environments. Those answers will decide whether XERJ stays a handy tool for a single developer or grows into shared infrastructure for teams.