XERJ: Reference Coding mit lokaler Suche und MCP

Was ist XERJ und wofür braucht ein Coding-Agent die Suche?

XERJ indexiert lokale Ordner und stellt die Inhalte über Suchschnittstellen bereit. Ein Coding-Agent kann dadurch nach einer Implementierung, einem Symbol oder einer erklärenden Passage fragen, bevor er selbst Code schreibt. Die dokumentierte Ordnerindexierung verarbeitet neben Quellcode unter anderem Markdown, JSONL, CSV und PDFs. Das Produkt ist weder ein eigenes Coding-LLM noch ein autonomer Programmieragent: Es liefert Material an den Agenten, der die Aufgabe bearbeitet.

Das adressiert ein konkretes Problem. In einer unbekannten Codebase kennt das Modell vielleicht das allgemeine Verfahren, aber nicht die projektspezifische API, ihre Zustandsregeln oder die aktuelle Implementierung. Wiederholtes Suchen und Lesen kann viel Kontext erzeugen. Ein vorbereiteter Index soll stattdessen den relevanten Ausschnitt liefern. Die Release-Dokumentation beschreibt dafür Passage-Retrieval mit Datei- und Zeilenprovenienz sowie Symbolerkennung über tree-sitter.

Kerndatum	Einordnung
Projekt und Kernsprache	xerj-org/xerj, Rust
Lizenz	Apache-2.0
Betriebsmodell	Lokaler Suchserver, CLI und MCP-Adapter; native sowie Elasticsearch-kompatible API
Geprüfte Engine-Version	v1.0.0-rc.97, veröffentlicht am 19.10.2026 um 14:16:06 UTC
GitHub-Stars	12.554 in der Recherche-Momentaufnahme vom 21.10.2026; kein Qualitätsnachweis
Kostenabgrenzung	Open-Source-Binary; Rechnerressourcen, Modellnutzung und optionale externe Dienste kommen hinzu

Quellen: Release-README einschließlich Lizenz, Release-API, GitHub-API für die archivierte Projektmomentaufnahme. Der dynamische API-Endpunkt kann inzwischen andere Starzahlen liefern; ein belastbares Wochenwachstum wurde nicht ermittelt.

Der Artikel ist eine Quellen- und Codeanalyse, kein Hands-on-Test. Für diese Recherche wurde keine XERJ-Binary installiert oder ausgeführt. Veröffentlichte Ergebnisdateien wurden rechnerisch ausgewertet, aber weder Indexierung noch MCP-Betrieb oder Coding-Läufe experimentell wiederholt. Release- und Fixstatus wurden am 21.10.2026 beim Schreiben und im unabhängigen Faktencheck erneut geprüft.

Wie funktioniert Reference Coding mit XERJ?

Reference Coding bedeutet hier: erst die relevante Referenzimplementierung finden und verstehen, dann die eigene Lösung schreiben. Der Agent soll nicht jede Implementierungsregel aus Modellwissen rekonstruieren. Die Projektstudie untersucht genau diesen Unterschied zwischen selbstständiger Dateisuche und vorab bereitgestellter Referenzpassage.

Ein sinnvoller Ablauf sieht so aus:

1. Korpus auswählen: Eigenen Projektcode, passende Dokumentation oder gezielt ausgewählte Referenzprojekte verwenden. Mehr Repositories sind nicht automatisch besser.
2. Revision und Lizenz festhalten: Die Implementierung muss zur verwendeten Version passen. Aus einer gefundenen OSS-Passage folgt keine pauschale Erlaubnis, ihren Code zu übernehmen.
3. Index aufbauen: XERJ erkennt Dateitypen, extrahiert Inhalte und erschließt Code strukturell. Der Suchindex ist eine zusätzliche Kopie beziehungsweise Repräsentation der Quellen.
4. Mechanismus suchen: Nach Verhalten oder Symbol fragen und prüfen, ob der Treffer tatsächlich die gesuchte Regel erklärt.
5. Passage lesen und umsetzen: Herkunft und Kontext kontrollieren, dann implementieren und testen. Retrieval ersetzt die Suche nach der Quelle, nicht deren fachliche Prüfung.

