XERJ
Local-first search engine and MCP server built for AI agents
About XERJ
XERJ is a local-first search engine and MCP server built for AI agents, shipped as a single Rust binary. It indexes your code, documents, logs, JSONL, CSV and PDFs, then answers an agent's questions from that index rather than forcing the agent to read source files into its context window. It speaks the Elasticsearch 8.13 wire protocol, so clients you already run connect without changes, and it offers BM25 full-text, vector and hybrid search through one API on port 9200.
The problem it targets is specific. A coding agent that meets an API it has not memorised invents method names, fails to compile, and loops, and every lap spends output tokens. Grep does not fix that, because grep only says where to look and the agent still has to read the source. XERJ's answer is what the project calls reference coding: clone the open-source repositories closest to what you are building, index them once with xerj autoindex, and let the agent retrieve the exact definition and its contract before writing a line. The vendor measured eight tasks across four languages, sixteen runs per arm, and reports 2.7 times fewer output tokens at the same solve rate. Those are the vendor's own benchmarks, but the site publishes losses next to wins: a ten-question exam on a 518 MB corpus is reported as nine correct and one partial against a grep-and-python baseline's ten out of ten, described on the page as a tie rather than a rout. The licence is Apache-2.0. The project is young, and the download button currently reads v1.0.0-RC.98 rather than a 1.0 release.
You install one static binary with a single shell command on Linux, macOS or Windows, x86_64 or arm64, and start a node. Pointing xerj autoindex at a folder walks the tree, identifies each file by content rather than extension across thirteen format families, infers field types and date encodings from the data, writes explicit mappings and streams everything in with idempotent IDs, so an interrupted run resumes to identical counts. It finishes by writing a catalog index, which means an agent's first question, what is even in here, is answered by the engine instead of another script. After that, xerj search runs a definition-first query that pairs an exact-symbol clause with a phrase match on tree-sitter AST fields, and xerj def answers go-to-definition in a single call. For agents there is a plain HTTP surface on :9200 with no SDK and no signup, including a /_memory API that stores what an agent learns and recalls it by meaning, with each namespace physically isolated.
- •Elasticsearch Wire Compatibility - Speaks the ES 8.13 protocol with 50 query types, so existing clients, dashboards and migration paths work unchanged
- •One Binary, Zero Config Indexing - xerj autoindex covers thirteen format families including JSONL, dialect-sniffed CSV, SQL dumps, SQLite, PDF, DOCX, HTML, XML, YAML and gzip, inferring mappings from the data
- •Hybrid Retrieval - BM25 full-text, kNN vector search with HNSW and exact modes, and native reciprocal rank fusion in a single query
- •Code Search for Agents - Definition-first search over tree-sitter AST fields, plus xerj def for go-to-definition in one call
- •Agent Memory - A /_memory REST API with store, recall by meaning, filter and forget, session-scoped and time-decayed, with per-agent namespace isolation
- •Resumable Ingest - Idempotent IDs and a journal, so a killed run converges to identical final counts, verified on multi-gigabyte corpora
- •Explain Plans and Metrics - A first-class explain-plan endpoint per query and a Prometheus metrics registry built in
Developers running coding agents against large or unfamiliar codebases, where the agent burns tokens re-reading files it could have queried. It suits teams that already operate Elasticsearch clients and want a drop-in local index without the operational weight, and anyone building agent tooling who would rather call plain HTTP than adopt an SDK. The local-first design is the point if your code cannot leave your machine. It is a poor fit if you need a proven, settled dependency: the project is a few months old, has not shipped 1.0, and has no track record on security response or breaking-change discipline. It is also the wrong tool if you need a published price for a supported deployment, because Professional is quoted per node on request and Enterprise is custom, and several compliance and platform rows on the comparison table are dated for future quarters rather than shipping today.
Pricing
Custom pricing, contact sales
- Community$0/mo
- ProfessionalContact sales
- EnterpriseContact sales
From the vendor pricing page, 2026-10-23
