Grep Won the Agent Wars. XERJ Is Betting Against the Peace.

For the past year, the conventional wisdom in agent tooling has been a kind of militant minimalism. Anthropic ripped vector search out of Claude Code in May 2025 and replaced it with grep, with creator Boris Cherny declaring that agentic search “outperformed everything. By a lot.” Cursor, Windsurf, Cline, Devin and Sourcegraph Amp all followed, dropping their vector databases in favor of tool-driven retrieval where the model decides what to search and how. The vector database, as one commentator put it, hasn’t died — it’s been demoted from default to fallback.

XERJ, a young Apache-2.0 project out of the xerj-org GitHub organization, is an interesting counter-thrust: it accepts the agentic-search premise — agents should query, not read — and then asks what happens when grep isn’t enough. Its answer is a full search engine. Not a wrapper around one, not a vector store with delusions, but an actual local index server written in Rust, shipped as a single static binary, that happens to speak the Elasticsearch REST API on port 9200.

The economics that make it necessary

The pitch starts with arithmetic that any agent developer has felt. The PHP in WordPress core is roughly 5.2 million tokens — about 26 full context windows. An agent cannot simply read it. Grep doesn’t solve the problem either, because a grep hit is a line, and judging that line means opening the whole file, which is the thing you were trying to avoid. The project’s own write-up of an AI security audit of WordPress core claims an agent worked across 1,492 PHP files on roughly 26,000 tokens — the cost of loading about half a percent of the tree.

This is the same tension the memory-infrastructure crowd keeps rediscovering. Mem0’s guide to agent memory argues that large context windows won’t eliminate the need for external memory: cost and latency grow with token count, attention degrades as context grows, and nothing persists across sessions. Cloudflare, launching its own Agent Memory service, frames it as a choice between context rot and aggressive pruning. Dataiku’s survey of the field cites LangChain’s 2026 report, where large enterprises flag context management as a leading cause of unreliable agent output. Everyone agrees the context window is a bad database. The disagreement is over what replaces it.

XERJ’s answer is: a database. Specifically, a search index where a query costs kilobytes instead of megabytes.

What it actually is

Strip the framing and XERJ is a local search engine with three distinguishing traits.

The first is autoindex. Point it at a folder and it sniffs each file by content — not extension — identifies what it is, and builds one index per dataset it finds, with no schema and no pipeline configuration. Source code goes through tree-sitter, so code arrives in the index with its symbols and line numbers rather than as flat text. CSV (dialect-sniffed), JSON, JSONL, XML, YAML, SQLite, SQL dumps, PDF, DOCX, HTML, mail and common log formats are all handled — thirteen format families in total, per the project’s site. It infers field types and date encodings, writes explicit mappings, and uses idempotent document IDs, which is what makes the process resumable and, in the project’s phrasing, kill -9 safe. In one published run, indexing a 1,995-file, 518 MB corpus of 25 formats finished in 38.1 seconds, producing 31 datasets and just over two million records, at a measured 33.7k records per second end-to-end on a larger 923 MB input.

The second trait is the one that sounds boring and is arguably the whole strategic insight: it implements the Elasticsearch REST API. Indices, documents, bulk, search, aggregations, mappings, kNN, scroll, reindex, the _cat endpoints. Kibana connects to it directly. Every official Elasticsearch client library works if you point it at localhost. The project runs an ES YAML conformance suite on every commit and currently passes 1,360 of 1,363 cases, with the remaining gaps listed in the repo rather than quietly rounded down to “compatible.” The project is careful to say it implements the API, not Elasticsearch internals — it is not a fork.

This matters more than it first appears. The Elasticsearch ecosystem has a decade of accumulated tooling, dashboards, client libraries, and institutional knowledge. A new agent-memory startup has to convince you to adopt its API; XERJ has to convince you to adopt nothing. The wire protocol is the moat it borrowed.

The third trait is that the same binary is an MCP server with ten tools — search, semantic, vector and hybrid search, durable agent memory under namespaced endpoints, and a second-brain link index over your own documents. It integrates with Claude Code and Cursor. So the project straddles both camps in the retrieval debate: it’s a grep-replacement for coding agents (ranked, cited passages with file and line, plus a go-to-definition command backed by the AST index) and a RAG-style retrieval engine (BM25, vector kNN, and hybrid in one query, with an offline default embedder and an opt-in neural one).

The evidence, and its limits

The project publishes numbers with unusual specificity. A controlled study across eight tasks in four languages, sixteen runs per arm, found retrieval-based agents used 2.7× fewer output tokens than grep-driven agents at the same solve rate, at roughly half the cost. On a Rust library the model had never seen, retrieval solved nine of nine tasks while memory-based solving solved none — a data point that flatters retrieval precisely where it should be strongest, on code too niche to be memorized during training. On an eighty-task cross-file benchmark, XERJ put the correct file first 94% of the time versus 38% for ordinary body-text search.

Against Elasticsearch 8.13.4, the project reports a closed-loop benchmark run of 55 wins, 26 ties, and 4 losses across ingest, full-text search, aggregations, vector search, and reads under a concurrent write flood — including 1.72× ingest throughput and a 1.61× smaller on-disk footprint. All four losses are the same gap: read p99 latency while a high-rate writer runs. The finding is written up in a playbook file in the repo rather than omitted, and the README closes its benchmarks section with a sentence you don’t often see: “Treat any number you cannot reproduce with skepticism, including ours.” The harness is public.

That transparency is the right instinct, but the numbers are still self-reported, and the comparison baseline is a specific Elasticsearch version with unspecified hardware and workload details that live in the repo rather than in the README. The ground-truth exam on the 25-format corpus passed 80 of 81 checks — the one miss was a Shift-JIS file indexed as mojibake, which is either an honest disclosure of an edge case or a reminder that content-sniffing across thirteen format families is a game of inches. Probably both.

There’s also a hype question the sources can’t fully answer. A Reddit thread in r/BestGitHubRepos suggests the project is getting attention, but the page itself was inaccessible — blocked by Reddit’s network security — so the shape and scale of community reception is unclear. What’s verifiable is the repo, the site, the conformance suite, and a third-party overview and Medium feature that describe the same project. Adoption claims beyond that are thin on the ground.

Where it sits in the fight it’s walking into

The awkward part for XERJ is that the agentic-search camp it partially serves has been winning arguments with the crudest possible tool. An Amazon Science AAAI 2026 paper — titled, with a straight face, “Keyword search is all you need” — measured agentic keyword search at 94.5% of RAG faithfulness using only grep-style tools. Anthropic’s guidance now says to start with agentic search and add semantic search only if needed. If grep plus a smart model gets you 94% of the way, the burden of proof on any heavier retrieval stack is steep.

XERJ’s implicit rebuttal is that grep’s ceiling shows up at scale and in structure. A grep hit is a line; an AST-aware index hit is a symbol with a signature and a definition site. The 94%-versus-38% first-file accuracy figure is the project’s way of saying the last 6% is where the real work lives — and where flat text search falls over. Meanwhile, the vector-database world it also competes with is not standing still: AWS markets vector databases as the storage layer for RAG and agentic memory, Google wires Vertex vector search into its RAG Engine, and Oracle is shipping hybrid memory retrieval inside its database. Those are managed, cloud-scale systems. XERJ is a binary on your laptop. Different fights.

The honest positioning is that XERJ isn’t trying to beat Pinecone or Cloudflare at their game. It’s trying to occupy the middle ground that the pendulum swing left empty: heavier than grep, lighter than a cloud retrieval stack, and shaped like infrastructure agents already know how to talk to. The “reference coding” use case — an agent clones and indexes open-source repos relevant to a task, then retrieves how they solved a problem before writing its own code — is the clearest expression of this. It’s retrieval as a substitute for training-data memorization.

Open questions

Three, at least. First, whether the Elasticsearch API is a durable advantage or a transitional one — MCP tools and agent-native interfaces are where the interface churn is happening, and ES compatibility serves the human and existing-tooling audience more than the agent audience. XERJ does both, which is hedging done sensibly, but the two audiences may eventually want different things. Second, the read-p99-under-write gap: for a project pitching itself at observability and log analytics, tail latency during ingest is not a corner case, it’s Tuesday. The project knows this and says so, which buys credibility but not latency. Third, whether the autoindex magic holds up across the long tail of real-world files — the mojibake miss suggests where the seams are.

What XERJ gets right, and what makes it worth watching regardless of how those questions resolve, is the diagnosis. Agents don’t need more context; they need a cheaper way to find the right context. The industry converged on grep as the cheap answer. XERJ is the argument that the cheap answer has a floor, and that when you hit it, you don’t want to be standing there holding a regex — you want a search engine, and you’d rather not have to install a JVM to get one.