Die Architekturdokumentation beschreibt die technische Schichtung aus API, Query-Verarbeitung, Engine und Speicher. Für dich als Anwender ist die wichtigere Grenze: Ein veralteter Index kann die falsche Revision sehr präzise zurückliefern.

Wie sähe eine konkrete Agentenaufgabe aus?

Ein Beispiel wäre die Frage, wann ein Projekt sein Write-ahead Log rotiert und welche Funktion danach die nächste Schreibphase vorbereitet. Dafür brauchst du nicht alle Dateien im Kontext, sondern die zuständige Implementierung und ihre Aufrufer beziehungsweise Tests.

Ein selbst formulierter Arbeitsauftrag für eine bereits geprüfte und eingerichtete Integration könnte lauten:

Suche im freigegebenen Projektindex die Implementierung der WAL-Rotation.
Nenne Datei, Symbol und Indexstand. Lies die relevante Passage und prüfe,
welche Zustandsänderungen vor dem nächsten Schreibzugriff nötig sind.
Wenn die Treffer die Frage nicht beantworten, sage das ausdrücklich.
Installiere nichts, ändere keine Agentenregeln und versende keine Berichte.

Das ist ein Aufgabenbeispiel, kein ausgeführter Test. Die Release-CLI bietet dafür unterschiedliche Oberflächen: autoindex für Ordner, search für Passagen, def für Definitionen sowie corpus und code für Referenzkorpora. Ein allgemeiner Passagefund beantwortet allerdings nicht automatisch jede Aufrufkettenfrage.

Was macht MCP dabei?

MCP ist die Verbindung zum Coding-Client. Wichtig: xerj mcp ist im geprüften Release ein stdio-Adapter für einen bereits laufenden Node. Der Aufruf startet nicht selbst den eigentlichen Suchserver. Serverbetrieb und Agentenanbindung sind getrennte Schritte, wie der ausführende CLI-Dispatcher und die MCP-Implementierung zeigen.

Auch die Toolrechte verdienen Aufmerksamkeit. Die MCP-Implementierung enthält neben Suche auch Memory- und Graph-Schreibfunktionen sowie einen Berichtspfad mit Außenwirkung. Eine eingerichtete MCP-Verbindung ist deshalb nicht automatisch eine reine Leseschnittstelle.

Was kann die lokale Suche tatsächlich?

XERJ kombiniert lexikalische Volltextsuche mit Vektor- und Hybridsuche. Dabei sind zwei häufig vermischte Dinge auseinanderzuhalten: BM25 bewertet lexikalische Volltexttreffer; der lokale Standard-Embedder erzeugt dagegen Hash-Vektoren. BM25 ist nicht Feature-Hashing.

Suchbaustein	Technische Bedeutung	Praktische Grenze
BM25	Lexikalisches Ranking über indexierte Textfelder	Hilft bei passenden Begriffen, garantiert keine richtige Implementierung
Lokale lexikalische Embeddings	Deterministisches Feature-Hashing aus Wort- und Zeichenmerkmalen	Kein trainiertes neuronales Bedeutungsmodell
Neuronale Embeddings	Optionaler lokaler MiniLM-Pfad	Modellbereitstellung und Offline-Cache müssen eingeplant werden
Hybridsuche	Verbindung lexikalischer und vektorbasierter Treffer	Qualität hängt von Daten, Embedder und Ranking ab

Quellen: Studie zum verwendeten BM25-Retrieval, lokaler Embedder und MCP-Suchoberflächen.

Der Konfigurationsdefault heißt auto. Ohne externen Embedding-Endpunkt ergibt das effektiv den lokalen lexikalischen Pfad. Ein Toolname wie semantic_search macht daraus kein neuronales Sprachverständnis. Der optionale Modus --embed-mode neural verwendet standardmäßig sentence-transformers/all-MiniLM-L6-v2; das Projekt nennt dafür ungefähr 90 MB Modellgewichte. Offline-Betrieb verlangt passend bereitgestellte lokale Modelldateien beziehungsweise einen vorbereiteten Cache. Belege: Embedding-Konfiguration, neuronaler Ladepfad und Release-README.

