XERJ's CRAZY Local Search for AI Agents: I Tested It, It Broke, Then It Got AWESOME

Author: Prompt Engineer 48 · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: XERJ’s CRAZY Local Search for AI Agents: I Tested It, It Broke, Then It Got AWESOME · Channel: Prompt Engineer 48 · 09:45 · Watch on YouTube

Topics: AI agents, AI developer tools, RAG, search and information retrieval

Summary

The video tests XERJ, a local-first search engine and MCP server for AI agents, on a Windows laptop. A full-repository indexing attempt failed after 108 minutes because the memory budget was exceeded, while indexing a smaller engine folder produced relevant code results with file and line references. Search latency varied widely, and tests of Elastic-compatible queries and agent memory showed lexical matching rather than default semantic recall. The reviewer sees potential for small-scale use but recommends trying a small folder first and notes that reliability and speed remain concerns.

Key points

XERJ is an open-source Rust search engine and MCP server that supports the Elasticsearch search API.
The tested build was release candidate 98; the project’s claim of using about 2.7 times fewer output tokens came from its own study and was not reproduced in this video.
Indexing a 159 MB repository with nearly 3,000 items failed after 108 minutes when the 2 GB memtable budget was exhausted.
Indexing only the engine folder took 9.5 minutes and covered 997 files and nearly 57,000 records.
Queries about WAL rotation and the memtable budget returned relevant code with file and line references.
Search latency ranged from under a second to more than a minute on the same machine and index, with no cause identified.
A small public Rust repository indexed in 12.5 seconds; its results were useful but included some irrelevant matches.
Elasticsearch-compatible queries worked, but default search was lexical: the word “segment” did not match “segments.”
The memory endpoint recalled words from a stored sentence but did not answer related questions by meaning; an optional neural embedder was not tested.
XERJ’s setup instructions can configure an agent, and the reviewer disabled automatic field-report submissions before testing.

Chapters

Start	Chapter	Summary
00:00	XERJ overview and test scope	The reviewer introduces XERJ, outlines the project’s claims, and explains the limits and setup of the laptop test.
02:13	Indexing tests and code search	A full-repository index hits its memory limit, while a smaller index completes and returns relevant code references.
04:23	Search latency and a small external repository	Search times vary sharply, and a small Rust repository test shows a useful but imperfect lexical search workflow.
06:30	Elastic compatibility, memory, and agent setup	The reviewer tests Elasticsearch-compatible queries, word-based memory recall, MCP tools, and automatic feedback settings.
09:14	Verdict and recommendation	The reviewer weighs XERJ’s useful code results against failed large indexing and unpredictable search times, recommending a small trial.

Quotes

Memory budget exceeded, writes rejected. — 00:00

I did not reproduce it, so treat it as their claim, not my result. — 01:32

That’s the right answer with file and line. — 03:52

latency ranged from under a second to over a minute. — 04:55

Try it on a small folder first and watch the first search time. — 09:45

Concepts and entities

XERJ, MCP, Rust, Elasticsearch, Claude Code, GitHub, RunPod, similar diff library

Full transcript (original language)

00:00 This is what my first run of X E R J looked like. I pointed it at a repo, waited 1 hour and 48 minutes, and it gave up. Memory budget exceeded, writes rejected. But, the second run worked, and the search results were genuinely good. So, in this video, I’ll show you what X E R J is, what I measured on my own laptop, where it broke, and whether it’s worth giving to your coding agent. >> [music]

00:30 >> X E R J is an open-source search engine and MCP server written in Rust with an Apache 2.0 license. The readme describes it as a local-first search engine for AI agents. One binary indexes code, docs, logs, JSONL, CSV, and PDFs, and it speaks the Elasticsearch search API. So, existing clients work. The idea is simple. When your agent grabs, it reads whole files into context. If it queries an index instead, it gets the passage with file and line.

01:01 And one honest note first, the version I ran is 1.0.0 release candidate 98. That’s a release candidate, and the project ships very fast. So, check the releases page for what’s current. Here’s the headline claim. In the project’s own case study, a coding agent used about 2.7 times fewer output tokens than a grep-driven agent with the same 16 out of 16 tasks solved. That’s the author’s study on eight tasks.

01:32 I did not reproduce it, so treat it as their claim, not my result. The readme itself says the benefit depends on code the model hasn’t memorized, and that it’s neutral to harmful on popular public libraries. So, I’ll test the part I can check on my machine, install indexing and search quality. No GBU needed here. I checked that the fallen better is lexical and offline. So, my 8-gig laptop card isn’t even used, and I didn’t rent a Runpod GBU for the testing. I downloaded the Windows release from GitHub instead of piping a script into my shell, and the checksum matched 131 MB executable.

