Home
Blog
Warum KI-Agenten wie OpenClaw Token verbrauchen und wie man die Kosten senken kann

Warum KI-Agenten wie OpenClaw Token verbrauchen und wie man die Kosten senken kann

Engineering

February 28, 2026

Min Yin

Wenn Sie schon etwas Zeit mit OpenClaw (früher Clawdbot und Moltbot) verbracht haben, wissen Sie bereits, wie gut dieser KI-Agent ist. Er ist schnell, lokal, flexibel und in der Lage, überraschend komplexe Workflows über Slack, Discord, Ihre Codebasis und praktisch alles andere, in das Sie ihn einbinden, abzuwickeln. Aber sobald man anfängt, es ernsthaft zu nutzen, zeigt sich schnell ein Muster: Der Tokenverbrauch steigt.

Das ist nicht die Schuld von OpenClaw - so verhalten sich die meisten KI-Agenten heutzutage. Sie lösen für fast alles einen LLM-Aufruf aus: eine Datei nachschlagen, eine Aufgabe planen, eine Notiz schreiben, ein Tool ausführen oder eine Folgefrage stellen. Und da Token die universelle Währung dieser Aufrufe sind, hat jede Aktion ihre Kosten.

Um zu verstehen, woher diese Kosten kommen, müssen wir einen Blick unter die Haube auf zwei große Mitwirkende werfen:

Die Suche: Schlecht konstruierte Suchvorgänge ziehen ausufernde Kontext-Payloads nach sich - ganze Dateien, Protokolle, Nachrichten und Codebereiche, die das Modell eigentlich nicht benötigt.
Speicher: Das Speichern unwichtiger Informationen zwingt den Agenten dazu, diese bei zukünftigen Aufrufen erneut zu lesen und zu verarbeiten, wodurch der Tokenverbrauch im Laufe der Zeit steigt.

Beide Probleme erhöhen stillschweigend die Betriebskosten, ohne die Fähigkeiten zu verbessern.

Wie KI-Agenten wie OpenClaw tatsächlich Suchvorgänge durchführen - und warum das Token verbrennt

Wenn ein Agent Informationen aus Ihrer Codebasis oder Dokumentenbibliothek benötigt, führt er normalerweise das Äquivalent einer projektweiten Strg+F-Funktion aus. Jede übereinstimmende Zeile wird zurückgegeben - ungeordnet, ungefiltert und unpriorisiert. Claude Code implementiert dies durch ein spezielles Grep-Tool, das auf ripgrep aufbaut. OpenClaw hat kein eingebautes Tool für die Codebase-Suche, aber sein exec-Tool lässt das zugrunde liegende Modell jeden Befehl ausführen, und geladene Skills können den Agenten dazu bringen, Tools wie rg zu verwenden. In beiden Fällen liefert die Codebase-Suche Schlüsselwortübereinstimmungen ohne Rangfolge und ungefiltert.

Dieser Brute-Force-Ansatz funktioniert gut bei kleinen Projekten. Aber wenn die Repositories wachsen, steigt auch der Preis. Irrelevante Treffer stapeln sich im Kontextfenster des LLM und zwingen das Modell dazu, Tausende von Token zu lesen und zu verarbeiten, die es eigentlich nicht braucht. Eine einzige unskopierte Suche kann ganze Dateien, riesige Kommentarblöcke oder Protokolle, die ein Schlüsselwort, aber nicht die zugrundeliegende Absicht enthalten, anziehen. Wiederholt man dieses Muster über eine lange Debugging- oder Forschungssitzung, summiert sich die Menge schnell.

Sowohl OpenClaw als auch Claude Code versuchen, dieses Wachstum zu kontrollieren. OpenClaw beschneidet übergroße Werkzeugausgaben und komprimiert lange Gesprächsverläufe, während Claude Code die Ausgabe von Dateien begrenzt und Kontextverdichtung unterstützt. Diese Abhilfemaßnahmen funktionieren - allerdings erst, nachdem die aufgeblähte Abfrage bereits ausgeführt wurde. Die nicht bewerteten Suchergebnisse verbrauchen immer noch Token, und Sie haben immer noch dafür bezahlt. Die Kontextverwaltung hilft zukünftigen Abfragen, nicht dem ursprünglichen Aufruf, der die Verschwendung verursacht hat.