Das unterscheidet Retrieval von nachgelagerter Token-Kompression mit Headroom: XERJ soll vorher auswählen, welches Material überhaupt in den Kontext kommt. Daraus lässt sich keine gemeinsame Sparrangliste verschiedener Benchmarks ableiten.

Was belegt der Output-Tokenfaktor 2,7?

Die Zahl stammt aus einer projektinternen Studie vom 05.08.2026. Die Multilang-Reihe verwendet vier eigens für die Studie gebaute Referenzbibliotheken, je eine pro Sprache, mit bewusst unbekannten APIs und überprüften Verhaltensregeln. Pro Aufgabe gibt es zwei Trials, also 16 Läufe je Arm. Das ist kein Test auf vier großen privaten Praxiscodebasen. Entscheidend ist die Teilreihe: acht Aufgaben in C, Java, JavaScript und Python, insgesamt 16 Läufe je Vergleichsarm. Nicht 16 Läufe je Aufgabe und nicht die gesamte Studie.

Die agentischen Arme verwenden denselben Claude-Code-Agenten. native bekommt den Referenzbaum auf der Platte und muss suchen; xerj bekommt eine vorab abgerufene Passage, aber nicht den vollständigen Referenzbaum zum Durchsuchen. Der zusätzliche Arm bare arbeitet ohne Tools aus Modellwissen. Er ist eine Untergrenze, nicht die gleichwertige Alltagsbaseline.

Arm der Multilang-Teilreihe	Erfolgreiche Läufe	Output-Tokens gesamt	Historisch gemeldete Kosten, USD
bare: ohne Tools	11/16	260.916	11,18
native: grep-basierter Agent	16/16	26.477	3,27
xerj: bereitgestellte Retrieval-Passage	16/16	9.982	1,58

Quelle: veröffentlichte Multilang-Rohdaten. Die Summen wurden aus den Einzelläufen nachgerechnet; Kosten sind auf Cent gerundet.

Aus den ungerundeten Daten ergibt sich 26.477 / 9.982 = 2,65247…, also gerundet der beworbene Faktor 2,7 für das Verhältnis der Output-Tokens von native zu xerj. Das Verhältnis der historischen Kosten liegt dagegen bei rund 2,06. Das sind unterschiedliche Kennzahlen. Weder Gesamttokens noch heutige End-to-end-Kosten sinken damit nachweislich um denselben Faktor.

Die plausible Erklärung ist enger als das Werbeversprechen: Eine passende Referenz kann Fehlversuche und unnötige Implementierungsarbeit vermeiden. Die Studie belegt aber keine gleich große Wirkung für beliebige Modelle, private Großprojekte oder einen frei suchenden MCP-Agenten. Insbesondere ist das kein Nachweis für GPT 6.1 Sol.

Warum gehört die negative Kontrolle dazu?

Bei Aufgaben zu bekannten öffentlichen Code- und Protokollmustern dreht sich das Bild. In den Realism-Rohdaten löst bare 6/6 Läufe für rund 1,49 USD, native ebenfalls 6/6 für 9,14 USD und xerj 5/6 für 4,40 USD. Auch das sind historische Studienkosten, keine aktuellen Tarife.

Die kleine Kontrolle zeigt: Zusätzliche Referenzen können unnötigen Aufwand erzeugen oder ablenken. Daraus folgt nicht, dass Retrieval bei allen öffentlichen Bibliotheken nutzlos wäre. Es folgt, dass du den Nutzen für deinen Korpus und deine Aufgaben messen musst, statt jede Suche zum Pflichtschritt zu machen.

Lässt sich die Studie vollständig reproduzieren?

Nicht allein aus den veröffentlichten Artefakten. Die Methodik unter „How you reproduce it“ sagt ausdrücklich, dass Messrunner, eigens gebaute Referenzbibliotheken und Hidden-Test-Aufgaben nicht im Repository enthalten sind. Ergebnisdateien nachzurechnen ist möglich; die vollständige Versuchsreihe unverändert neu auszuführen ist damit nicht möglich.

