XERJ is a local search engine for coding agents: it indexes a folder (code, docs, logs, PDFs) and lets the agent retrieve passages instead of reading whole files. The repository sits at about 5.6k stars on its GitHub page (checked on 16 October 2026) and shows up on daily Trending, which makes it one of the projects of the moment for anyone working with agents.
What it is
It is a single static Rust binary with no JVM or other dependencies, built for Linux, macOS and Windows on x86-64 and arm64. Its hook is that it implements the Elasticsearch REST API, so clients that already talk to Elasticsearch can point at XERJ unchanged. The license is Apache-2.0.
Internally, the autoindex command sniffs file types and creates one index per inferred dataset. Source code is parsed with tree-sitter so symbols and line numbers survive. Search covers full-text (BM25), vector (kNN) and hybrid retrieval using Elasticsearch query syntax. For agents it exposes an MCP stdio server (xerj mcp) with 13 tools, including search, memory store/recall and a code-search pipeline. The default embedder is lexical and works offline; a neural one needs model files staged separately.
How to use it
Per the README, installation is one script and minimal usage is four commands:
curl -fsSL https://xerj.org/get | sh
xerj --insecure --data-dir ./data &
xerj autoindex ~/my-project
xerj search "how do we rotate the WAL segment"You can also query it with the classic API:
curl "localhost:9200/ax-*/_search?q=checkout+error"Two practical warnings. First, I don't recommend curl | sh without reading the script. Second, --insecure disables TLS and authentication: the README says the node binds to 127.0.0.1 only, but it is a single-user dev mode. On a shared host you need to enable auth.
What I like and what I don't
I like reusing a well-known contract (the Elasticsearch API) and shipping one binary: for an SRE, something that needs no cluster and no JVM lowers the cost of trying it a lot. The MCP server out of the box also helps wire it into coding agents.
What holds me back: the README itself admits limits. Scroll is a bounded snapshot and queries exceeding the window return a 400 instead of truncating; it recommends search_after. Elasticsearch conformance is 1366 of 1369 cases, and on read p99 latency under a concurrent high-rate writer it reports losing to Elasticsearch 8.13.4. Reranking quality with the real model is listed as unverified, and the optional external reranker (Jev) sends result text off the node, though it is off by default.
The token-savings figures are also inconsistent within the page itself: the intro says "40x fewer tokens than grep" while the case study in the body reports 2.7x fewer output tokens. The README adds that the benefit depends on the model not having memorized the code, and that it is neutral or even harmful with popular public libraries. I would treat 2.7x as the order of magnitude and measure it on my own repository before adopting it.
As an alternative, ripgrep plus a good symbol index covers a lot of cases with no extra service; XERJ pays off when the corpus mixes logs, PDFs and docs with code.
XERJ vs. Graphify
The comparison with Graphify naturally comes up whenever you want to supply structured context to an agent, but they tackle the problem from fundamentally different angles: hybrid document retrieval versus relational graph modeling.
XERJ treats the repository as a heterogeneous text corpus: it parses source code with tree-sitter, but stores it alongside logs, Markdown files, and PDFs to serve lexical (BM25) and vector (kNN) queries. Its primary objective is pinpointing relevant snippets and line ranges without forcing an agent to load entire files into its context window. It does not resolve or model explicit software relationships across modules.
Graphify, in contrast, turns code into a property graph of dependencies and symbols (nodes for files, classes, or functions linked by edges like CALLS, IMPORTS, or inheritance), designed for export to tools like Neo4j or NetworkX. It is tailored for architectural and topological questions: identifying what breaks if an interface changes, tracing call hierarchies, or analyzing coupling between packages.
In practice, they complement each other rather than compete: Graphify helps the agent reason about overall architecture and dependency hierarchies, while XERJ handles fast retrieval of specific code fragments, documentation, and error traces without requiring graph databases or external infrastructure.
Sources
- XERJ repository on GitHub (README, license and stars), checked on 16 October 2026.