Semble - Code-Suche für Agenten, die 98 % weniger Tokens als grep verbraucht

• Semble ist eine Code-Suchbibliothek, die dafür entwickelt wurde, dass Agenten mit natürlichsprachigen oder Code-Abfragen sofort nur die benötigten Code-Snippets finden
• Im Vergleich zu grep+read verbraucht sie rund 98 % weniger Tokens und gibt statt kompletter Dateien nur relevante Chunks zurück
• Ein durchschnittliches Repository wird in etwa 250 ms indexiert, Anfragen werden in etwa 1,5 ms beantwortet, und das Ganze läuft auf der CPU ohne API-Schlüssel, GPU oder externe Dienste
• Die Benchmarks wurden mit rund 1.250 Abfragen auf 63 Repositories in 19 Sprachen durchgeführt; dabei erreichte Semble 99 % der Qualität von CodeRankEmbed Hybrid, während die Indexierung 218-mal schneller war
• Im Benchmark zur Token-Effizienz verbrauchte Semble im Durchschnitt 98 % weniger Tokens und erreichte mit nur 2k Tokens 94 % Recall, während grep+read bei einem Kontextfenster von 100k auf 85 % Recall kam
• Als MCP-Server kann es mit Claude Code, Cursor, Codex, OpenCode und MCP-kompatiblen Agenten verwendet werden; Repositories werden bei Bedarf geklont und indexiert, und der Index wird während der Sitzung im Cache gehalten
• Auch die Nutzung auf Bash-Basis wird unterstützt, sodass sich semble search- und semble find-related-Workflows in AGENTS.md oder CLAUDE.md einfügen lassen; für Subagenten in Claude Code und Codex CLI ist dieser Weg erforderlich
• Die CLI akzeptiert sowohl lokale Pfade als auch https://-Git-URLs; wenn path weggelassen wird, wird standardmäßig das aktuelle Verzeichnis verwendet
• Es kann auch als Python-Bibliothek verwendet werden, sodass sich die Suche mit SembleIndex.from_path, SembleIndex.from_git, search und find_related in benutzerdefinierte Tools integrieren lässt
• Intern teilt es Dateien mit tree-sitter in codebewusste Chunks auf, kombiniert Embeddings von Model2Vec mit potion-code-16M und BM25 und führt die Scores anschließend per Reciprocal Rank Fusion zusammen
• Das Ranking nutzt lexikalische Gewichtung für symbolische Abfragen, einen Boost für Definitions-Chunks, Identifier-Stemming-Matching, Relevanz innerhalb derselben Datei sowie eine Abwertung für Tests, Legacy-Code, Beispiele und .d.ts
• Da ein statisches Embedding-Modell verwendet wird, gibt es zur Abfragezeit keinen Transformer-Forward-Pass, wodurch Suchen auf der CPU im Millisekundenbereich möglich sind
• semble savings schätzt die eingesparten Tokens, indem für jede Suche die Gesamtzeichenzahl der eindeutigen Dateien mit zurückgegebenen Chunks mit der Zeichenzahl der zurückgegebenen Snippets verglichen wird; die Statistik wird in ~/.semble/savings.jsonl gespeichert
• Das Paket kann als semble über PyPI installiert werden; für die MCP-Nutzung wird die Form uvx --from "semble[mcp]" semble verwendet
• Die Lizenz ist MIT

[GN⁺]

Hacker-News-Kommentare