Das ist ein relevantes Herstellersignal mit offen gelegten Grenzen, keine unabhängige Replikation. Ein kleiner Suchoutput, weniger Bytes oder XERJs interne Suchstatistik sind außerdem noch kein kontrollierter Beleg eingesparter LLM-Tokens.

Wann passen ripgrep, Zoekt oder andere Werkzeuge besser?

Der faire Vergleich beginnt bei der Aufgabe, nicht bei einer pauschalen Geschwindigkeitsrangliste. Für diesen Artikel wurden auch die Vergleichswerkzeuge nicht ausgeführt. Die Funktionsbeschreibungen der Alternativen beziehen sich auf ihre am 21.10.2026 gelesene Primärdokumentation, nicht auf gemeinsam installierte oder gegeneinander getestete Releases.

Werkzeug	Passende Frage	Betriebs- und Integrationsaufwand
XERJ	Welche Code- oder Dokumentpassage hilft meinem Agenten?	Suchnode und gepflegter Ordnerindex; CLI, MCP und Such-API
ripgrep	Wo steht dieser Identifier, reguläre Ausdruck oder exakte Text?	Dateisuche ohne persistenten Vorindex; Kontextzeilen sind möglich
Zoekt, Sourcegraph-Fork	Wie suche ich wiederholt Substrings und Regex über viele Repositories?	Vorab gebaute Codeindizes, Such-CLI beziehungsweise Webserver
codebase-memory-mcp	Wer ruft was auf und welche Struktur ist betroffen?	Persistenter SQLite-Codegraph, MCP/CLI und lokaler Coordination-Daemon; zusätzlich Textsuche und Embeddings
Qdrant Server	Wie baue ich eine eigene Vektor- oder Hybrid-Retrievalpipeline?	Datenbankbaustein. Im verlinkten Low-level-Quickstart liefert die umgebende Pipeline die aufzubereitenden Inhalte und Vektoren; ein XERJ-artiger Ordner-Autoindex ist dort nicht der gezeigte Ablauf.

Wenn du den Symbolnamen bereits kennst und der aktuelle Dateistand zählt, bleibt ripgrep eine sinnvolle Baseline. Bei wiederkehrender Suche über gemischte Dokumente und Referenzcode ist XERJs Bündelung interessanter. Für strukturelle Beziehungen setzt codebase-memory-mcp einen anderen Schwerpunkt; dessen aktuelle Primärdokumentation im geprüften Main-Snapshot beschreibt inzwischen auch Text- und semantische Suche. „Graph oder Suche“ wäre daher eine falsche Entweder-oder-Gegenüberstellung.

Welche Einschränkungen bleiben bei Qualität und Betrieb?

Ein falscher kurzer Treffer ist nicht besser als ein langer korrekter. Der Issuebericht zu schwachen Nachbartreffern macht deutlich, warum No-match-Verhalten in einen Retrievaltest gehört: Der Agent muss erkennen können, wann sein Index keine tragfähige Antwort liefert.

Eine kleine Anwenderprobe mit cudarc und candle fand die richtige Passage bei 6 von 10 Fragen unter den ersten fünf Treffern. Sie untersuchte rc.96 und verglich unter anderem Outputbytes, nicht die tatsächliche Tokenabrechnung oder Coding-Lösequote. Der spätere Release rc.97 enthält Rankingkorrekturen; das ersetzt keinen identischen nachgelagerten Test.

Weitere Nutzerberichte betreffen Speicherwachstum und OOM bei JSONL in rc.97, CPU-Last und Stalls im Langzeitbetrieb sowie einen leeren Katalog nach großem Batch. Das sind konkrete Berichte, keine hier reproduzierten Fehler und kein Beweis, dass jede Installation betroffen ist. Eine neutrale, reproduzierte Vergleichsreihe für den geprüften Release wurde in dieser Recherche nicht gefunden.

