Codesuche für Agenten hat ein Token-Budget

Semble überschritt am 17. Mai 2026 die Marke von 900 GitHub-Sternen mit einer direkten These: Code-Agenten verschwenden den Großteil ihres Kontextbudgets, wenn sie grep verwenden, ganze Dateien öffnen und deutlich mehr Code lesen, als die Aufgabe verlangt.¹

Die These trifft, weil sie Codesuche als Budgetproblem neu rahmt. Ein Mensch kann ein verrauschtes rg-Ergebnis überfliegen und den Ballast ausblenden. Ein Agent bezahlt für jede irrelevante Zeile mit Kontext, Aufmerksamkeit und Zeit in Werkzeugschleifen.

Kurzfassung

Semble ist eine Codesuchbibliothek für Agenten. Sie bietet einen MCP-Server, Shell-Integration über AGENTS.md oder CLAUDE.md, eine CLI und eine Python-API.¹ Intern zerlegt Semble Code in Abschnitte, sucht mit BM25 plus statischen Model2Vec-Code-Embeddings, führt die Ranglisten mit Reciprocal Rank Fusion zusammen und sortiert anschließend mit codebewussten Signalen neu, etwa Symbolgewichtung, Definition-Boosts, Identifier-Stämmen, Dateikohärenz und Rauschabzügen.¹ Der Benchmark meldet NDCG@10 von 0,854 über rund 1.250 Abfragen in 63 Repositories und 19 Sprachen, nahe am hybriden CodeRankEmbed-Wert von 0,862, während Semble in der Benchmark-Tabelle deutlich schneller indexiert.² Die wichtige Produktlektion lautet nicht: „grep ersetzen.“ Sie ist präziser: Ein Suchwerkzeug für Agenten sollte das kleinste Evidenzpaket zurückgeben, mit dem das Modell korrekt handeln kann.

Zentrale Erkenntnisse

• Für Benutzer von Code-Agenten: Behalten Sie rg für exakte Zeichenketten, nutzen Sie aber snippetbasierte Rangsuche, wenn die Aufgabe Verhalten statt eines wörtlichen Tokens beschreibt.
• Für Werkzeugentwickler: Optimieren Sie den abgerufenen Kontext, nicht nur die Suchgenauigkeit. Die nützliche Einheit ist Evidenz pro Token.
• Für Codex- und Claude Code-Benutzer: Bevorzugen Sie einen über die Shell erreichbaren Pfad für Subagenten, weil MCP-Werkzeuge auf oberster Ebene delegierte Agenten unter Umständen nicht auf dieselbe Weise erreichen.¹
• Für Benchmark-Leser: Trennen Sie Anbieterangaben aus Benchmarks von lokalem Laufzeitverhalten. Mein kalter uvx-Lauf dauerte deutlich länger als Sembles Benchmark-Tabelle, weil Paket-, Modell- und Indexstart dominierten.
• Für öffentliches Schreiben: Suchwerkzeuge ersetzen keine Quellenarbeit. Sie machen nur den Evidenzpfad günstiger zu prüfen.

Warum Grep weiterhin gut ist und trotzdem nicht reicht

rg bleibt das richtige erste Werkzeug für exakte Zeichenketten. Wenn ich visible_label_residue, den Namen einer Credential-Variable oder einen Funktionsnamen brauche, sollte lexikalische Suche bei Geschwindigkeit und Gewissheit gewinnen. In meinem lokalen Test lieferte eine wörtliche rg-Abfrage nach Begriffen für Übersetzungsrückstände nach etwa einer Zehntelsekunde Ergebnisse.⁵

Das Problem beginnt, wenn der Agent die genaue Zeichenkette nicht kennt.

Agenten suchen oft nach Absicht: „Wo prüft die i18n-Schranke des Blogs sichtbare Label-Rückstände?“ oder „Wie funktioniert die Verifikation einer Übersetzungsveröffentlichung?“ Wörtliche Suche kann weiterhin nützliche Zeilen finden, doch der Agent muss Wörter auswählen, Dutzende Treffer prüfen, Dateien lesen, die Abfrage umformulieren und entscheiden, welche Zeile die Antwort trägt. Jeder Schritt verbraucht Kontext und schafft die Möglichkeit, zu früh aufzuhören.