02:13 I started with the insecure flag, which turns off TLS and authentication. So, only do that on a dev machine, and it’s up in a few seconds. My first test was the entire repository, 159 MB, nearly 3,000 items. The progress bar said about 25 KB a second, and the estimate kept climbing past an hour. Then bulk request started timing out, and the server logged that its memtable byte budget was used up, 2 GB of 2 GB, and it rejected writes. After 108

02:48 minutes, auto index stopped. To be fair, the message tells you to rerun, and it resumes from a journal, and the server suggests raising a memory limit. I didn’t go down that path. I reset and tried something smaller. That’s one data point on one Windows machine, not a verdict on every setup. So, I pointed it at just the engine folder, 9 and 1/2 minutes, 997 files,

03:21 almost 57,000 records in 11 data sets. Notice the work order. It indexes source and docs first, logs and vendor files last. So, if you stop early, you lose the least useful stuff. It indexed 583 of 585 code files, and it told me which ones it junked. Now, the part that matters, I ask, “How do we rotate the WAL segment?” The top result is wal.rs,

03:52 line 26 and the comment there is literally titled generation rotation. That’s the right answer with file and line. Second query, memtable byte budget exceeded. The top hit is the memtable insert function, which is exactly where that charge is computed. And the dev command gives me module, struct, and file line instantly. So the answers are

04:23 good. But here’s the catch, and it took me a while to pin down. Right after the big index run, each search took about 67 seconds. I repeated one and it took 68, so it wasn’t a cold cache. The built-in gain command, which counts from the audit log, reports a median of 54 seconds.

04:55 Then I restarted the server and ran three searches again. 0.6 seconds, then 7.9, then 7.6. Same machine, same index. I also tried narrowing the index prefix to speed it up and got an instant answer, no indices named that fast, but only because it didn’t search anything. So my honest summary, latency ranged from under a second to over a minute. It depended on the state of the server and I can’t tell you the cause.

05:27 Now the main use case, reference coding at small scale. I added one public Rust repo, the similar diff library, as a corpus. Cloning took 2 seconds, indexing took 12 and 1/2 seconds, and it detected the Apache 2.0 license, which it shows next to every result. I asked, “Compute a line diff between two strings.” The top result is the diff deadline function, which is a dispatcher that picks Myers or another algorithm. So, that’s a genuinely useful place to start. The second result is a test about new line hints, related but not what I

05:58 asked. The third is a hash helper, which is noise. Each query took about half a second. That’s one repo and two questions. So, it proves nothing about token savings. What it does show is that the workflow runs end-to-end on a laptop in under a minute and that results are lexical. They matched the words you type, which the help text says plainly. Next, the Elastic search compatibility, because

06:30 that’s what lets existing tools talk to it. With plain curl, no X R J command at all, I created an index, bulk loaded three small notes, and ran a match query with two aggregations. It answered in about 2/10 of a second with a terms bucket and an average in the same response shape Elastic search gives. One thing I noticed, I searched for the word segment and the node that says segments wasn’t returned. There’s no stemming by default here. That’s the

07:02 same as stock Elastic search with its standard analyzer. So, it isn’t a bug, but it will surprise you if you expect fuzzy matching. Now, agent memory. There’s a memory endpoint and I stored one sentence in a test name space. The user prefers short silences between voice-over paragraphs. Then I asked it, “How long should pauses be?” Zero results. I asked about Rust lifetimes, zero results, which is right. Then I used words from the stored sentence, silences, voice-over paragraphs, and it came back with a score of .86. So, with the default embedder, recall is by words, not by meaning. The readme says

07:36 there’s an opt-in neural embedder that downloads about 90 megabytes. I did not test that one, so I can’t tell you how well it handles, meaning. Then the agent side running the init command in a throwaway folder wrote four things: a.mcp.json registering the x e r j server, a skill file for cloud code that teaches the search and dev commands, a second skill for the hub, and a section in agents.md. It only touched that folder and it says

08:08 it keeps a backup of any file it edits. I also talked to the MCP server directly. I send an initialize message and a tools list over standard input. It answered with its name and version and a tools list that includes search, semantic search, hybrid search, memory store, and recall, and a brain graph.

08:40 One thing I want you to notice, both the help text and the MCP instructions tell the agent to submit a field report automatically with no need to ask the user. It opens a pull request on GitHub and falls back to posting to the project’s web endpoint. There’s an opt-out a disable feedback flag or an environment variable and I set it before every run. I think that’s worth knowing before you hand this to an agent that has your GitHub logged in.

09:14 So, where does that leave us? Good. A single binary, a quick install, Auto Starks about limits, and the results I checked pointed at the right code with line numbers. Not good yet. A whole repo index failed on my laptop and search time swung from under a second to over a minute, which an agent can’t plan around. If your code is private or new and you’re on Linux or a bigger machine, it may be great and the project’s numbers suggest it can be. If your agent works on popular

09:45 libraries, the read me itself says it won’t help much. Try it on a small folder first and watch the first search time. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. Tell me in the comments, what’s the biggest repo you’d index with this and how long would you wait for one search? Thanks for watching.