Auch die Elasticsearch-kompatible API ist kein vollständiger Elasticsearch-Ersatz. Die Release-Unterlagen dokumentieren Grenzen bei Mapping, Berechtigungen und produktionsreifer Replikation. Die Toleranzliste des ES-Testgates enthält 151 eindeutige Testfalleinträge, bei denen Abweichungen von erwarteten Fehlerantworten toleriert werden können. Die Liste wurde nachgezählt; die Suite wurde hier nicht ausgeführt. Ein grünes Projekt-Gate beweist deshalb nicht sämtliche negativen Validierungssemantiken, vollständige Feld-/Dokumentrechte oder Multi-Tenant-Eignung. Dafür sind die Security-Grenzen und die tatsächlich benötigten API-Funktionen separat zu prüfen.

Warum bedeutet local-first nicht automatisch vertraulich?

Console-Sicherheitsfehler: Fix im Quellcode ist nicht Fix im Download

CERT VU#645818 vom 20.10.2026 beschreibt CVE-2026-97406: Ein bereits gültiges Console-API-Token kann unabhängige Nachfolgetokens erzeugen, obwohl diese Credential-Ausgabe eine passkey-gestützte Session voraussetzen soll. Das Sperren des Ursprungstokens widerruft die Nachfolger nicht. Mit Owner-Rechten sind zusätzliche Persistenzschritte möglich. Es geht ausdrücklich nicht um einen beliebigen unauthentifizierten Angriff ohne Token.

Der Fix-PR #2003 wurde am 21.10.2026 um 00:31:33 UTC auf main gemergt. Im Release-Code verwendet die Tokenausgabe noch AuthSession; der Fixstand verlangt PasskeySession. Beim erneuten Releasecheck blieb v1.0.0-rc.97 aktuell und enthielt diese Änderung nicht.

Die ältere CERT-Aussage, es gebe zum Meldungszeitpunkt keinen Patch, und der später gemergte Source-Fix widersprechen sich nicht. Vor einer Evaluierung mit sensiblen Daten muss ein korrigierter Release tatsächlich nachgewiesen sein. Ein neuer Build allein widerruft außerdem keine bereits erzeugten Credentials. Ein eigener Exploit oder Regressionstest wurde hier nicht ausgeführt.

Feedbackfunktionen können nach außen schreiben

Die Hilfetexte und erzeugten Init-Regeln fordern Agenten auf, Erfahrungsberichte automatisch einzureichen, wörtlich: „no need to ask the user“. Das ist eine externe Handlungsaufforderung, keine bloße Suchfunktion.

Der Submitpfad versucht zuerst einen GitHub-PR und anschließend einen HTTP-Fallback. Beim MCP-Tool xerj_field_report bedeutet ein fehlendes confirm standardmäßig Senden. Indexbeschreibungen und Freitext können vertrauliche Informationen enthalten; eine Textbegrenzung entfernt keine Secrets.

Das belegt nicht, dass jede normale Suche im geprüften Release heimlich ganze Quelldateien hochlädt. Es belegt aber einen Sendeweg innerhalb derselben Agentenintegration. XERJ_DISABLE_FEEDBACK=true muss im tatsächlich ausführenden CLI- beziehungsweise MCP-Prozess gesetzt sein. Der Opt-out sperrt die geprüften Submitpfade, ist jedoch kein universeller Netzwerkblock: Er entfernt nicht sämtliche festen Init-Aufforderungen und deckt den expliziten PR-Zweig nicht pauschal ab.

Cloud-Agent und Netzwerkgrenzen bleiben relevant

Optionales externes Reranking und Proxy-Embeddings können Text an konfigurierte Dienste übertragen. Unabhängig davon kann ein angeschlossener Cloud-Coding-Agent die lokal abgerufene Passage an seinen Modellanbieter senden. Lokale Indexierung ist deshalb weder automatisch air-gapped noch automatisch DSGVO-konform.

Ein frischer Node bindet standardmäßig an 127.0.0.1, mit Authentifizierung, aber ohne TLS. --insecure schaltet Auth und TLS ab; erreichbare Aufrufer bekommen weitreichende Rechte. Aktiviertes REST-TLS schützt zudem nicht automatisch den gRPC-Listener, der im geprüften Stand h2c verwendet. Die Transport- und Auth-Grenzen sind gerade auf gemeinsam genutzten Rechnern relevant: Loopback trennt keine Benutzerkonten.