Semble greift genau diesen Fehlermodus an. Der Agent kann in natürlicher Sprache suchen und erhält gerankte Code-Snippets statt ganzer Dateien.¹ Dadurch wird rg nicht überflüssig. Die Standardinteraktion verschiebt sich von „Zeig mir jede Zeile, die diesen Begriff enthält“ zu „Gib mir den kleinsten nützlichen Codeausschnitt.“

Dieser Unterschied zählt, weil Agenten nicht wie Menschen lesen. Menschen können 80 Zeilen Suchausgabe überfliegen und nur die drei interessanten Zeilen im Kopf behalten. Modelle erhalten die ganze Ausgabe als Tokens. Ein verrauschtes Suchergebnis wird Teil der Aufgabenumgebung.

Was Semble tatsächlich macht

Sembles öffentliches README beschreibt vier Integrationspfade: MCP-Server, Bash / AGENTS.md, CLI und Python-API.¹ Das Codex-Setup ist ein lokaler MCP-Servereintrag in ~/.codex/config.toml; der Shell-Pfad ergänzt AGENTS.md oder CLAUDE.md um einen Codesuchabschnitt.¹

Der Shell-Pfad ist wichtiger, als er zunächst wirkt. Das README schreibt, dass Claude Code- und Codex-CLI-Subagenten statt oder zusätzlich zu MCP die Bash-Integration verwenden sollten, weil Subagenten in diesem Setup MCP-Werkzeuge nicht direkt aufrufen können.¹ Das ist ein praktischer Punkt der Agentenschnittstelle: Das Suchwerkzeug muss dort verfügbar sein, wo die Arbeit passiert, nicht nur dort, wo die Sitzung auf oberster Ebene beginnt.

Auch der Suchaufbau zeigt, wohin sich Agentensuche bewegt:

Dieses Design entspricht dem, was ich in lokalen Suchsystemen gesehen habe: Reine Vektorsuche verfehlt Identifier, reine Schlüsselwortsuche verfehlt Absicht, und hybrides Ranking gibt dem Agenten einen besseren ersten Blick.⁴

Die Benchmark-These betrifft Kontext, keine Magie

Sembles Benchmark-README berichtet zwei unterschiedliche Ergebnisklassen.

Die erste misst Suchqualität und Geschwindigkeit. Die Tabelle meldet Semble mit 0,854 NDCG@10, CodeRankEmbed Hybrid mit 0,862, BM25 mit 0,673 und ripgrep mit 0,126. Der Benchmark umfasst etwa 1.250 Abfragen über 63 Repositories in 19 Sprachen, ausgeführt nur auf CPU.²

Die zweite misst Token-Effizienz. Der Benchmark modelliert einen typischen Arbeitsablauf von Code-Agenten: Eine Abfrage wird in Schlüsselwörter zerlegt, rg --fixed-strings --ignore-case wird ausgeführt, Dateien werden nach unterschiedlichen Schlüsselworttreffern gerankt und anschließend vollständig gelesen. Gegen diese Basis meldet der Benchmark durchschnittlich 45.692 Tokens für ripgrep plus Dateilesen gegenüber 566 Tokens für Semble, also eine Reduktion um 98 %.²

Das ist die interessante These. Nicht „semantische Suche schlägt grep“ in jeder Lage. Nicht „Agenten sollten exakte Suche nicht mehr verwenden.“ Die These lautet: Grep plus Dateilesen schiebt zu viel irrelevanten Code ins Modell, wenn die Aufgabe nur wenige Abschnitte braucht.

Die Methodik des Benchmarks erklärt auch, wo die Aussage gelten sollte und wo nicht. Semble vergleicht gegen das vollständige Lesen getroffener Dateien.² Wenn Ihr Arbeitsablauf bereits rg -n, sed und gezielt enge Zeilenbereiche nutzt, ist Ihre Basis womöglich knapper als das Grep-und-Dateilesen-Modell des Benchmarks. Wenn Ihr Agent nach einer breiten Suche routinemäßig ganze Dateien öffnet, liegt der Benchmark näher an Ihrem tatsächlichen Fehlermodus.