Wie der Speicher des KI-Agenten funktioniert und warum auch er Token kostet

Die Suche ist nicht die einzige Quelle für den Token-Overhead. Jedes Stück Kontext, das ein Agent aus dem Speicher abruft, muss auch in das Kontextfenster des LLM geladen werden, und das kostet ebenfalls Token.

Die LLM-APIs, auf die sich die meisten Agenten heute verlassen, sind zustandslos: Die Nachrichten-API von Anthropic erfordert bei jeder Anfrage den vollständigen Gesprächsverlauf, und die Chat Completions-API von OpenAI arbeitet auf die gleiche Weise. Sogar die neuere zustandsabhängige API von OpenAI, die den Konversationsstatus serverseitig verwaltet, verlangt bei jedem Aufruf immer noch das vollständige Kontextfenster. Der in den Kontext geladene Speicher kostet Token, unabhängig davon, wie er dorthin gelangt.

Um dies zu umgehen, schreiben Agent-Frameworks Notizen in Dateien auf der Festplatte und laden relevante Notizen zurück in das Kontextfenster, wenn der Agent sie benötigt. OpenClaw zum Beispiel speichert kuratierte Notizen in MEMORY.md und hängt tägliche Protokolle an zeitgestempelte Markdown-Dateien an, die dann mit einer hybriden BM25- und Vektorsuche indiziert werden, damit der Agent bei Bedarf relevanten Kontext abrufen kann.

Das Speicherdesign von OpenClaw funktioniert gut, aber es erfordert das gesamte OpenClaw-Ökosystem: den Gateway-Prozess, die Verbindungen zur Messaging-Plattform und den Rest des Stacks. Das Gleiche gilt für den Speicher von Claude Code, der an seine CLI gebunden ist. Wenn Sie einen benutzerdefinierten Agenten außerhalb dieser Plattformen erstellen möchten, benötigen Sie eine eigenständige Lösung. Der nächste Abschnitt behandelt die Werkzeuge, die für beide Probleme zur Verfügung stehen.

Wie man OpenClaw davon abhält, Token zu verbrauchen

Wenn Sie den Token-Verbrauch von OpenClaw reduzieren wollen, können Sie zwei Hebel in Bewegung setzen.

Der erste ist eine bessere Abfrage - das Ersetzen von Schlüsselwort-Dumps im Grep-Stil durch bewertete, relevanzgesteuerte Suchwerkzeuge, damit das Modell nur die Informationen sieht, die wirklich wichtig sind.
Der zweite ist ein besserer Speicher - weg von undurchsichtigen, vom Framework abhängigen Speichern hin zu etwas, das Sie verstehen, überprüfen und kontrollieren können.

Ersetzen von grep durch besseres Retrieval: index1, QMD und Milvus

Viele KI-Codieragenten durchsuchen Codebasen mit grep oder ripgrep. Claude Code hat ein eigenes Grep-Tool, das auf ripgrep aufbaut. OpenClaw hat kein eingebautes Tool für die Suche in Codebasen, aber sein exec-Tool lässt das zugrunde liegende Modell jeden Befehl ausführen, und Skills wie ripgrep oder QMD können geladen werden, um die Suche des Agenten zu steuern. Ohne einen auf die Suche ausgerichteten Skill greift der Agent auf den Ansatz zurück, den das zugrunde liegende Modell wählt. Das Kernproblem ist bei allen Agenten dasselbe: Ohne eine Rangfolge der Suchvorgänge gelangen die Schlüsselworttreffer ungefiltert in das Kontextfenster.

Das funktioniert, wenn ein Projekt so klein ist, dass jeder Treffer bequem in das Kontextfenster passt. Das Problem beginnt, wenn eine Codebasis oder Dokumentenbibliothek so groß wird, dass ein Schlüsselwort Dutzende oder Hunderte von Treffern liefert und der Agent sie alle in die Eingabeaufforderung laden muss. In dieser Größenordnung müssen die Ergebnisse nach Relevanz geordnet werden, nicht nur nach Übereinstimmung gefiltert.

