Xerj: Auto-Indexed Search Built for Agents

TL;DR: Xerj is a Rust search engine built for agents, claiming one-command indexing of code, docs, logs and PDFs plus 40x fewer tokens than grep. It is Apache-2.0 licensed with 5,728 stars, and the Elasticsearch compatibility is the part most likely to save you migration work.

What it is

The pitch is token economics. An agent searching a codebase with grep and sed burns context on lines that turn out to be irrelevant. Xerj’s claim is that autoindexing lets an agent retrieve targeted results instead, using 40x fewer tokens than grep for the same job.

That number is the repository’s own claim, and no benchmark is cited in the GitHub metadata. Read it as a direction of travel rather than a measured figure.

One command is meant to index code, documentation, logs and PDFs, and the description names the jobs it targets: search, RAG, security audits and agent memory. Four different consumers of the same index is an unusual way to frame a search tool, and it is the most interesting part of the pitch.

Elasticsearch compatible

This is the practical detail. If existing Elasticsearch clients can talk to it unchanged, you do not rewrite the search layer of an agent system to find out whether it works. You point the client somewhere else.

That is a much stronger compatibility claim than “implements a search API”, and it is the reason to read further before weighing anything else in the description.

Young and moving fast

Metric	Value
Stars	5,728
Forks	310
Open issues	54
Primary language	Rust
Repository size	about 116 MB
Created	2026-06-30
Last push	2026-10-15
License	Apache-2.0

$ curl -s https://api.github.com/repos/xerj-org/xerj \
  | jq '{stars: .stargazers_count, language, license: .license.spdx_id, topics, created_at}'
{
  "stars": 5728,
  "language": "Rust",
  "license": "Apache-2.0",
  "topics": ["ai-search","ai-search-algorithms","ai-search-engine","ai-search-free","ai-search-module"],
  "created_at": "2026-06-30T04:32:45Z"
}

Roughly three and a half months old, which makes 5,728 stars fast growth. The topic tags are five variations of the same phrase, so that list was optimised for discovery rather than describing the project. Do not read the topics as an architecture summary.

54 open issues against 5,728 stars sits just under 1 percent. For a project this young the ratio looks healthy, though it does not tell you how quickly issues get closed.

How to try it

git clone https://github.com/xerj-org/xerj.git
cd xerj

Check how indexing is wired before pointing it at a large corpus. A 116 MB repository that indexes PDFs and logs is doing real work, and the storage profile matters more than the speed claim.

When to use it

It fits when an agent is reading more code and documents than fit comfortably in context and your current approach is grep. Security audit workflows are the clearest case, since the index is doing the narrowing instead of the agent reading its way through every file.

The Elasticsearch compatibility makes it cheap to trial inside an existing stack, which is unusual for a project this young and lowers the cost of finding out whether the token savings hold up on your own data.

When not to use it

Skip it on a small repository. Indexing has a floor, and across a few hundred files grep is faster with nothing to maintain.

A three month old Rust project from a user account carries a different risk profile than an established engine. Pin your version and read the release history before wiring it into anything you cannot roll back easily.

Source and Accuracy Notes

• Project page: https://xerj.org
• Source repository: xerj-org/xerj (verified via GitHub API html_url)
• License: Apache-2.0 (verified via GitHub API license.spdx_id)
• Stars at time of writing: 5728
• The 40x token reduction and the Elasticsearch compatibility are the repository’s own claims from its description, not independently verified