Warum ich gegen Claude Codes reine Grep-Suche bin? Sie verbraucht einfach zu viele Tokens
KI-Coding-Assistenten explodieren gerade. Allein in den letzten zwei Jahren haben sich Tools wie Cursor, Claude Code, Gemini CLI und Qwen Code von Kuriositäten zu alltäglichen Begleitern für Millionen von Entwicklern entwickelt. Doch hinter diesem rasanten Aufstieg braut sich ein Streit um etwas trügerisch Einfaches zusammen: Wie sollte ein KI-Coding-Assistent eigentlich deine Codebasis nach Kontext durchsuchen?
Derzeit gibt es zwei Ansätze:
Vector search-gestütztes RAG (semantischer Abruf).
Keyword-Suche mit grep (wörtlicher String-Abgleich).
Claude Code und Gemini haben sich für Letzteres entschieden. Tatsächlich hat ein Claude-Ingenieur auf Hacker News offen zugegeben, dass Claude Code überhaupt kein RAG verwendet. Stattdessen grept es einfach dein Repo Zeile für Zeile (was sie „agentic search“ nennen) – keine Semantik, keine Struktur, nur roher String-Abgleich.
Diese Enthüllung spaltete die Community:
Befürworter verteidigen die Einfachheit von grep. Es ist schnell, exakt und – am wichtigsten – vorhersehbar. Beim Programmieren, so argumentieren sie, sei Präzision alles, und heutige Embeddings seien immer noch zu unscharf, um ihnen zu vertrauen.
Kritiker sehen grep als Sackgasse. Es überflutet dich mit irrelevanten Treffern, verbrennt Tokens und bremst deinen Workflow aus. Ohne semantisches Verständnis ist es, als würdest du deine KI mit verbundenen Augen debuggen lassen.
Beide Seiten haben recht. Und nachdem ich meine eigene Lösung gebaut und getestet habe, kann ich sagen: Der auf vector search basierende RAG-Ansatz verändert das Spiel. Er macht die Suche nicht nur dramatisch schneller und genauer, sondern reduziert auch die Token-Nutzung um 40 % oder mehr. (Springe zum Teil Claude Context für meinen Ansatz)
Warum ist grep also so einschränkend? Und wie kann vector search in der Praxis tatsächlich bessere Ergebnisse liefern? Schauen wir es uns an.
Was stimmt nicht mit Claude Codes reiner grep-Code-Suche?
Ich bin beim Debuggen eines kniffligen Problems auf dieses Problem gestoßen. Claude Code feuerte grep-Abfragen über mein Repo ab und warf mir riesige Blöcke irrelevanten Textes zurück. Nach einer Minute hatte ich die relevante Datei immer noch nicht gefunden. Fünf Minuten später hatte ich endlich die richtigen 10 Zeilen – aber sie waren in 500 Zeilen Rauschen vergraben.
Das ist kein Randfall. Ein Blick in die GitHub-Issues von Claude Code zeigt viele frustrierte Entwickler, die gegen dieselbe Wand laufen:
issue1: https://github.com/anthropics/claude-code/issues/1315
issue2: https://github.com/anthropics/claude-code/issues/4556
Die Frustration der Community lässt sich auf drei Schmerzpunkte reduzieren:
Token-Aufblähung. Jeder grep-Dump schaufelt riesige Mengen irrelevanten Codes in das LLM und treibt die Kosten in die Höhe, die mit der Repo-Größe furchtbar skalieren.
Zeitsteuer. Du sitzt fest und wartest, während die KI mit deiner Codebasis „Zwanzig Fragen“ spielt, was Fokus und Flow zerstört.
Null Kontext. Grep gleicht wörtliche Strings ab. Es hat kein Gefühl für Bedeutung oder Beziehungen, sodass du effektiv blind suchst.
Deshalb ist die Debatte wichtig: grep ist nicht nur „old school“, es hält KI-gestütztes Programmieren aktiv zurück.
Claude Code vs Cursor: Warum Letzterer besseren Code-Kontext hat
Wenn es um Code-Kontext geht, hat Cursor bessere Arbeit geleistet. Von Anfang an hat Cursor auf Codebase-Indexing gesetzt: dein Repo in sinnvolle Chunks zerlegen, diese Chunks in Vektoren einbetten und sie semantisch abrufen, wann immer die KI Kontext benötigt. Das ist klassisches Retrieval-Augmented Generation (RAG), angewendet auf Code, und die Ergebnisse sprechen für sich: präziserer Kontext, weniger verschwendete Tokens und schnellerer Abruf.
Claude Code hingegen setzt konsequent auf Einfachheit. Keine Indizes, keine Embeddings—nur grep. Das bedeutet, dass jede Suche ein wörtlicher String-Abgleich ist, ohne Verständnis von Struktur oder Semantik. Theoretisch ist das schnell, aber in der Praxis müssen Entwickler oft Berge irrelevanter Treffer durchsuchen, bevor sie die eine Nadel finden, die sie tatsächlich brauchen.
| Claude Code | Cursor | |
|---|---|---|
| Suchgenauigkeit | Zeigt nur exakte Treffer an—übersieht alles, was anders benannt ist. | Findet semantisch relevanten Code, selbst wenn Keywords nicht exakt übereinstimmen. |
| Effizienz | Grep kippt riesige Code-Blobs in das Modell, was die Token-Kosten erhöht. | Kleinere, signalstärkere Chunks reduzieren die Token-Last um 30–40%. |
| Skalierbarkeit | Grept das Repo jedes Mal erneut, was mit wachsenden Projekten langsamer wird. | Indiziert einmal und ruft dann in großem Maßstab mit minimaler Verzögerung ab. |
| Philosophie | Minimal bleiben—keine zusätzliche Infrastruktur. | Alles indizieren, intelligent abrufen. |
Warum ist Claude (oder Gemini oder Cline) also nicht dem Beispiel von Cursor gefolgt? Die Gründe sind teils technischer und teils kultureller Natur. Vector Retrieval ist nicht trivial—man muss Chunking, inkrementelle Updates und groß angelegte Indexierung lösen. Wichtiger ist jedoch, dass Claude Code auf Minimalismus ausgelegt ist: keine Server, keine Indizes, nur eine saubere CLI. Embeddings und Vektor-DBs passen nicht zu dieser Designphilosophie.
Diese Einfachheit ist attraktiv—aber sie begrenzt auch das, was Claude Code leisten kann. Cursors Bereitschaft, in echte Indexierungsinfrastruktur zu investieren, ist der Grund, warum es sich heute leistungsfähiger anfühlt.
Claude Context: ein Open-Source-Projekt zum Hinzufügen semantischer Codesuche zu Claude Code
Claude Code ist ein starkes Tool—aber es hat einen schwachen Code-Kontext. Cursor hat dieses Problem mit Codebase-Indexierung gelöst, aber Cursor ist Closed-Source, an Abonnements gebunden und teuer für Einzelpersonen oder kleine Teams.
Diese Lücke ist der Grund, warum wir begonnen haben, unsere eigene Open-Source-Lösung zu entwickeln: Claude Context.
Claude Context ist ein Open-Source-MCP-Plugin, das semantische Codesuche zu Claude Code bringt (und zu jedem anderen KI-Coding-Agenten, der MCP spricht). Anstatt dein Repo mit grep per Brute Force zu durchsuchen, integriert es Vektordatenbanken mit Embedding-Modellen, um LLMs tiefen, gezielten Kontext aus deiner gesamten Codebase zu liefern. Das Ergebnis: präzisere Retrievals, weniger Token-Verschwendung und eine deutlich bessere Entwicklererfahrung.
So haben wir es gebaut:
Technologien, die wir verwenden
🔌 Schnittstellenschicht: MCP als universeller Connector
Wir wollten, dass dies überall funktioniert—not nur mit Claude. MCP (Model Context Protocol) funktioniert wie der USB-Standard für LLMs und ermöglicht es externen Tools, sich nahtlos einzuklinken. Indem wir Claude Context als MCP-Server bereitstellen, funktioniert es nicht nur mit Claude Code, sondern auch mit Gemini CLI, Qwen Code, Cline und sogar Cursor.
🗄️ Vektordatenbank: Zilliz Cloud
Als Rückgrat haben wir Zilliz Cloud gewählt (einen vollständig verwalteten Service, der auf Milvus basiert). Sie ist leistungsstark, cloud-nativ, elastisch und für KI-Workloads wie Codebase-Indexierung konzipiert. Das bedeutet Retrieval mit niedriger Latenz, nahezu unbegrenzte Skalierung und grundsolide Zuverlässigkeit.
🧩 Embedding-Modelle: Flexibel by DesignVerschiedene Teams haben unterschiedliche Anforderungen, daher unterstützt Claude Context von Haus aus mehrere Embedding-Anbieter:
OpenAI embeddings für Stabilität und breite Akzeptanz.
Voyage embeddings für code-spezialisierte Performance.
Ollama für datenschutzorientierte lokale Deployments.
Zusätzliche Modelle können bei sich ändernden Anforderungen integriert werden.
💻 Sprachwahl: TypeScript
Wir haben Python vs. TypeScript diskutiert. TypeScript hat gewonnen – nicht nur wegen der Kompatibilität auf Anwendungsebene (VSCode-Plugins, Web-Tooling), sondern auch, weil Claude Code und Gemini CLI selbst auf TypeScript basieren. Das macht die Integration nahtlos und hält das Ökosystem kohärent.
Systemarchitektur
Claude Context folgt einem klaren, geschichteten Design:
Kernmodule übernehmen die Schwerarbeit: Code-Parsing, Chunking, Indexierung, Retrieval und Synchronisierung.
Benutzeroberfläche übernimmt Integrationen – MCP-Server, VSCode-Plugins oder andere Adapter.
Diese Trennung hält die Kern-Engine über verschiedene Umgebungen hinweg wiederverwendbar und ermöglicht gleichzeitig, dass sich Integrationen schnell weiterentwickeln, wenn neue KI-Coding-Assistenten entstehen.
Implementierung der Kernmodule
Die Kernmodule bilden die Grundlage des gesamten Systems. Sie abstrahieren Vektordatenbanken, Embedding-Modelle und andere Komponenten in komponierbare Module, die ein Context-Objekt erstellen und so unterschiedliche Vektordatenbanken und Embedding-Modelle für unterschiedliche Szenarien ermöglichen.
import { Context, MilvusVectorDatabase, OpenAIEmbedding } from '@zilliz/claude-context-core';
// Initialize embedding provider
const embedding = new OpenAIEmbedding(...);
// Initialize vector database
const vectorDatabase = new MilvusVectorDatabase(...);
// Create context instance
const context = new Context({embedding, vectorDatabase});
// Index your codebase with progress tracking
const stats = await context.indexCodebase('./your-project');
// Perform semantic search
const results = await context.semanticSearch('./your-project', 'vector database operations');
Lösung wichtiger technischer Herausforderungen
Beim Aufbau von Claude Context ging es nicht nur darum, Embeddings und eine Vektor-DB miteinander zu verdrahten. Die eigentliche Arbeit bestand darin, die schwierigen Probleme zu lösen, die Code-Indexierung im großen Maßstab gelingen lassen oder scheitern lassen. So sind wir die drei größten Herausforderungen angegangen:
Herausforderung 1: Intelligentes Code-Chunking
Code kann nicht einfach nach Zeilen oder Zeichen aufgeteilt werden. Das erzeugt unübersichtliche, unvollständige Fragmente und entfernt die Logik, die Code verständlich macht.
Wir haben dies mit zwei komplementären Strategien gelöst:
AST-basiertes Chunking (Primäre Strategie)
Dies ist der Standardansatz, der tree-sitter-Parser verwendet, um die Syntaxstruktur von Code zu verstehen und entlang semantischer Grenzen zu teilen: Funktionen, Klassen, Methoden. Das bietet:
Syntaxvollständigkeit – keine zerschnittenen Funktionen oder kaputten Deklarationen.
Logische Kohärenz – zusammengehörige Logik bleibt für besseres semantisches Retrieval beisammen.
Unterstützung mehrerer Sprachen – funktioniert über JS, Python, Java, Go und mehr hinweg über tree-sitter-Grammatiken.
LangChain-Textaufteilung (Fallback-Strategie)
Für Sprachen, die AST nicht parsen kann, oder wenn das Parsing fehlschlägt, bietet LangChains RecursiveCharacterTextSplitter eine zuverlässige Absicherung.
// Use recursive character splitting to maintain code structure
const splitter = RecursiveCharacterTextSplitter.fromLanguage(language, {
chunkSize: 1000,
chunkOverlap: 200,
});
Es ist weniger „intelligent“ als AST, aber äußerst zuverlässig – und stellt sicher, dass Entwickler niemals im Stich gelassen werden. Zusammen balancieren diese beiden Strategien semantische Reichhaltigkeit mit universeller Anwendbarkeit.
Herausforderung 2: Effizienter Umgang mit Codeänderungen
Die Verwaltung von Codeänderungen stellt eine der größten Herausforderungen in Code-Indexierungssystemen dar. Ganze Projekte bei kleineren Dateiänderungen neu zu indexieren, wäre völlig unpraktikabel.
Um dieses Problem zu lösen, haben wir den auf Merkle Trees basierenden Synchronisierungsmechanismus entwickelt.
Merkle Trees: Die Grundlage der Änderungserkennung
Merkle Trees erstellen ein hierarchisches „Fingerabdruck“-System, bei dem jede Datei ihren eigenen Hash-Fingerabdruck hat, Ordner Fingerabdrücke basierend auf ihren Inhalten haben und alles in einem eindeutigen Root-Node-Fingerabdruck für die gesamte Codebasis mündet.
Wenn sich Dateiinhalte ändern, wandern die Hash-Fingerabdrücke kaskadenartig durch jede Schicht nach oben bis zum Wurzelknoten. Dies ermöglicht eine schnelle Änderungserkennung, indem Hash-Fingerabdrücke Schicht für Schicht von der Wurzel abwärts verglichen werden, wodurch Dateiänderungen schnell identifiziert und lokalisiert werden, ohne das gesamte Projekt neu zu indizieren.
Das System führt alle 5 Minuten Handshake-Synchronisierungsprüfungen mithilfe eines optimierten dreiphasigen Prozesses durch:
Phase 1: Blitzschnelle Erkennung berechnet den Merkle-Wurzel-Hash der gesamten Codebasis und vergleicht ihn mit dem vorherigen Snapshot. Identische Wurzel-Hashes bedeuten, dass keine Änderungen stattgefunden haben—das System überspringt die gesamte Verarbeitung in Millisekunden.
Phase 2: Präziser Vergleich wird ausgelöst, wenn sich Wurzel-Hashes unterscheiden, und führt eine detaillierte Analyse auf Dateiebene durch, um genau zu identifizieren, welche Dateien hinzugefügt, gelöscht oder geändert wurden.
Phase 3: Inkrementelle Updates berechnet Vektoren nur für geänderte Dateien neu und aktualisiert die Vektordatenbank entsprechend, wodurch die Effizienz maximiert wird.
Lokale Snapshot-Verwaltung
Der gesamte Synchronisierungszustand wird lokal im Verzeichnis ~/.context/merkle/ des Benutzers gespeichert. Jede Codebasis verwaltet ihre eigene unabhängige Snapshot-Datei, die Datei-Hash-Tabellen und serialisierte Merkle-Baumdaten enthält, wodurch eine genaue Zustandswiederherstellung auch nach Programmneustarts gewährleistet wird.
Dieses Design bietet offensichtliche Vorteile: Die meisten Prüfungen werden in Millisekunden abgeschlossen, wenn keine Änderungen vorliegen, nur tatsächlich geänderte Dateien lösen eine erneute Verarbeitung aus (wodurch massive Rechenverschwendung vermieden wird), und die Zustandswiederherstellung funktioniert nahtlos über Programmsitzungen hinweg.
Aus Sicht der Benutzererfahrung löst die Änderung einer einzelnen Funktion eine Neuindizierung nur für diese Datei aus, nicht für das gesamte Projekt, was die Entwicklungseffizienz erheblich verbessert.
Herausforderung 3: Gestaltung der MCP-Schnittstelle
Selbst die intelligenteste Indizierungs-Engine ist ohne eine saubere entwicklerorientierte Schnittstelle nutzlos. MCP war die offensichtliche Wahl, brachte aber einzigartige Herausforderungen mit sich:
🔹 Tool-Design: Einfach halten
Das MCP-Modul dient als benutzerorientierte Schnittstelle, wodurch die Benutzererfahrung oberste Priorität hat.
Das Tool-Design beginnt damit, standardmäßige Codebasis-Indizierungs- und Suchvorgänge in zwei Kern-Tools zu abstrahieren: index_codebase zum Indizieren von Codebasen und search_code zum Durchsuchen von Code.
Dies wirft eine wichtige Frage auf: Welche zusätzlichen Tools sind notwendig?
Die Anzahl der Tools erfordert ein sorgfältiges Gleichgewicht—zu viele Tools erzeugen kognitiven Aufwand und verwirren die Tool-Auswahl des LLM, während zu wenige wesentliche Funktionalität vermissen lassen könnten.
Von realen Anwendungsfällen rückwärts zu arbeiten hilft, diese Frage zu beantworten.
Bewältigung von Herausforderungen bei der Hintergrundverarbeitung
Große Codebasen können erhebliche Zeit für die Indizierung benötigen. Der naive Ansatz, synchron auf den Abschluss zu warten, zwingt Benutzer dazu, mehrere Minuten zu warten, was schlicht inakzeptabel ist. Asynchrone Hintergrundverarbeitung wird unerlässlich, aber MCP unterstützt dieses Muster nicht nativ.
8.png
Unser MCP-Server führt einen Hintergrundprozess innerhalb des MCP-Servers aus, um die Indizierung zu handhaben, während er Benutzern sofort Startmeldungen zurückgibt, sodass sie weiterarbeiten können.
9.png
Dies schafft eine neue Herausforderung: Wie verfolgen Benutzer den Indizierungsfortschritt?
Ein dediziertes Tool zur Abfrage des Indizierungsfortschritts oder -status löst dies elegant. Der Hintergrund-Indizierungsprozess speichert Fortschrittsinformationen asynchron im Cache, sodass Benutzer jederzeit Abschlussprozentsätze, Erfolgsstatus oder Fehlerbedingungen überprüfen können. Zusätzlich behandelt ein manuelles Tool zum Löschen des Index Situationen, in denen Benutzer ungenaue Indizes zurücksetzen oder den Indizierungsprozess neu starten müssen.
Finales Tool-Design:
index_codebase - Codebasis indizieren
search_code - Code durchsuchen
get_indexing_status - Indizierungsstatus abfragen
clear_index - Index löschen
Vier Tools, die das perfekte Gleichgewicht zwischen Einfachheit und Funktionalität herstellen.
🔹 Verwaltung von Umgebungsvariablen
Die Verwaltung von Umgebungsvariablen wird oft übersehen, obwohl sie die Benutzererfahrung erheblich beeinflusst. Eine separate API-Schlüsselkonfiguration für jeden MCP Client zu verlangen, würde Nutzer dazu zwingen, Anmeldedaten mehrfach zu konfigurieren, wenn sie zwischen Claude Code und Gemini CLI wechseln.
Ein globaler Konfigurationsansatz beseitigt diese Reibung, indem eine ~/.context/.env-Datei im Home-Verzeichnis des Nutzers erstellt wird:
# ~/.context/.env
OPENAI_API_KEY=your-api-key-here
MILVUS_TOKEN=your-milvus-token
Dieser Ansatz bietet klare Vorteile: Nutzer konfigurieren einmal und verwenden die Konfiguration überall über alle MCP-Clients hinweg, alle Konfigurationen werden für einfache Wartung an einem einzigen Ort zentralisiert, und sensible API-Schlüssel verteilen sich nicht über mehrere Konfigurationsdateien.
Wir implementieren außerdem eine dreistufige Prioritätshierarchie: Prozess-Umgebungsvariablen haben höchste Priorität, globale Konfigurationsdateien haben mittlere Priorität, und Standardwerte dienen als Fallbacks.
Dieses Design bietet enorme Flexibilität: Entwickler können Umgebungsvariablen für temporäre Test-Overrides nutzen, Produktionsumgebungen können sensible Konfigurationen über Systemumgebungsvariablen für erhöhte Sicherheit injizieren, und Nutzer konfigurieren einmal, um nahtlos über Claude Code, Gemini CLI und andere Tools hinweg zu arbeiten.
Zu diesem Zeitpunkt ist die Kernarchitektur des MCP-Servers vollständig und umfasst Code-Parsing und Vektorspeicherung ebenso wie intelligente Abfrage und Konfigurationsmanagement. Jede Komponente wurde sorgfältig entworfen und optimiert, um ein System zu schaffen, das sowohl leistungsstark als auch benutzerfreundlich ist.
Praktischer Test
Wie schlägt sich Claude Context also tatsächlich in der Praxis? Ich habe es gegen exakt dasselbe Bug-Hunting-Szenario getestet, das mich anfangs frustriert zurückgelassen hatte.
Die Installation war nur ein einziger Befehl, bevor Claude Code gestartet wurde:
claude mcp add claude-context -e OPENAI_API_KEY=your-openai-api-key -e MILVUS_TOKEN=your-zilliz-cloud-api-key -- npx @zilliz/claude-context-mcp@latest
Sobald meine Codebasis indexiert war, gab ich Claude Code dieselbe Fehlerbeschreibung, die es zuvor auf eine fünfminütige, grep-getriebene Schnitzeljagd geschickt hatte. Diesmal lokalisierte es über claude-context-MCP-Aufrufe sofort die genaue Datei und Zeilennummer, inklusive einer Erklärung des Problems.
Der Unterschied war nicht subtil – es war ein Unterschied wie Tag und Nacht.
Und es ging nicht nur um Bug Hunting. Mit integriertem Claude Context lieferte Claude Code durchgängig hochwertigere Ergebnisse bei:
Problemlösung
Code-Refactoring
Erkennung von dupliziertem Code
Umfassenden Tests
Der Leistungsschub zeigt sich auch in den Zahlen. In direkten Vergleichstests:
Der Token-Verbrauch sank um über 40 %, ohne Recall-Verlust.
Das führt direkt zu niedrigeren API-Kosten und schnelleren Antworten.
Alternativ lieferte Claude Context bei gleichem Budget deutlich genauere Abfrageergebnisse.
Wir haben Claude Context auf GitHub als Open Source veröffentlicht, und es hat bereits über 2,6K Sterne erhalten. Vielen Dank euch allen für eure Unterstützung und Likes.
Du kannst es selbst ausprobieren:
Detaillierte Benchmarks und die Testmethodik sind im Repo verfügbar – wir freuen uns über dein Feedback.
Ausblick
Was als Frustration über grep in Claude Code begann, ist zu einer soliden Lösung herangewachsen: Claude Context – ein Open-Source-MCP-Plugin, das semantische, vektorbasierte Suche zu Claude Code und anderen Coding-Assistenten bringt. Die Botschaft ist einfach: Entwickler müssen sich nicht mit ineffizienten KI-Tools zufriedengeben. Mit RAG und Vektor-Retrieval kannst du schneller debuggen, Token-Kosten um 40 % senken und endlich KI-Unterstützung erhalten, die deine Codebasis wirklich versteht.
Und das ist nicht auf Claude Code beschränkt. Da Claude Context auf offenen Standards basiert, funktioniert derselbe Ansatz nahtlos mit Gemini CLI, Qwen Code, Cursor, Cline und darüber hinaus. Schluss damit, an Anbieter-Kompromisse gebunden zu sein, die Einfachheit über Leistung stellen.
Wir würden uns freuen, wenn du Teil dieser Zukunft wirst:
Probiere Claude Context** aus:** Es ist Open Source und völlig kostenlos
Trage zu seiner Entwicklung bei
Oder entwickle deine eigene Lösung mit Claude Context
👉 Teile dein Feedback, stelle Fragen oder erhalte Hilfe, indem du unserer Discord-Community beitrittst.
Weiterlesen
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.