Die Standardlösung ist die hybride Suche, die zwei sich ergänzende Bewertungsmethoden kombiniert:

BM25 bewertet jedes Ergebnis danach, wie oft und wie eindeutig ein Begriff in einem bestimmten Dokument vorkommt. Eine fokussierte Datei, in der der Begriff "Authentifizierung" 15 Mal erwähnt wird, wird höher eingestuft als eine weitläufige Datei, in der er nur einmal erwähnt wird.
Die Vektorsuche wandelt Text in numerische Darstellungen der Bedeutung um, so dass "Authentifizierung" mit "Login-Flow" oder "Sitzungsmanagement" übereinstimmen kann, auch wenn sie keine Schlüsselwörter gemeinsam haben.

Keine der beiden Methoden allein ist ausreichend: BM25 übersieht umschriebene Begriffe, und die Vektorsuche übersieht exakte Begriffe wie Fehlercodes. Die Kombination beider Methoden und die Zusammenführung der Ranglisten durch einen Fusionsalgorithmus deckt beide Lücken ab.

Die nachstehenden Tools setzen dieses Muster in unterschiedlichem Umfang um. Grep ist die Basis, mit der alle beginnen. index1, QMD und Milvus fügen jeweils eine hybride Suche mit steigender Kapazität hinzu.

index1: schnelle hybride Suche auf einem einzigen Rechner

index1 ist ein CLI-Tool, das die hybride Suche in einer einzigen SQLite-Datenbankdatei zusammenfasst. FTS5 verarbeitet BM25, sqlite-vec verarbeitet Vektorähnlichkeit und RRF fusioniert die Ranglisten. Die Einbettungen werden lokal von Ollama generiert, so dass nichts Ihren Rechner verlässt.

index1 gliedert den Code nach Struktur, nicht nach Zeilenzahl: Markdown-Dateien werden nach Überschriften aufgeteilt, Python-Dateien nach AST, JavaScript und TypeScript nach Regex-Mustern. Das bedeutet, dass die Suchergebnisse zusammenhängende Einheiten wie eine vollständige Funktion oder einen kompletten Dokumentationsabschnitt zurückgeben und nicht beliebige Zeilenbereiche, die in der Mitte des Blocks abgeschnitten werden. Die Antwortzeit beträgt 40 bis 180 ms für hybride Abfragen. Ohne Ollama fällt die Suche auf BM25-only zurück, das immer noch eine Rangfolge der Ergebnisse erstellt, anstatt jede Übereinstimmung in das Kontextfenster zu übertragen.

index1 enthält auch ein episodisches Speichermodul, um gelernte Lektionen, Fehlerursachen und Architekturentscheidungen zu speichern. Diese Erinnerungen befinden sich in der gleichen SQLite-Datenbank wie der Code-Index und nicht als eigenständige Dateien.

Hinweis: index1 ist ein Projekt im Anfangsstadium (0 Sterne, 4 Commits im Februar 2026). Prüfen Sie es mit Ihrer eigenen Codebasis, bevor Sie es einsetzen.

Am besten geeignet für: Einzelentwickler oder kleine Teams mit einer Codebasis, die auf einen Rechner passt, und die eine schnelle Verbesserung gegenüber grep suchen.
Erweitern Sie es, wenn Sie den Zugriff mehrerer Benutzer auf denselben Index benötigen oder Ihre Daten den Umfang einer einzelnen SQLite-Datei übersteigen.

QMD: Höhere Genauigkeit durch lokale LLM-Neueinstufung

QMD (Query Markup Documents), entwickelt vom Shopify-Gründer Tobi Lütke, fügt eine dritte Stufe hinzu: LLM-Re-Ranking. Nachdem BM25 und die Vektorsuche jeweils Kandidaten geliefert haben, liest ein lokales Sprachmodell die Top-Ergebnisse neu ein und ordnet sie nach ihrer tatsächlichen Relevanz für die Suchanfrage neu an. Auf diese Weise werden Fälle abgefangen, in denen sowohl Schlüsselwörter als auch semantische Übereinstimmungen plausible, aber falsche Ergebnisse liefern.

