XERJ is an Elasticsearch-compatible search engine for code, documents and logs, written in Rust and pointed at AI agents rather than at human dashboards. It is for developers who run a coding agent and watch it burn its context window opening files one at a time, and for anyone who wants local search over a project to feed retrieval-augmented generation, security audits or agent memory. The project is Apache-2.0 licensed, has roughly 5,300 stars and 299 forks, and was last pushed on the day this entry was written.
What it does
You point XERJ at a project and it builds a searchable index of what is inside: code, docs, logs and, according to the project, PDFs as well. The agent then asks the index a question instead of reading candidate files one by one. The README advertises three query styles: BM25 keyword search, k-nearest-neighbour vector search, and a hybrid of the two. Other advertised pieces are a /__memory surface for agent memory, native MCP support, and an llms.txt file so agents can read the docs themselves.
Every token figure attached to XERJ is the project's own claim, not an independent measurement, and this channel does not run the tools it covers. The GitHub description claims 40x fewer tokens than grep. The project's own reference-coding case study is narrower and more specific: 2.7x fewer output tokens than grep, and 26x fewer than giving the agent memory alone, a setup that finished only 11 of 16 tasks. The authors also quote users reporting roughly 5x fewer tokens in everyday work. Read all of those as vendor numbers.
How it works
The selling point for integration is the query language: XERJ speaks Elasticsearch's API, so clients and tooling you already have can talk to it without a rewrite. The project publishes a conformance badge of 1366 of 1369 ES-YAML tests passing, again measured by the authors on their own benchmark page, so expect compatibility to be very good but not total.
The second design choice is packaging. XERJ ships as a single static binary with no JVM, which is what makes it plausible to drop next to a repository rather than run as a cluster. Indexing is described as zero-config "autoindex": you give it a directory and it decides how to index the contents, instead of you writing mappings first.
Getting started
The repository is github.com/xerj-org/xerj. The software itself is free and self-hosted under Apache-2.0, and nothing in the material requires a paid service to run the index. The intelligence is still a separate bill: the coding agent that queries XERJ is whatever model you already pay for, locally or through an API. The saved material also does not say where vector embeddings come from for the kNN and hybrid modes, so do not assume semantic search is free of a model or key until you check the docs.
The project does not list hardware requirements, operating systems or memory figures in the material here. Because it is a static binary with no JVM, the practical install is a download rather than a build: tagged builds live on the repository's GitHub Releases page, and the project site carries install and CLI pages. The script says one command indexes a project, but the saved README excerpt does not print that command, so take it from the project's CLI documentation rather than from this page. The README is published in English and Simplified Chinese.
When to use it / when not
The main catch is security. There is an insecure flag that makes every caller a superuser, so an exposed instance with that flag set is an open door to whatever you indexed. Use it only inside a setup you fully trust, on a loopback address, and treat it as a reason not to put XERJ on a shared host yet. The second caveat is age: the repository was created at the end of June 2026 and is still moving fast, so interfaces may shift under you.
Use it instead of grep or ripgrep when your agent keeps rescanning a large repository and you can see the token cost in every session. Don't use it if the repository is small enough that two grep calls answer the question, or if you need a hardened, multi-tenant search service with real authentication and quotas.
Alternatives
The obvious comparison is Elasticsearch itself, which XERJ imitates deliberately: pick the original when you need the full ecosystem and can run a JVM service, pick XERJ when you want one binary next to a codebase. For agents specifically, the alternatives the reader already has are plain grep in a loop, or a memory file that the agent re-reads, and the project's case study positions itself against both.
Developers who pay per token for a coding agent on a big repository should take this seriously, because indexing is the one lever that cuts retrieval cost without changing the model. It is also a reasonable choice for anyone who wants an Elasticsearch-shaped search service without a JVM. Just keep it on a trusted network until the authentication story is clearer, and treat the headline multipliers as the project's own marketing until someone outside the project measures them.