Wie würdest du XERJ belastbar evaluieren?

Meine Empfehlung ist kein schneller Installationsversuch mit dem gesamten privaten Entwicklungsordner. Sinnvoll wäre nach einem nachweislich korrigierten Release ein isolierter Vergleich mit freigegebenen Testdaten. Der folgende Ablauf ist ein Testplan, kein bereits erzieltes Ergebnis:

1. Versions- und Vertrauensgrenzen prüfen: Release, Fix-Abstammung, Agentenregeln, MCP-Tools und ausgehende Verbindungen kontrollieren. Keine langlebigen Produktions- oder GitHub-Credentials mitgeben.
2. Aufgaben vorher definieren: Unbekannte Implementierungsregeln, exakte Symbolsuche, natürlichsprachliche Fragen und echte No-match-Fälle aufnehmen. Die richtigen Sollpassagen vorher festlegen.
3. Gegenkontrolle einbauen: Bekannte Standardaufgaben ergänzen, bei denen Retrieval möglicherweise nur Overhead erzeugt.
4. Gleiches gegen Gleiches messen: Dasselbe Modell, dieselben Aufgaben, Budgets, Tests und Cachebedingungen mit nativer grep/read-Suche und mit XERJ vergleichen. Mehrere Läufe statt eines gelungenen Beispiels.
5. Qualität vor Kürze bewerten: Richtige Datei, Funktion, Revision und Zeilen prüfen; daneben Lösequote, falsche Nachbartreffer und begründete Negativantworten erfassen.
6. Gesamtaufwand erfassen: Input-, Output- und Cache-Tokens getrennt dokumentieren. Indexierungszeit, RAM, CPU, Plattenbedarf und Indexpflege gehören ebenso dazu wie die Modellrechnung.
7. Änderungen testen: Neue, geänderte und gelöschte Dateien einspielen. Ein guter Erstindex belegt noch keine zuverlässige Arbeit mit einer laufend veränderten Codebase.

Der wirtschaftliche Gewinn entsteht erst, wenn der Agent zuverlässig die richtige Lösung mit weniger Gesamtaufwand liefert. Ein kürzerer Tooloutput allein reicht dafür nicht.

FAQ: Häufig gestellte Fragen zu XERJ

Braucht XERJ ein eigenes LLM?

Für lokale Indexierung und lexikalische Suche nicht. Das Coding-LLM ist der angeschlossene Agent; neuronale Embeddings oder externe Reranker sind davon getrennte optionale Bausteine. Siehe Release-Dokumentation.

Ist die semantische Suche standardmäßig neuronal?

Nein. Der frische auto-Default ohne externen Endpunkt verwendet deterministisches lexikalisches Feature-Hashing. Der Konfigurationscode trennt diesen Pfad vom optionalen neuronalen Modus.

Spart XERJ generell den Faktor 2,7 bei Tokens oder Kosten?

Nein. Der gerundete Faktor ist das Verhältnis der Output-Tokens von native zu xerj in einer bestimmten projektinternen Multilang-Teilreihe: 26.477 zu 9.982. Andere Tokenarten, Modelle, Infrastrukturkosten und Aufgaben sind damit nicht abgedeckt.

Bleiben alle Daten auf meinem Rechner?

Nicht automatisch. Lokale Suche ist möglich, aber Berichtsfunktionen, konfigurierte externe Dienste und der angeschlossene Cloud-Agent können Daten nach außen übertragen. Die MCP-Reportimplementierung ist ein konkreter solcher Pfad.

Ist der Console-Sicherheitsfehler im geprüften Release behoben?

Nein. Der Source-Fix liegt auf main, nicht im beim Schreiben aktuell geprüften Release v1.0.0-rc.97. Vor jedem späteren Einsatz muss dieser Status erneut geprüft werden.

Wann reicht ripgrep statt eines Suchservers?