QMD läuft vollständig auf Ihrem Rechner unter Verwendung von drei GGUF-Modellen mit einer Gesamtgröße von etwa 2 GB: ein Einbettungsmodell (embeddinggemma-300M), ein Cross-Encoder-Reranker (Qwen3-Reranker-0.6B) und ein Abfrageerweiterungsmodell (qmd-query-expansion-1.7B). Alle drei werden beim ersten Durchlauf automatisch heruntergeladen. Keine Cloud-API-Aufrufe, keine API-Schlüssel.

Der Nachteil ist die Kaltstartzeit: Das Laden der drei Modelle von der Festplatte dauert etwa 15 bis 16 Sekunden. QMD unterstützt einen persistenten Servermodus (qmd mcp), der die Modelle zwischen den Abfragen im Speicher hält, wodurch die Kaltstartzeit bei wiederholten Abfragen entfällt.

Am besten geeignet für: datenschutzkritische Umgebungen, in denen keine Daten Ihren Rechner verlassen dürfen und in denen die Abfragegenauigkeit wichtiger ist als die Antwortzeit.
Wachsen Sie über sich hinaus, wenn Sie Antworten im Bereich von weniger als einer Sekunde benötigen, einen gemeinsamen Zugriff im Team benötigen oder Ihr Datenbestand die Kapazität eines einzelnen Rechners übersteigt.

Milvus: Hybride Suche auf Team- und Unternehmensebene

Die oben genannten Einzelmaschinen-Tools eignen sich gut für einzelne Entwickler, stoßen aber an ihre Grenzen, wenn mehrere Personen oder Agenten Zugriff auf dieselbe Wissensdatenbank benötigen.

Milvus ist eine Open-Source-Vektordatenbank, die für diese nächste Stufe entwickelt wurde: verteilt, mit mehreren Benutzern und in der Lage, Milliarden von Vektoren zu verarbeiten.

Die Schlüsselfunktion für diesen Anwendungsfall ist das eingebaute Sparse-BM25, das seit Milvus 2.5 verfügbar ist und in 2.6 deutlich schneller ist. Sie stellen Rohtext zur Verfügung und Milvus tokenisiert ihn intern mit einem auf tantivy aufbauenden Analysator und konvertiert dann das Ergebnis in Sparse-Vektoren, die vorberechnet und zur Indexzeit gespeichert werden.

Da die BM25-Darstellung bereits gespeichert ist, müssen bei der Abfrage keine Punktwerte neu berechnet werden. Diese spärlichen Vektoren befinden sich neben den dichten Vektoren (semantische Einbettungen) in derselben Sammlung. Zum Zeitpunkt der Abfrage werden beide Signale mit einem Ranker wie RRFRanker fusioniert, den Milvus standardmäßig bereitstellt. Das gleiche hybride Suchmuster wie index1 und QMD, aber auf einer horizontal skalierbaren Infrastruktur.

Milvus bietet auch Funktionen, die Single-Machine-Tools nicht bieten können: Multi-Tenant-Isolation (separate Datenbanken oder Sammlungen pro Team), Datenreplikation mit automatischem Failover und Hot/Cold Data Tiering für kosteneffiziente Speicherung. Für Agenten bedeutet dies, dass mehrere Entwickler oder mehrere Agenteninstanzen gleichzeitig dieselbe Wissensdatenbank abfragen können, ohne auf die Daten der jeweils anderen zuzugreifen.

Am besten geeignet für: mehrere Entwickler oder Agenten, die sich eine Wissensdatenbank teilen, große oder schnell wachsende Dokumentensätze oder Produktionsumgebungen, die Replikation, Failover und Zugriffskontrolle benötigen.

Zusammengefasst:

