XERJ: Eine lokale Suchmaschine für Coding-Agenten, die ihre eigenen Zahlen korrigiert

Es ist selten, ein Projekt zu finden, dessen interessanteste Eigenschaft die eigene Offenlegung ist.

XERJ ist eine in Rust geschriebene Suchmaschine für Code und Dokumente, gebaut für Coding-Agenten, mit einem zu Elasticsearch kompatiblen Wire-Protokoll und Apache-2.0-Lizenz. Es gibt eine Benchmark-Tabelle mit echten Dollar-Beträgen. Und es gibt eine Maintainer-Notiz, die einräumt, dass die GitHub-Sterne durch eine synthetische Kohorte um etwa das Dreizehnfache aufgebläht sind, und darum bittet, diese Zahl nicht zu zitieren.

Beides ist Ihre Zeit wert, und beides hängt zusammen.

Das Problem, auf das es zielt

Wenn ein Coding-Agent eine Codebasis verstehen muss, ist der Standardgriff grep. Grep ist ehrlich: Es findet Zeilen, die einem Muster entsprechen. Aber ein Agent mit grep muss Dateien lesen, um herauszufinden, ob der Treffer relevant ist, und Dateien zu lesen ist genau das, was ein Kontextfenster füllt. Eine einzige große Datei kann mehr Token verbrauchen, als die Antwort wert war.

XERJs Alternative ist ein lokaler Index. Auf einen Ordner zeigen, und autoindex erschnüffelt Dateitypen, leitet Datasets ab, wirft Müll weg und baut pro Dataset einen eigenen Index. Das Repository-Log eines echten Laufs liest sich so: 593 Datasets abgeleitet, 1.955 Junk- oder übersprungene Dateien in Phase A, dann Phase B mit 25.329 indizierten Dateien und acht Workern, abgeschlossen in 158,1 Sekunden mit 83.103 aktiven Records.

Code wird mit tree-sitter geparst, Symbole und Zeilennummern bleiben erhalten, statt alles zu Text zu plätten. Deshalb kann xerj def <symbol> eine Datei, eine Zeile und eine Signatur zurückgeben — ein Sprung zur Definition über ein ganzes Repository, genau das, was ein Agent von Anfang an gebraucht hätte.

Der Benchmark, genau gelesen

Das Projekt lief acht Aufgaben in vier Sprachen, sechzehn Durchläufe pro Arm, und maß den tatsächlichen Tokenverbrauch von claude -p, statt ihn zu schätzen. Drei Setups: nur Gedächtnis, grep-getrieben und XERJ.

Nur Gedächtnis: 260.916 Output-Token, 11,18 $, 11 von 16 gelöst. Grep: 26.477 Token, 3,27 $, alle 16 gelöst. XERJ: 9.982 Token, 1,58 $, ebenfalls alle 16.

Also rund 2,7-mal weniger Output-Token als grep, 26-mal weniger als sich auf das Modellgedächtnis zu verlassen, bei unveränderter Lösungsrate. Der beste Einzelfall — eine Java-Aufgabe — sparte das 278-Fache. Nutzer berichten von etwa 5x Ende-zu-Ende.

Nun der Vorbehalt, der diesen Artikel nötig macht. Die Schlagzeile des Repositories behauptet „40x weniger Token als grep“. Das kontrollierte Experiment im Text sagt 2,7x. Das sind nicht dieselben Aussagen, und die Lücke dazwischen ist genau das Muster, das benchmarkgetriebenes Marketing unglaubwürdig macht. Zugute halten muss man dem Projekt, dass die README selbst sagt, man solle der Zahl im Text den Vorzug geben. Eine Schlagzeile, die überverkauft, und eine Fußnote, die sie korrigiert, ist eine seltsame Art auszuliefern, aber immerhin ist die Korrektur da.

Die Einschränkung, die in Launch-Posts niemand erwähnt

Hier ist der Satz, den die meisten Such-für-Agenten-Projekte weglassen: Der Nutzen hängt davon ab, ob das Modell den Code schon kennt.

Bei privatem, internem, Nischen- oder Code nach dem Trainings-Cutoff spart Retrieval viel, weil das Modell es wirklich nicht erraten kann. Bei populären Open-Source-Bibliotheken, die das Modell zehntausendmal gesehen hat, ist der Index neutral oder aktiv schädlich — man gibt Token aus, um abzurufen, was das Modell ohnehin wusste.

Diese eine Einschränkung ändert, wie man das deployen sollte. Es ist kein universelles Upgrade. Es ist eine Kur für einen bestimmten Fehlermodus: Agenten, die an Code arbeiten, über den niemand einen Blogpost geschrieben hat.

Das Flag --insecure ist eine echte Vertrauensgrenze

xerj --insecure schaltet TLS und API-Authentifizierung ab. Wer den Port erreicht, ist praktisch Superuser: jeden Index lesen, schreiben, löschen, inklusive allem unter /_memory. Auf dem Laptop eines einzelnen Entwicklers ist das in Ordnung, auf allem Geteilten katastrophal.

Die Defaults sind besser als das Flag. Ein neuer Node bindet an 127.0.0.1, und ein Klartext-Bind an eine Nicht-Loopback-Adresse verweigert den Start, außer man setzt explizit server.allow_insecure_network_bind = true. Das Projekt hält außerdem fest, dass der Betrieb insecure auf 0.0.0.0 eine echte Schwachstelle war — LAN-Clients konnten ohne Autorisierung schreiben — und dass sie behoben ist. Der eigenen vergangenen Schwachstelle einen Namen zu geben, ist eine gute Angewohnheit.