• Wenn man solche Tools benutzt, sieht man, dass auch die AI selbst dümmer wird, ähnlich wie Entwickler dümmer werden, wenn sie sich zu stark auf AI-Tools verlassen.
  Agentische AI ist bereits klug genug, bei der Code-Erkundung oder -Suche ziemlich optimierte Pfade zu finden, aber wenn man solche Tools dazwischenschaltet, neigt sie dazu, zu aggressiv vorzugehen, weil die Suchergebnisse fast immer nur Pointer statt vollständiger Details liefern.
  Ich habe Pi testweise den vollständigen Sammel- und Suchpfad in einem einigermaßen komplexen Projekt verfolgen lassen; codebase-memory-mcp kam auf 85k/4.4k Input-/Output-Tokens, mein normales Setup auf 67k/3.2k, und ganz ohne Tool waren es 80k/3.2k.
  Ergebnisqualität und Informationsgehalt waren gleich, und dieses Tool war zwar nicht viel, aber eher schlechter.
  Mein normales Setup ist, in AGENTS.md und CLAUDE.md nur eine Zeile zu haben: „Lies mit PROJECT.md beginnend.“
  In PROJECT.md stehen nur 2–3 Zeilen Projektbeschreibung, relevante Dateien mit Ein-Zeilen-Erklärung, Fallstricke und ein Satz für das LLM wie: „Wenn sich etwas zu ändern lohnt, aktualisiere diese Datei. Der Zweck dieser Datei ist es, einen groben Eindruck vom Projekt zu geben und bei Bedarf weitere Erkundung von dort aus zu ermöglichen.“

  • Die Aussage „Agentische AI ist bereits klug genug, bei der Code-Erkundung oder -Suche hochoptimierte Pfade zu finden“ deckt sich nicht mit meiner Erfahrung.
    Bei der Arbeit haben wir früher Augment Code verwendet, das eine MCP-ähnliche Context Engine hatte, die natürlichsprachliche Anfragen über vorab indexierten Code beantwortete.
    Danach sind wir zu Claude Code gewechselt, und seltsamerweise versucht es trotz eines Range-Read-Tools Dateien per sed zu lesen, basierend auf Zeilenbereichen aus seinem Gedächtnis.
    Ich weiß nicht, ob man das wirklich einen hochoptimierten Pfad nennen kann.
  • codebase-memory-mcp und semble sind zwar nicht genau dasselbe, aber der Vergleich ist interessant; ich setze das auf meine Liste zur Überprüfung und füge es wenn möglich zu Benchmarks hinzu.
    Falls du Gelegenheit hast, denselben Vergleich mit semble zu machen, wäre das wirklich nützliches Feedback. Solche „echten“ Szenarien sind schwer zu benchmarken oder zu reproduzieren.

• Interessant. Ich arbeite auch in diesem Bereich, aber mein Ansatz war ein anderer.
  Statt einen Index zu bauen, habe ich ein smarteres grep für ganze Codebases und allgemeinen Text erstellt, mit Ranking und Bewusstsein für Code-Strukturen; die meiste Zeit ging in Performance-Probleme, deshalb läuft es sehr schnell.
  Ich sollte es als Vergleich zu https://github.com/boyter/cs hinzufügen und sehen, was LLMs bei der Art von Fragen bevorzugen, die ich stelle.
  Das bietet ebenfalls MCP, erstellt aber keinen Suchindex. Da es keine Standard-BM25, sondern code-semantische Varianten verwendet, bin ich gespannt, wie das Ranking ausfällt.
  Dieses Tool scheint eher für Anfragen wie „Wie funktioniert die Authentifizierung?“ geeignet zu sein, während cs nach authenticate --only-declarations dann Dateiinhalte berücksichtigt, also ob die Trefferstelle Code oder Kommentar ist, sowie die Gesamtkomplexität der Datei, um Ergebnisse zu gewichten.
  Ich habe einen Stern dagelassen und werde es weiter beobachten.

• Ich weiß, dass dieses Tool für AI gedacht ist, aber mich reizt mehr, es selbst beim Erkunden neuer oder eigener Codebases zu nutzen.
  Es wirkt nützlich, wenn man beim Refactoring die Gesamtform sehen möchte, also wo man überhaupt Änderungen vornehmen muss.
  LSP leistet so etwas zwar auch, aber dieses Tool könnte noch einen Schritt weiter gehen.