Wenn du exakte Muster, Identifier oder überschaubare aktuelle Dateien durchsuchen willst, ist ripgrep eine sinnvolle erste Wahl. XERJs zusätzlicher Index muss seinen Pflege- und Betriebsaufwand durch bessere Retrievalergebnisse oder vermiedene Sucharbeit rechtfertigen.

Fazit

XERJ zeigt einen sinnvollen Ansatz: Referenzwissen gezielt abrufen, bevor der Coding-Agent eine unbekannte API errät oder ganze Verzeichnisbäume liest. Der Token-Claim trägt nur für seinen beschriebenen Versuchsaufbau; der ungepatchte geprüfte Release und die außenwirksamen Agentenfunktionen sprechen gegen eine pauschale Produktivempfehlung. Meine Empfehlung lautet deshalb: korrigierten Release nachweisen und anschließend isoliert gegen grep/read evaluieren, statt den Suchserver sofort an private Projekte anzuschließen. Für die weitere Einordnung helfen der strukturelle Ansatz von codebase-memory-mcp und die Trennung zwischen Wissen und Fortsetzungszustand im Artikel über Agent Memory als Infrastruktur.

Quellen

Primärquellen: Projekt, Implementierung und Studienartefakte

• XERJ-README am geprüften Releasecommit: Funktionen, Lizenz, dokumentierte Bedienoberflächen und Herstellerclaims.
• Engine-Release v1.0.0-rc.97 und Latest-Release-API: Versions- und Veröffentlichungsstand; beim Schreiben und im unabhängigen Faktencheck erneut abgefragt.
• GitHub-Projekt-API: Starzahl aus der archivierten Recherche-Momentaufnahme, nicht als dauerhaft aktueller Zähler.
• Architektur, ausführender CLI-Dispatcher und MCP-Implementierung: Schichtung, Node-/Adaptertrennung und Toolrechte; das CLI-Inventar im Hilfetext dokumentiert die Bedienoberflächen.
• Reference-Coding-Studie, Multilang-Rohdaten und Realism-Rohdaten: Methodik, nachgerechnete Ergebnisse und negative Kontrolle; keine unabhängige Benchmarkreihe.
• Lokaler Embedder, Embedding-Konfiguration und neuronaler Ladepfad: lexikalischer Default und neuronales Opt-in.
• Security Model, Reranking und Egress sowie ES-Testtoleranzen: Betriebs-, Sicherheits- und Kompatibilitätsgrenzen; Listenzählung statt selbst ausgeführter Testsuite.
• Console-Fix #2003, Release-Tokenpfad und korrigierter Tokenpfad: Source-Fix und Releasegrenze.
• Feedbackaufforderung und Opt-out, Init-Regeln und Submitimplementierung: außenwirksame Agentenfunktionen, nicht pauschal ein Upload sämtlicher Suchdaten.
• Vergleichsdokumentation, gelesen am 21.10.2026, keine gemeinsam getesteten Releases: ripgrep, Zoekt, codebase-memory-mcp am geprüften Main-Commit, Qdrant-Quickstart und Qdrant Server.

Externe Sicherheitsmeldung und attribuierte Anwenderberichte

• CERT VU#645818: externe Sicherheitsmeldung zu CVE-2026-97406, veröffentlicht am 20.10.2026; Meldungsstand vom späteren Source-Fix getrennt betrachtet.
• cudarc/candle-Anwenderbericht: kleine Probe auf rc.96, im Projektrepository veröffentlicht; keine unabhängige Replikation der Tokenstudie.
• Nutzerberichte: JSONL-Speicher/OOM #1940, Langzeitbetrieb #1981, Katalog nach Batch #1977 und schwache Nachbartreffer #1986. Nicht als eigene Reproduktionen verwendet.

Quellenstand: 21.10.2026. Recherche-Synthese: öffentlich geteiltes NotebookLM-Notebook. Die Freigabe ist „Jeder mit Link“ mit vollständiger Notebookansicht; Google kann zum Öffnen trotzdem eine Anmeldung verlangen. Maßgeblich für Claims sind die verlinkten Originalquellen, nicht die Notebook-Synthese.