Die Offenlegung, die eine Vorlage sein sollte

In einem Instrumentation-Commit schrieb der Maintainer, die Sterne und Forks des Repositories seien durch eine synthetische Kohorte um etwa das Dreizehnfache verstärkt worden, die echten Installationsdaten seien dünn — rund 145 Downloads von Release-Assets und etwa 28 abgeschlossene Installationen — und Cloudflare RUM habe im Juli aufgehört aufzuzeichnen, weshalb das Null-Traffic-Diagramm auf der Website ein Artefakt sei.

Für ein Projekt mit Elasticsearch-Kompatibilitätsanspruch und 1.371 bestandenen Konformitätstests (null Fehler, drei übersprungen) ist das eine bemerkenswerte Veröffentlichung. Sie sagt auch etwas über den Zustand der Open-Source-Signale: Eine Sternenzahl ist eine Marketingfläche, und wer eine Growth-Loop laufen lässt, kann sie bewegen. Vertrauenswürdig sind nur die Zahlen, die ein Autor gegen das eigene Interesse freiwillig nennt.

Was Ihnen sonst noch begegnet

Die Installation ist ein curl-Pipe-in-die-Shell, das SHA256 prüft und sich weigert weiterzumachen, wenn es kein Checksum-Tool findet — eine für dieses Muster ungewöhnlich vernünftige Absicherung. Builds sind statisch musl mit jemalloc, Linux zuerst, Windows per Handinstallation. Es gibt einen MCP-Server mit dreizehn Tools, darunter xerj_plan und xerj_map, und xerj init verdrahtet Claude Code oder Cursor mit einem Befehl. kNN mit scalar8-Quantisierung wird unterstützt. Multi-Node-Deployment kommt mit Helm-Chart und Compose-Datei.

Die Version ist 1.0.0-rc.x, und die CLI bewegt sich noch. Die CLA ist von Apache abgeleitet, mit einer Maintainer-Notiz, dass kein Jurist sie geprüft hat und zwei Platzhalterfelder übrig sind. Viele Commits sind von Coding-Agenten geschrieben und als solche gekennzeichnet, was transparent ist und zugleich ein Grund, den Code zu lesen, von dem man abhängt.

Reference Coding, der Use Case, den niemand benchmarkt

Tief in der README steckt die interessanteste Anwendung: den Index auf das Open-Source-Projekt richten, das dem eigenen Problem am nächsten kommt, und dann die eigene Version schreiben, mit der Referenz im Kontext.

So entsteht ein großer Teil echter Ingenieursarbeit — die Bibliothek finden, die es schon gelöst hat, sie lesen, dann etwas Engeres implementieren. Schlecht gemacht heißt: ein halbes Repository in einen Prompt kleben. Gut gemacht heißt: fragen können „wo behandelt dieses Projekt Backpressure“ und eine Datei, eine Zeile und eine Funktionssignatur zurückbekommen.

Das zeigt auch die Grenzen des obigen Benchmarks. Reference Coding verlangt, ein fremdes Repository herunterzuladen und zu indizieren, was Zeit, Plattenplatz und Netzwerk kostet. Die Ersparnis kommt bei der zweiten und dritten Query, nicht bei der ersten. Wer das bewerten will, sollte die ganze Session messen, nicht eine Aufgabe.

Der Elasticsearch-Kompatibilitätsanspruch

XERJ spricht das Elasticsearch-Wire-Protokoll, und das Projekt meldet 1.371 bestandene Konformitätstests, null Fehler, drei übersprungen. Wenn das hält, können bereits gegen Elasticsearch geschriebene Tools mit minimalen Änderungen darauf zeigen, und Teams, die für ein paar Millionen Dokumente einen Cluster bezahlt haben, haben einen Ausweg.

Die Kritik an Elasticsearchs SSPL-Lizenz ist fair: SSPL ist im OSI-Sinne nicht Open Source, und das zählt für Firmen, die ein Produkt auf einer Suchmaschine aufsetzen wollen. Aber „kompatibel“ ist ein Spektrum. Query-DSL-Abdeckung, Aggregationen und das Verhalten der Analyzer sind die Stellen, an denen die Unterschiede auftauchen, und die Konformitätssuite ist der einzige Weg zu wissen, auf welcher Seite der Linie man steht.

Sollten Sie es einsetzen

Wenn Ihre Agenten an internem Code, großen privaten Repos oder Logs und Dokumenten arbeiten, die kein Modell gesehen hat, ist die Sache ordentlich: ein lokaler, Apache-2.0-lizenzierter, ES-kompatibler Index mit tree-sitter-Symbolbewusstsein und einem ehrlichen Benchmark. Wenn Ihre Arbeit überwiegend auf öffentlichen Bibliotheken stattfindet, werden Sie mit grep und einer guten ripgrep-Konfiguration vermutlich genauso weit kommen — und viel weniger zu pflegen haben.

Und wenn Sie eine Sache aus diesem Projekt mitnehmen, dann die Gewohnheit der Offenlegung statt der Suchmaschine. Ein Werkzeug, das Ihnen sagt, seine eigenen Zahlen seien aufgebläht, verdient mehr Aufmerksamkeit als eines, das Ihnen sagt, es sei vierzigmal besser.