• Ich habe ein paar Auswertungen mit Pi und GPT 5.5 gemacht.
  Ich habe RTK an / headroom an / beides an / beides aus getestet; überall mit den Standard-Systemanweisungen von Pi und ohne AGENTS.md.
  Ich habe vergessen, welche Tests es genau waren, aber es waren einige Standard-Agent-Evals, die Leute benutzen, eines in Python und eines in TypeScript, also in den Sprachen, die ich nutze.
  Ich behaupte nicht, dass das gründliche oder gute Tests waren. Vielleicht wären bessere Ergebnisse herausgekommen, wenn ich einen Tag lang AGENTS.md sowie die System-Prompts und Tool-Anweisungen von Pi feinjustiert hätte. Eine Sache, die ich beim Laufenlassen der Evals gelernt habe, ist, dass solche feinen Unterschiede die Ergebnisse stark verändern können.
  Aber beides aus war klar besser, genug, dass ich die Tests nach nur 3 Runden abgebrochen habe.
  Das Problem war: Selbst wenn die Kontextnutzung manchmal sank, stieg die Zahl der Turns bis zum Abschluss, sodass die Gesamtkosten der Unterhaltung höher wurden.
  Mir ist dadurch stark bewusst geworden, dass sehr viele Leute solche Tools teilen, aber entweder gar keine Evals haben, sie verdächtig schwer reproduzierbar sind oder — wie bei diesem Tool trotz vieler Benchmarks — das Falsche gemessen wird.
  Dass dieses Tool weniger Tokens als grep verbraucht, stimmt, und die Benchmarks zeigen das auch, aber das ist nicht das Entscheidende. Entscheidend ist, ob ein Agent mit diesem Tool dieselbe Qualität schneller und günstiger erreicht.

  • Der gesamten AI-Branche fehlt es derzeit an Tests.
    Das ist kein Problem nur dieses Tools, sondern von allem, was AI an Codebases oder Entwicklungsabläufe andockt.
    Schon vor AI gab es keine Tests dafür, „wie schnell und gut ist das entwickelt worden“, und jetzt wurden auch keine ergänzt.
  • In AI wird sehr oft passieren: „Weil wir es konnten, haben wir nicht darüber nachgedacht, ob wir es sollten.“

• Ich würde gern echte Agent-Benchmarks sehen. Zum Beispiel, indem man in Claude Code oder Copilot CLI grep entfernt und dieses Tool stattdessen einsetzt.
  Ich habe mir RTK und verschiedene LSP-Implementierungen angesehen, und die Modelle sind so stark auf grep feinabgestimmt, dass sie anderen Ergebnisformen nicht trauen und immer weiter neu versuchen oder erneut lesen.
  Dadurch verpufft die gesamte Token-Ersparnis, weil das Modell den anderen Tool-Ergebnissen nicht vertraut.

  • Ich habe in ein globales CLAUDE.md (unter ~/.Claude) geschrieben, dass statt grep LSP genutzt werden soll, und danach trat dieses Problem nicht mehr auf.
  • Codex CLI kommt mit RTK ziemlich gut zurecht. Zumindest war das bei GPT 5.5 xhigh so.
    Mich stört aber, dass es bei nicht unterstützten Dingen wie bestimmten CLI-Flags von find nur eine Fehlermeldung ausgibt, statt die vollständige Kommandoausgabe zu senden.
    Dann verschwendet der Agent Tokens mit Wiederholungen oder, schlimmer noch, traut sich wegen des Prompts ohne RTK gar nicht, den Befehl auszuführen.
  • Wir interessieren uns ebenfalls für solche Benchmarks, und Prompt- und Beschreibungsoptimierung, damit Modelle das Tool leichter nutzen, steht mit auf der Roadmap.
    Nur anekdotisch, aber wir verwenden dieses Tool natürlich selbst ebenfalls, und bisher funktioniert es recht gut.
    Die Modelle von Anthropic scheinen dieses Tool aufzurufen und den Ergebnissen zu vertrauen.
  • Token-Ersparnis wird immer wichtiger, aber genauso wichtig ist, ob der Agent den Ergebnissen vertraut und die Suche beendet.
    Man darf nicht nur den Such-Output betrachten, sondern muss die gesamte Agent-Loop messen.
  • Zumindest Codex hört darauf, wenn man sagt, grep sei oft zu langsam und stattdessen rg zu verwenden, aber wenn man RTK hinzufügt, benutzt es über RTK wieder grep, was etwas nervt.