Werkzeug	Stufe	Bereitstellung	Migrationssignal
Claude Native Grep	Prototyping	Eingebaut, keine Einrichtung	Rechnungen klettern oder Abfragen verlangsamen sich
index1	Ein-Maschinen-System (Geschwindigkeit)	Lokales SQLite + Ollama	Mehrbenutzerzugriff erforderlich oder Daten wachsen über einen Rechner hinaus
QMD	Einzelplatzrechner (Genauigkeit)	Drei lokale GGUF-Modelle	Gemeinsame Indizes für das Team erforderlich
Milvus	Team oder Produktion	Verteilter Cluster	Große Dokumentensätze oder Multi-Tenant-Anforderungen

Reduzierung der Token-Kosten für KI-Agenten durch Bereitstellung eines dauerhaften, bearbeitbaren Speichers mit memsearch

Die Suchoptimierung reduziert die Token-Verschwendung pro Abfrage, aber sie hilft nicht bei dem, was der Agent zwischen den Sitzungen speichert.

Jedes Stück Kontext, das ein Agent aus dem Speicher abruft, muss in die Eingabeaufforderung geladen werden, und auch das kostet Token. Die Frage ist nicht, ob Speicher gespeichert werden soll, sondern wie. Die Speichermethode bestimmt, ob Sie sehen können, was der Agent sich merkt, ob Sie es korrigieren können, wenn es falsch ist, und ob Sie es mitnehmen können, wenn Sie das Werkzeug wechseln.

Die meisten Frameworks versagen in allen drei Punkten. Mem0 und Zep speichern alles in einer Vektordatenbank, was für den Abruf funktioniert, aber den Speicher undurchsichtig macht:

Undurchsichtig. Man kann nicht sehen, was der Agent sich merkt, ohne eine API abzufragen.
Schwer zu bearbeiten. Das Korrigieren oder Entfernen eines Speichers bedeutet API-Aufrufe, nicht das Öffnen einer Datei.
Eingesperrt. Ein Wechsel des Frameworks bedeutet, dass Sie Ihre Daten exportieren, konvertieren und wieder importieren müssen.

OpenClaw verfolgt einen anderen Ansatz. Der gesamte Speicher wird in einfachen Markdown-Dateien auf der Festplatte gespeichert. Der Agent schreibt automatisch tägliche Protokolle, und Menschen können jede Speicherdatei direkt öffnen und bearbeiten. Damit sind alle drei Probleme gelöst: Der Speicher ist lesbar, bearbeitbar und portabel.

Der Nachteil ist der Aufwand für die Bereitstellung. Das Ausführen des OpenClaw-Speichers bedeutet, dass das gesamte OpenClaw-Ökosystem ausgeführt wird: der Gateway-Prozess, die Verbindungen zur Messaging-Plattform und der Rest des Stacks. Für Teams, die bereits OpenClaw verwenden, ist das in Ordnung. Für alle anderen ist die Hürde zu hoch. memsearch wurde entwickelt, um diese Lücke zu schließen: es extrahiert OpenClaw's Markdown-first memory pattern in eine eigenständige Bibliothek, die mit jedem Agenten funktioniert.

memsearch, entwickelt von Zilliz (dem Team hinter Milvus), behandelt Markdown-Dateien als einzige Quelle der Wahrheit. Eine MEMORY.md enthält langfristige Fakten und Entscheidungen, die Sie von Hand schreiben. Tägliche Protokolle (2026-02-26.md) werden automatisch aus Sitzungszusammenfassungen erstellt. Der Vektorindex, der in Milvus gespeichert wird, ist eine abgeleitete Schicht, die jederzeit aus der Markdown-Datei neu erstellt werden kann.

In der Praxis bedeutet dies, dass Sie jede beliebige Speicherdatei in einem Texteditor öffnen, genau das lesen können, was der Agent weiß, und es ändern können. Speichern Sie die Datei, und der Datei-Überwacher von memsearch erkennt die Änderung und indiziert automatisch neu. Sie können Speicher mit Git verwalten, KI-generierte Speicher über Pull-Requests überprüfen oder durch Kopieren eines Ordners auf einen neuen Rechner verschieben. Wenn der Milvus-Index verloren geht, bauen Sie ihn aus den Dateien neu auf. Die Dateien sind nie in Gefahr.