Mein lokaler Test

Ich habe Semble im Website-Repository über uvx --from semble semble ausgeführt und es anschließend mit wörtlichen rg-Suchen verglichen.

Ich begann mit einer Abfrage zum Veröffentlichungsprozess:

semble search "blog translation quality gate release verifier D1" . --top-k 5 --include-text-files

Semble gab fünf Snippets zurück. Das oberste Ergebnis fasste die Veröffentlichungsrunde für Blogübersetzungen in einer Tabelle eines Migrationsartikels zusammen. Ein weiteres Ergebnis zeigte direkt auf scripts/i18n-automation/README.md; dort standen die Schritte für Qualitätsschranke, Release-Verifier, Native Review, Commit, Push, Railway, Cloudflare und Live-Smoke.⁵

Der vergleichbare rg-Befehl war schnell, gab aber einen großen Strom wörtlicher Treffer zu Credential-Variablen, blog_release_verify und verwandten Namen über Skripte, Tests und Dokumentation hinweg zurück.⁵ Ein Mensch kann das filtern. Ein Agent muss dafür Kontext aufwenden.

Dann fragte ich nach der Implementierung der Schranke:

semble search "where does the blog i18n gate check visible label residue" . --top-k 5 --include-text-files

Sembles oberstes Ergebnis zeigte auf genau den lokalen Schrankenblock, in dem visible_label_residue zugewiesen, in einen Fehler überführt und für den Befundstatus berücksichtigt wird. Die Ausgabe enthielt die relevanten Zeilen des Funktionskörpers statt einer ganzen Datei.⁵

Die vergleichbare rg-Abfrage war wieder schneller, lieferte aber viele Treffer in Tests, Übersetzungs-Prompts, Reparaturskripten, dem README und der Schrankenimplementierung.⁵

Dieser Test beweist Sembles Benchmark nicht. Mein Aufruf nutzte uvx, lud Pakete und Modellressourcen herunter, indexierte ein großes gemischtes Repository, bezog Markdown- und JSON-Dateien ein und lief aus einem kalten Pfad. Die erste Semble-Abfrage dauerte etwa 54 Sekunden, die zweite etwa 31 Sekunden.⁵ Diese Zahlen passen nicht zur Benchmark-Tabelle des Projekts, und ich würde sie nicht als Semble-Performance-Daten zitieren.

Der Test belegt aber die Produktform. Semble lieferte kleinere, eher antwortförmige Evidenzpakete. Nach zwei Suchen meldete semble savings --verbose nach eigener Datei-versus-Snippet-Methode etwa 38.100 geschätzte eingesparte Tokens bei 94 %.⁵ Behandeln Sie das als werkzeuggemeldete Schätzung, nicht als unabhängige Messung; die Richtung passte aber zur sichtbaren Ausgabe.

Das richtige Denkmodell: Evidenzpakete

Agentensuche sollte Evidenzpakete erzeugen.

Ein Evidenzpaket hat vier Eigenschaften:

Rohes rg liefert Ort und Geschwindigkeit. Vollständige Dateilesevorgänge liefern Kontext, aber zu viel davon. Vektorsuche liefert Absicht, kann aber exakte Namen verfehlen. Ein guter Suchablauf für Agenten kombiniert diese Ansätze:

1. Verwenden Sie exakte Suche, wenn die Aufgabe ein Symbol, einen Fehler, einen Konfigurationsschlüssel, eine Datei oder eine wörtliche Zeichenkette nennt.
2. Verwenden Sie semantische oder hybride Snippet-Rangsuche, wenn die Aufgabe Verhalten beschreibt.
3. Öffnen Sie die ganze Datei erst, nachdem ein Snippet Relevanz bewiesen hat.
4. Zitieren Sie Datei und Zeilenbereich in der finalen Antwort.
5. Versuchen Sie es erneut mit exakter Suche, wenn das Snippet einen konkreten Identifier nahelegt.

Semble kodiert einen Großteil dieses Arbeitsablaufs als Werkzeug. Der Agent braucht weiterhin Urteilsvermögen, und die Evidenzschranke braucht weiterhin eine prüfbare Ablaufspur.

Wie Semble Codex- und Claude Code-Arbeitsabläufe verändert

Die praktische Frage lautet nicht, ob jedes neue Suchwerkzeug installiert werden sollte. Die Frage lautet, wohin Codesuche im Betriebsvertrag des Agenten gehört.

Für Sitzungen auf oberster Ebene kann MCP gut funktionieren, weil der Agent das Werkzeugschema sieht und den Server direkt aufruft. Sembles README enthält MCP-Setup-Beispiele für Claude Code, Codex, OpenCode, Cursor und andere MCP-kompatible Clients.¹

Bei delegierter Arbeit kann Shell-Zugriff wichtiger sein. Sembles README hebt ausdrücklich die Bash-Integration für Claude Code- und Codex-CLI-Subagenten hervor.¹ Ein Subagent, der das MCP-Werkzeug auf oberster Ebene nicht erreicht, kann trotzdem einen Shell-Befehl ausführen, wenn der Arbeitsablauf ihm beibringt, wann und wie.

Die beste Integration kann deshalb unspektakulär aussehen:

## Code Search

Use `semble search` when looking for behavior or related implementation.
Use `rg` when looking for an exact string, symbol, file name, or config key.
Open full files only after the search result proves relevance.
Report file path and line range when citing evidence.

Eine solche Anweisung schlägt eine vage Regel wie „nutze semantische Suche“, weil sie die Routing-Entscheidung benennt. Der Agent lernt, welches Werkzeug zu welcher Frage passt.

Was ich nicht tun würde

Ich würde rg nicht ersetzen.

Der lokale Test hat das deutlich gemacht. rg beantwortete wörtliche Abfragen in etwa einer Zehntelsekunde. Semble lieferte bessere Pakete für verhaltensförmige Abfragen, aber mein kalter Shell-Aufruf hatte reale Start- und Indexierungskosten.⁵

Ich würde Sembles 98-%-Token-Aussage nicht als universell behandeln. Der Benchmark vergleicht gegen Grep plus vollständiges Dateilesen. Die Aussage ist fair, wenn diese Basis dem Agentenverhalten ähnelt. Der Gewinn wird überzeichnet, wenn ein disziplinierter Arbeitsablauf bereits enge Zeilenbereiche liest.

Ich würde die Routing-Entscheidung nicht in einer Black Box verstecken. Agenten müssen wissen, ob sie exakte Suche, semantische Erkundung, verwandte Code-Erkundung oder Evidenzbestätigung betreiben. Werkzeugnutzung ohne Routing-Regeln wird zu einer weiteren Quelle plausibler Fehler, demselben Schnittstellenproblem hinter chatgetriebener Agentenarbeit.

Warum Semble neben das Grep-Paper gehört

Das aktuelle Paper „Is Grep All You Need?“ testete grep und Vektorsuche über Chronos, Claude Code, Codex CLI und Gemini CLI bei Long-Memory-Conversational-QA. Inline-Grep schlug in diesem Umfeld Inline-Vektorsuche, doch die tiefere Lehre des Papers ist wichtiger: Die Ausführungsumgebung veränderte das Ergebnis ebenso stark wie die Suchmethode.³

Semble zeigt aus der Code-Perspektive auf dieselbe operative Ebene. Suchqualität steckt nicht allein im Retriever. Sie entsteht daraus,

• wie die Abfrage geformt wird;
• ob exakte und semantische Pfade beide existieren;
• wie viel Kontext das Werkzeug zurückgibt;
• ob Snippets Datei- und Zeilenevidenz tragen;
• ob der Agent ganze Dateien nur bei Bedarf öffnet;
• ob delegierte Agenten das Werkzeug erreichen können;
• ob die finale Antwort zitiert, was die Suche tatsächlich gefunden hat.

Die Hülle bleibt das Produkt. Suche wird erst nützlich, wenn die Ausführungsumgebung Abruf in Evidenz verwandelt. Deshalb zählt die Steuerfläche für agentisches Design genauso wie der Suchalgorithmus.

Der Standard, den ich will

Ein Suchwerkzeug für Agenten sollte mehr melden als Treffer.

Es sollte melden:

• welche Abfrage ausgeführt wurde;
• welcher Suchpfad verwendet wurde;
• welche Datei und welcher Zeilenbereich betroffen sind;
• welches Snippet zurückgegeben wurde;
• eine Schätzung der zurückgegebenen Tokens;
• ob das Ergebnis aus exakter, semantischer oder hybrider Suche stammt;
• wann der Agent vom Snippet zum vollständigen Dateilesen eskaliert ist.

Diese Ausgabe würde Codesuche prüfbar machen. Ein Reviewer könnte sehen, ob der Agent den richtigen Code gefunden, genug Kontext gelesen und vermieden hat, in irrelevanten Dateien zu versinken. Dasselbe Prinzip treibt Ausführungsspuren von Agenten: Der Beweis liegt im Pfad, nicht nur in der Antwort.

Semble bewegt sich bereits in diese Richtung, indem es Snippet-Größe und Token-Einsparungen als Produktanliegen erster Ordnung behandelt. Der nächste Schritt für Agenten-Ausführungsumgebungen besteht darin, diesen Evidenzpfad in Review-Paketen und finalen Antworten sichtbar zu machen.

Das Ziel ist nicht schönere Suche. Das Ziel sind weniger unbelegte Behauptungen pro Token.

FAQ

Ersetzt Semble grep?

Nein. Verwenden Sie rg für exakte Zeichenketten, Symbole, Konfigurationsschlüssel, Dateinamen und schnelle Bestätigung. Nutzen Sie Semble-artigen Snippet-Abruf, wenn die Aufgabe Verhalten oder verwandte Implementierung beschreibt und der Agent den genauen Identifier nicht kennt.

Hat Ihr lokaler Test Sembles Geschwindigkeitsaussagen bestätigt?

Nein. Mein lokaler uvx-Aufruf dauerte etwa 54 Sekunden für die erste Abfrage und 31 Sekunden für die zweite, vor allem weil Paket-/Modellstart und Indexierung den Ad-hoc-Lauf dominierten. Sembles Benchmark-Tabelle meldet deutlich schnellere kontrollierte Messungen, aber mein lokaler Lauf sollte als Arbeitsablauf-Evidenz behandelt werden, nicht als Performance-Benchmark.²⁵

Hat Ihr lokaler Test die Richtung der Token-Einsparungen bestätigt?

Ja, auf Ebene des Arbeitsablaufs. Semble gab deutlich kleinere Snippets zurück als die breite wörtliche rg-Ausgabe, und der Befehl savings meldete nach zwei Suchen etwa 38.100 geschätzte eingesparte Tokens. Die Einsparungszahl stammt aus Sembles eigener Abrechnungsmethode; behandeln Sie sie daher als Werkzeugtelemetrie und nicht als unabhängigen Beweis.⁵

Warum ist Codesuche für Agenten bei Codex und Claude Code wichtig?

Agenten verlieren Qualität, wenn die Suche zu viel Kontext ausgibt oder zu viel Evidenz versteckt. Ein guter Arbeitsablauf lehrt den Agenten, wann exakte Suche passt, wann snippetbasierter Abruf mit Ranking passt, wann ganze Dateien geöffnet werden müssen und wie das Ergebnis zu zitieren ist.

Sollten Teams Semble zu AGENTS.md hinzufügen?

Erst nach einem Test mit der eigenen Codebasis. Beginnen Sie mit einer Anweisung: Verwenden Sie snippetbasierte Rangsuche für verhaltensförmige Fragen und rg für exakte Zeichenketten. Messen Sie, ob Agenten die richtigen Dateien schneller finden und weniger irrelevante Zeilen lesen.

Quellen