• Die Idee sieht gut aus, also habe ich ein wenig damit herumgespielt.
  Getestet habe ich im Repository browsercode (https://github.com/browser-use/browsercode); der Prompt war: „Verwende nur die semble-CLI und beantworte, welche Tools Browsercode dem Agenten zusätzlich zu den Standard-OpenCode-Tools bereitstellt. Gib das genaue Schema von Tool-Input und -Output sowie eine kurze Zusammenfassung, was sie tun und wie sie funktionieren.“
  Dazu habe ich das AGENTS.md-Snippet aus https://github.com/MinishLab/semble#bash-integration eingefügt.
  Im Test ohne Semble habe ich dieselbe Frage gestellt, aber verlangt, nur rg und fd als CLI zu verwenden.
  In beiden Fällen habe ich Pi und gpt-5.4 medium verwendet und die restliche Konfiguration sehr minimal gehalten. Ich habe auch geprüft, ob tatsächlich in einem Fall nur rg und fd und im anderen nur semble verwendet wurden.
  Ohne Semble wurden 10,9 % des Modellkontexts und API-Credits im Wert von 0,144 $ verbraucht, mit Semble 9,8 % und 0,172 $.
  Die Antworten waren fast identisch, also sehr nah beieinander.
  Ich habe dann noch einmal im OpenCode-Repository getestet; die Frage war: „Verfolge den Pfad von der Stelle, an der die Umgebungsvariable OPENCODE_EXPERIMENTAL_EXA auf 1 gesetzt wird, bis zu den Auswirkungen auf den System-Prompt oder die dem OpenCode-Agenten bereitgestellten Tools.“
  Dabei habe ich dieselben Anweisungen und Dokumente verwendet wie oben.
  Die Nicht-Semble-Version war etwas ausführlicher und behandelte auch, dass der Tool-Aufrufpfad Exa aufruft, je nachdem, ob Exa oder Parallel als Web-Suchanbieter aktiviert ist, aber die eigentliche Frage wurde in beiden Versionen korrekt beantwortet.
  Die Semble-Version verbrauchte 14,7 % Kontext / 0,282 $ API-Kosten, die Nicht-Semble-Version 19,0 % / 0,352 $.
  Bei der Kontexteffizienz war Semble also klar im Vorteil, aber bemerkenswert ist, dass die Nicht-Semble-Version ungefähr doppelt so schnell fertig war.
  Natürlich habe ich nur kurz damit herumgespielt, die Ergebnisse können also anders ausfallen.

• Wenn man sagt, „es verbraucht 98 % weniger Tokens als grep“, soll ich dann glauben, dass grep so verschwenderisch ist, dass das Modell jedes Mal 98 % nutzlosen Müll liest?
  Entweder ist diese Behauptung nicht repräsentativ, oder man verpasst etwas anderes, wenn man den Großteil des Kontexts wegwirft, den man dem Modell geben würde.

  • Die 98 % beziehen sich nicht nur auf die grep-Ausgabe, sondern auf die grep+read-Schleife.
    Wenn ein Agent auf eine unbekannte Codebase trifft, macht er üblicherweise zuerst cat file oder liest ganze Dateien. Zumindest war das meine Erfahrung.
    Wenn du Agenten zuverlässig dazu bringst, nur grep -C N zu machen und dann aufzuhören, würde mich dein Setup wirklich interessieren. Meiner Meinung nach ist die Ergebnisqualität zu niedrig, um als nützlicher Kontext zu dienen.
  • Ich hatte das Problem, dass Claude wegen Treffern in node_modules Ausgaben von Hunderten Kilobyte gelesen hat.
    Da ripgrep hilft, ergibt es Sinn, in irgendeine Memory-Datei eine Zeile zu schreiben, dass es verwendet werden soll.
  • grep gibt alle passenden Zeilen aus.
    Wenn ein LLM eine Suche ausführt, kann das viel Rauschen erzeugen, und es muss vielleicht so suchen, weil es nicht präziser suchen kann.
    Zielgerichtete Suche kann die Tokenzahl reduzieren.
    Allerdings scheint dieser Vergleich eher „nur die nötigen Teile erhalten“ mit „die ganze Codebase lesen“ zu vergleichen.

• Als Feedback: codex-cli hängt sich auf, wenn es das über MCP aufruft.
  Der semble-Prozess bleibt dann ebenfalls als Zombie hängen und steht ewig still. Ich weiß nicht, warum, und im Log steht auch nichts.
  Wenn ich es über einen Skill als CLI-Aufruf verwende, wirft GPT 5.5 extrem viele Suchbegriffe hinein, als wäre es an ripgrep gewöhnt.
  Ich weiß nicht, wie effektiv das ist, und aus der kurzen Dokumentation auf GitHub und den Agent-Anweisungen wird nicht klar, was optimal ist.
  Schließlich gab es bei der Installation für Bash auch einige Fehler im Zusammenhang mit externen Verbindungen außerhalb von GitHub. Ich weiß nicht, ob das mit dem Hängen zusammenhängt.
  Zusätzlich versucht mein Agent danach weiterhin, ripgrep zu benutzen, was doppelt wirkt. Es verhält sich so, als gäbe es ein Vertrauensproblem.
  Eine detailliertere Beschreibung des Agent-Skills könnte helfen, den Agenten zur richtigen Verwendung zu lenken.

  • Danke für das detaillierte Feedback.
    Es wäre hilfreich, wenn du mit den Konfigurationsdetails ein Issue eröffnen könntest. Das ist definitiv etwas, das wir untersuchen und beheben möchten.
    Auch das Problem mit den vielen Anfragen ist sehr gutes Feedback; wir werden die Prompts und Anweisungen aktualisieren und entsprechende Tests ergänzen, damit so etwas nicht passiert.
    Die externen Verbindungsfehler bei der Installation stammen vermutlich daher, dass uv Abhängigkeiten von PyPI lädt; sie sollten nicht die Ursache für das Hängen sein.

• Sieht nach einer guten Idee aus.
  Ein verwandtes Problem ist aber auch, dass Claude bei kleinen Codebases oft die gesamte Codebase auf einmal in den Kontext packen und mit sehr wenigen Tokens verarbeiten könnte, aber stattdessen viel Zeit damit verbringt, etwas zu suchen.
  Ein brauchbarer Workaround ist, per Start-Hook das gesamte Verzeichnis in den Kontext zu legen.
  So überspringt Claude bei jeder Aufgabe diese Phase des „Herumtastens im Dunkeln“.
  Ich habe auch schon ein großartiges Projekt gesehen, das dem Modell in größeren Repositories eine Übersicht mit Stubs gibt, aber ich habe den Namen vergessen.

  • Vielleicht aider? https://aider.chat/2023/10/22/repomap.html
  • Stimmt. Agenten wissen nicht besonders gut, was sie gerade vor sich haben — etwa wie viele Dateien es gibt oder wie groß sie sind.
    Andererseits ist in kleinen Codebases das, was man finden will, auch leichter zu finden, sodass Suche trotzdem noch Kosten sparen kann.

• Das größere Problem bei diesen Lösungen ist, dass die meisten AIs dank ihres Trainings bereits sehr gut mit grep und Suche umgehen können.
  Wenn man einer AI ein neues Tool in die Hand gibt, nimmt dieses Tool ihr einen Teil ihrer kognitiven Fähigkeiten.
  Menschen würden typischerweise lernen, solche Tools zu benutzen, aber das Training eines LLM ist fest, und es verfügt bereits über sehr tiefe Vertrautheit mit bestehenden Tools wie grep.
  Zum Beispiel weiß die AI bereits, wie man mit Linux-Befehlen wie tree eine Codebase erkundet, und auch das ist gut eintrainiert.
  Ein weiteres Problem ist, dass es leicht ist, Beispiele zu bauen, die den Nutzen solcher Tools zeigen, aber schwer, tatsächlich zu beweisen, dass der Nutzen den kognitiven Mangel ausgleicht, den solche Tools bei langen Läufen verursachen.
  Mein erster Instinkt ist, dass die einsetzbare Intelligenz bei langen Läufen netto sinkt und der Agent am Ende schlechter wird, als wenn er bestehende Tools verwendet.
  Das Gegenteil zu beweisen ist kein triviales Problem, aber vielleicht eine Herausforderung, die sich lohnt.