xerj gives coding agents a local search engine in one Rust binary

Coding agents read files one by one. xerj gives them a search engine so they can read passages instead. The project reached rank 17 on Trendshift's daily list on 23 October, with 14,193 stars on GitHub. The repository was created on 30 June. It is one Rust binary, under the Apache-2.0 licence.

What xerj is

The README says xerj is a local-first search engine and an MCP server. It indexes code, docs, logs, JSONL and CSV data, and PDFs. It supports BM25 full-text search, vector search, and a hybrid of both. It serves an Elasticsearch-compatible API, so any client that can talk to Elasticsearch can talk to it.

The project says it works with Claude Code, Cursor and any MCP client. The install is curl -fsSL https://xerj.org/get | sh, then xerj autoindex ~/my-project. The binary runs under one user on one machine and binds to the loopback address by default.

The measurement the project publishes

The README's lead claim is that an agent using xerj uses fewer tokens than one that greps. xerj says it ran 8 tasks across 4 languages, 16 runs per setting, on code the model had not memorised. The results, as the README states them:

• From memory only: 260,916 output tokens, 11 of 16 solved, cost $11.18.
• Grep-driven agent: 26,477 output tokens, 16 of 16 solved, cost $3.27.
• xerj: 9,982 output tokens, 16 of 16 solved, cost $1.58.

The project calls that 2.7 times fewer output tokens than grep, at the same 16-of-16 solve rate. Against from-memory it is 26 times fewer tokens. The project says the gap grows on private or niche code. On popular public libraries the model already knows, xerj says the gap is small.

Those figures are the project's own, in a case study it ran itself. The README links the study at xerj.org and is clear about the limits. No outside team has reproduced them.

Other uses the README names

The README names five uses for the same primitive. Reference coding: index the open-source projects nearest the problem and have the agent read how they solved it before writing new code. Codebase question-and-answer: ask for the mechanism, get the passage with file and line number. Security audits: query for secrets, dangerous calls and sink patterns across every file type at once. Log and incident analysis: mixed log formats become typed indices with aggregations. Agent memory: a /_memory/{namespace} endpoint stores what the agent learns and recalls it by meaning next session.

The --insecure flag turns off TLS and API-key auth. The project is clear in the README that this is a one-user, one-machine boundary. A node started with --insecure on any interface other than loopback refuses to start without an explicit allow flag.

What a buyer should check

The main claim is a measured one, and a buyer can run it. The case study comes with its scripts. 8 tasks are a small enough set to repeat on a Friday. A reader with code the model has not seen can test it well.

The second question is whether the agent that calls xerj knows when to use it. Grep works. The README is open about one limit. A model that memorised a library will not call a search index at all. That measurement does not count prompts the model refused to issue. The model may already think it knows the answer.

Source

xerj on GitHub. Case study on xerj.org. Trendshift rank from Trendshift's daily list.