Unter der Haube verwendet memsearch dasselbe hybride Suchmuster wie oben beschrieben: Chunks, die nach Überschriftenstruktur und Absatzgrenzen aufgeteilt sind, BM25 + Vektorabfrage und ein LLM-gestützter kompakter Befehl, der alte Erinnerungen zusammenfasst, wenn die Protokolle groß werden.

Am besten geeignet für: Teams, die vollen Einblick in das haben wollen, was der Agent sich merkt, die Versionskontrolle über den Speicher benötigen oder ein Speichersystem wollen, das nicht an ein einzelnes Agent-Framework gebunden ist.

Zusammengefasst:

Fähigkeit	Mem0 / Zep	memsearch
Quelle der Wahrheit	Vektordatenbank (einzige Datenquelle)	Markdown-Dateien (primär) + Milvus (Index)
Transparenz	Blackbox, erfordert API zur Überprüfung	Öffnen einer beliebigen .md-Datei zum Lesen
Bearbeitbarkeit	Ändern über API-Aufrufe	Direktes Bearbeiten in einem beliebigen Texteditor, automatische Neuindizierung
Versionskontrolle	Erfordert separate Protokollierung von Prüfungen	Git arbeitet nativ
Kosten der Migration	Exportieren → Format konvertieren → Re-Importieren	Kopieren des Markdown-Ordners
Mensch-KI-Zusammenarbeit	KI schreibt, Menschen beobachten	Menschen können bearbeiten, ergänzen und überprüfen

Welches Setup passt zu Ihrem Maßstab?

Szenario	Suche	Speicher	Wann man weitermachen sollte
Früher Prototyp	Grep (eingebaut)	-	Rechnungen steigen oder Abfragen werden langsamer
Einzelner Entwickler, nur Suche	index1 (Geschwindigkeit) oder QMD (Genauigkeit)	-	Mehrbenutzerzugriff erforderlich oder Daten wachsen über einen Rechner hinaus
Einzelner Entwickler, beide	index1	memsearch	Benötigt Mehrbenutzer-Zugriff oder die Daten wachsen über einen Rechner hinaus
Team oder Produktion, beides	Milvus	memsearch	-
Schnelle Integration, nur Speicher	-	Mem0 oder Zep	Notwendigkeit, Speicher zu inspizieren, zu bearbeiten oder zu migrieren

Schlussfolgerung

Die Token-Kosten, die mit ständig aktiven KI-Agenten einhergehen, sind nicht unvermeidlich. In diesem Leitfaden wurden zwei Bereiche behandelt, in denen bessere Werkzeuge die Verschwendung verringern können: Suche und Speicher.

Grep funktioniert in kleinem Maßstab, aber wenn die Codebasis wächst, überschwemmen nicht bewertete Schlüsselwortübereinstimmungen das Kontextfenster mit Inhalten, die das Modell nie gebraucht hat. index1 und QMD lösen dieses Problem auf einer einzigen Maschine, indem sie BM25-Schlüsselwortbewertung mit Vektorsuche kombinieren und nur die relevantesten Ergebnisse zurückgeben. Für Teams, Multi-Agenten-Setups oder Produktions-Workloads bietet Milvus das gleiche hybride Suchmuster auf einer horizontal skalierbaren Infrastruktur.

Für den Speicher speichern die meisten Frameworks alles in einer Vektordatenbank: undurchsichtig, schwer von Hand zu bearbeiten und an das Framework gebunden, das sie erstellt hat. memsearch verfolgt einen anderen Ansatz. Der Speicher wird in einfachen Markdown-Dateien gespeichert, die Sie lesen, bearbeiten und mit Git versionskontrollieren können. Milvus dient als abgeleiteter Index, der jederzeit aus diesen Dateien neu erstellt werden kann. Sie behalten die Kontrolle darüber, was der Agent weiß.

Sowohl memsearch als auch Milvus sind Open Source. Wir entwickeln memsearch aktiv weiter und würden uns über Feedback von jedem freuen, der es in der Produktion einsetzt. Eröffnen Sie ein Issue, reichen Sie einen PR ein, oder sagen Sie uns einfach, was funktioniert und was nicht.

In diesem Leitfaden erwähnte Projekte: