Context Mode – MCP-Server, der den Kontextverbrauch von Claude Code um 98 % reduziert

• Löst das Problem, dass bei Aufrufen externer Tools große Mengen an Rohdaten das Kontextfenster schnell aufbrauchen
• Sitzt zwischen Claude Code und der Tool-Ausgabe, komprimiert und filtert Daten und reduziert 315 KB auf 5,4 KB (98 % Einsparung)
• Über eine Sandbox-Struktur wird jede Ausführung isoliert, und nur stdout wird in den Kontext aufgenommen, wodurch das Austreten von Rohdaten wie Logs und Snapshots verhindert wird
• Eine wissensdatenbank auf Basis von SQLite FTS5 indiziert Markdown-Inhalte und unterstützt mit BM25-Ranking und Porter-Stemming eine präzise Suche nach Codeblöcken
• Beim gleichen Limit von 200K Tokens steigt die Sitzungsdauer von 30 Minuten auf 3 Stunden, was ein effizientes Kontextmanagement für AI-Agenten ermöglicht

---

Problem

• MCP-Tool-Aufrufe in Claude Code dumpen bei jedem Aufruf Rohdaten direkt in das 200K-Kontextfenster
  • Playwright-Snapshots 56 KB, 20 GitHub-Issues 59 KB, Access-Logs 45 KB usw.
  • Nach etwa 30 Minuten Nutzung sind 40 % des gesamten Kontexts verbraucht
• MCP ist zum Standard für die Nutzung externer Tools geworden, hat aber die strukturelle Grenze, dass sowohl Eingabedefinitionen als auch Ausgabedaten den Kontext füllen
• Bei aktivierten mehr als 81 Tools sind schon vor der ersten Nachricht 72 % (143K Tokens) verbraucht

Architektur von Context Mode

• Ein MCP-Server zwischen Claude Code und der Tool-Ausgabe, der Rohdaten minimiert weitergibt
  • 315 KB Ausgabe werden auf 5,4 KB reduziert (98 % weniger)
• Jeder execute-Aufruf läuft in einem isolierten Subprozess und wird unabhängig ohne geteilten Speicher oder Zustand ausgeführt
  • Nur stdout wird in den Kontext aufgenommen; Logs, API-Antworten, Snapshots usw. bleiben innerhalb der Sandbox
• Unterstützung für 10 Sprach-Runtimes: JavaScript, TypeScript, Python, Shell, Ruby, Go, Rust, PHP, Perl, R
  • Automatische Bun-Erkennung erhöht die Ausführungsgeschwindigkeit von JS/TS um das 3- bis 5-Fache
• Authentifizierte CLIs (gh, aws, gcloud, kubectl, docker) übergeben Anmeldedaten sicher per Vererbung von Umgebungsvariablen

Wissensdatenbank (knowledge base)

• Das Tool index teilt Markdown nach Überschrifteneinheiten auf und speichert es unter Beibehaltung der Codeblöcke in einer virtuellen SQLite-FTS5-Tabelle
• Bei der Suche wird der BM25-Ranking-Algorithmus verwendet, der Relevanz auf Basis von Worthäufigkeit, inverser Dokumenthäufigkeit und Normalisierung der Dokumentlänge berechnet
• Durch Porter-Stemming werden „running“, „runs“ und „ran“ demselben Wortstamm zugeordnet
• Bei einem search-Aufruf werden keine Zusammenfassungen, sondern exakte Codeblöcke und die Überschriftenhierarchie zurückgegeben
• fetch_and_index ruft eine URL ab, wandelt HTML in Markdown um und indiziert es; die Originalseite wird nicht in den Kontext aufgenommen

Leistungswerte

• In 11 realen Szenarien (Test-Triage, Diagnose von TypeScript-Fehlern, Review von git diff usw.) blieb die Ausgabe in allen Fällen unter 1 KB
  • Playwright-Snapshot: 56 KB → 299 B
  • GitHub-Issues (20): 59 KB → 1,1 KB
  • Access-Logs (500 Einträge): 45 KB → 155 B
  • CSV-Analyse (500 Zeilen): 85 KB → 222 B
  • Git-Log (153 Commits): 11,6 KB → 107 B
  • Repository-Untersuchung (Subagent): 986 KB → 62 KB (5 Aufrufe vs. 37 Aufrufe)
• Bezogen auf die gesamte Sitzung Reduktion von 315 KB auf 5,4 KB, Sitzungsdauer 30 Minuten → 3 Stunden
• Verbleibender Kontext nach 45 Minuten: bisher 60 % → 99 %

Installation und Nutzung

• Unterstützung für automatische Routing-Hooks und Slash-Befehle über den Plugin Marketplace
• Dedizierte Installation nur für MCP ebenfalls möglich
• Nach einem Neustart von Claude Code sofort nutzbar

Praktische Änderungen

• Ohne Änderung der Nutzungsweise übernimmt der PreToolUse-Hook automatisch das Routing der Ausgabe
• Subagenten verwenden batch_execute als Standard-Tool
• Der Bash-Subagent wurde zu general-purpose aufgewertet und kann auf MCP-Tools zugreifen
• Dadurch füllt sich das Kontextfenster nicht mehr so schnell, und mit derselben Token-Menge sind längere Sitzungen möglich

Hintergrund der Entwicklung

• Beim Betrieb von MCP Directory & Hub wurde das gemeinsame Muster entdeckt, dass alle MCP-Server Rohdaten in den Kontext dumpen
• Inspiriert von Cloudflares Code Mode, der Tool-Definitionen komprimiert, wurde der Ansatz in Richtung Komprimierung von Ausgabedaten erweitert
• Nachdem bestätigt wurde, dass sich in Claude-Code-Sitzungen 6-mal länger arbeiten lässt, wurde das Projekt als Open Source unter MIT-Lizenz veröffentlicht
• GitHub: mksglu/claude-context-mode

[GN⁺]

Hacker-News-Kommentare

• Der hier vorgeschlagene FTS5-Index-Ansatz ist richtig, aber ich denke, man muss noch einen Schritt weitergehen
  Tool-Ausgaben mischen strukturierte Daten (JSON, Tabellen, Konfigurationen) und natürliche Sprache (Kommentare, Fehlermeldungen, Docstrings), daher hat reines BM25 Leistungseinbußen
  Ich habe zur Lösung eines ähnlichen Problems einen hybriden Retriever gebaut, der Model2Vec + sqlite-vec + FTS5 kombiniert. Die beiden Suchergebnisse werden mit Reciprocal Rank Fusion (RRF) zusammengeführt, sodass man gleichzeitig exaktes Keyword-Matching von BM25 und semantikbasiertes Matching der Vektorsuche erhält
  Auch inkrementelle Indizierung ist wichtig. Mein Indexer bettet mit dem Flag --incremental nur geänderte Chunks neu ein. Die vollständige Neuindizierung von 15.800 Dateien dauert 4 Minuten, tägliche Inkremente weniger als 10 Sekunden
  Auch beim Caching ist dieser Ansatz vorteilhaft. Für dieselbe Query ist die komprimierte Ausgabe deterministisch, sodass Prompt-Caching stabil funktioniert
  Was ich der Context-Mode-Architektur noch hinzufügen würde: denselben Retriever als PostToolUse-Hook auszuführen, damit die Ausgabe komprimiert wird, bevor sie in die Unterhaltung gelangt

  • Beim Ansatz des OP war das Problem, dass strukturierte Antworten unverändert erhalten blieben. Ich baue gerade ein MCP-Gateway ohne Möglichkeit zur Sandbox-Ausführung, daher wirkt diese Methode für mich sehr nützlich. Ich werde das heute ausprobieren
  • Ich würde dazu unbedingt gern einen ausführlicheren Beitrag lesen. Die sorgfältigen Notizenmacher auf HN würden das vermutlich lieben
  • Ich würde ebenfalls gern den Hintergrund und die Umsetzung dieser Obsidian-Indizierungsarbeit genauer sehen

• Hier der Autor des Beitrags. Ich habe vor ein paar Tagen das GitHub-Repository geteilt und gutes Feedback bekommen. Dieser Beitrag ist die Architekturerklärung dazu
  Die Kernidee ist, dass Context Mode statt der rohen Daten, die MCP-Tool-Aufrufe auskippen, in ein 200K-Kontextfenster zu stecken, einen isolierten Subprozess erzeugt und nur stdout in den Kontext übergibt. Rein algorithmisch ohne LLM-Aufrufe, mit SQLite FTS5 + BM25 + Porter-Stemming
  Inzwischen habe ich 228 Stars und Nutzungsdaten aus der Praxis erhalten und erkannt, wie wichtig Subagent-Routing ist. Wenn man den Bash-Subagent automatisch auf den allgemeinen Typ hochstuft und batch_execute nutzt, lässt sich der Kontext füllen, ohne ihn mit Rohausgaben zu überladen

  • Es wäre gut, im Blogbeitrag einen Link zum Cloudflare Code Mode Post hinzuzufügen. In der README ist er vorhanden, im Haupttext aber nicht
  • Sehr interessant, ich werde das selbst ausprobieren. Ich verstehe allerdings, dass Context Mode nicht direkt den MCP-Kontextverbrauch selbst behandelt; ich möchte nur bestätigen, ob das stimmt. Ich nutze MCP in mehreren Claude-Umgebungen, daher ist ein reines CLI dafür begrenzt
  • Ich frage mich, ob sich das auch mit anderen Agenten wie Zed Agent verwenden lässt
  • Ich würde gern wissen, ob es einen Grund gibt, warum Codex nicht unterstützt wird. Strukturell wirkt es agentenunabhängig
  • Ich frage mich, ob dieser Ansatz den Cache nicht kaputtmacht

• Ich verstehe nicht, warum man nicht den mcp-cli-Modus nutzt. Ich habe mit wener-mcp-cli eine geklonte Version gebaut

• Tolle Arbeit. Ich denke, beim Management des Kontextfensters gibt es noch viel Raum für Verbesserungen. Wenn ein Modell etwa erst nach mehreren Versuchen die richtige Antwort findet, wäre ein Backtracking-Ansatz nützlich, bei dem fehlgeschlagene Versuche aus dem Kontext entfernt werden

  • Sehe ich auch so. Beim Debugging entstandene Logs oder Fehlversuche sollten sich entfernen lassen, sobald der Bug behoben ist. In aktuellen IDEs ist das manuell umständlich. Es wäre gut, wenn der Agent seinen Kontext selbst verwaltet und Dinge wie Logs nach einer gewissen Anzahl automatisch aufräumt. Kontext sollte nicht als einfacher Stack betrachtet werden, sondern als frei manipulierbarer Raum
  • Fehlgeschlagene Versuche sind letztlich Rauschen. Wiederholungsmuster automatisch zu erkennen und nur die letzte erfolgreiche Version zu behalten, ist gut machbar
  • Gerade fühlt es sich wie Ende der 1990er an. Damals waren es HTML und SQL, heute sind es Coding-Agenten. Wir sind bereits erfahrene Engineers und finden bei der Nutzung von Claude Code ganz natürlich Optimierungen
  • Eine weitere Möglichkeit ist die Nutzung von Subagenten. Wenn ein Problem auftritt, forkt man einen Subagenten, lässt ihn die Lösung erarbeiten und übernimmt nur das Ergebnis. Interessant ist auch die Vorstellung, dass ein Modell seinen Speicher selbst löscht und in einen früheren Zustand zurückkehrt
  • Ich mache das tatsächlich so. Jeder Task-Aufruf läuft in einem separaten Subprozess, damit der Elternkontext nicht verunreinigt wird. Nach Abschluss werden Ergebnis, Prozesszusammenfassung, fehlgeschlagene Versuche und Erkenntnisse in vier Punkten an den Elternprozess übergeben. Tool-Ausgaben werden in Dateien gespeichert, und das LLM liest nur die nötigen Teile. Wenn es zum Beispiel mit „Success!“ endet, reicht die letzte Zeile. Im Fehlerfall wird nur die Fehlermeldung gelesen. Ich experimentiere auch damit, Logs mit einem lokalen Modell zusammenzufassen und an ein Cloud-Modell weiterzugeben. Vielleicht nicht State of the Art, aber in meiner Umgebung funktioniert es gut

• Durch diesen Beitrag wurde mir klar, dass ich über den Token-Verbrauch von Claude Code überhaupt nichts weiß, und ich habe heute Morgen ein CLI namens claude-trace gebaut
  Es parst ~/.claude/projects/*/*.jsonl und analysiert Nutzung und Kosten (inklusive Cache-Lese-/Erstellungskosten) nach Session, Tool, Projekt und Timeline
  Wenn Context Mode die Ausgabekomprimierung gut löst, dient das hier als Messschicht, um den Verbrauch vor und nach Änderungen zu visualisieren

  • Wie bei der Frage „/context?“ ist es entscheidend, sichtbar zu machen, wohin die Tokens tatsächlich fließen

• Viel Token-Verbrauch lässt sich reduzieren, wenn man statt MCP CLI-Apps nutzt. Zum Beispiel erledigt die GitHub CLI dieselben Dinge mit deutlich weniger Tokens als MCP

• Die Hooks wirken zu aggressiv. Alles an curl/wget/WebFetch zu blockieren und im Sandbox-Modus einen 56-KB-Snapshot zu erzeugen, ist zwar nett, aber in Fällen wie einfachem curl api.example.com/health, wo nur 200 Byte gebraucht werden, ist das übertrieben
  Wenn man 153 Git-Commits auf 107 Byte komprimiert, kann das Modell die Daten nur sehen, wenn es ein perfektes Extraktionsskript schreibt. Mit einem falschen Befehl gehen nötige Informationen verloren
  Das Benchmarking setzt voraus, dass das Modell immer den richtigen Zusammenfassungscode schreibt, aber in der Praxis ist das nicht so

  • Stimme zu, deshalb habe ich die Funktion entfernt

• Nicht schlecht, aber es gibt Genauigkeitsverlust und Halluzinationsrisiko. Wegen unvollständiger Daten oder fehlerhafter Extraktionslogik kann Claude falsche Schlüsse ziehen. Es wird vorausgesetzt, dass MCP klug genug ist, sowohl gute Extraktionsskripte als auch Suchqueries zu schreiben. Ich denke, Informationserhalt ist in der Praxis ein großes Problem

• Die Kompressionsrate ist beeindruckend, aber ich frage mich, ob das Modell mit komprimiertem Kontext noch dieselbe Ausgabequalität liefert. Selbst wenn eine Session von 30 Minuten auf 3 Stunden verlängert wird, ist das nur sinnvoll, wenn die Qualität der Schlussfolgerungen in der zweiten Stunde erhalten bleibt
  Auch die von esafak angesprochene Cache-Ökonomie ist wichtig. Wenn Prompt-Caching gut funktioniert, ist selbst ausschweifender Kontext faktisch kostenlos. Wenn die Komprimierung aber die Cache-Kontinuität zerstört, können die Kosten im Gegenteil steigen
  Das grundlegendere Problem ist, dass die meisten MCP-Tools per SELECT * alle Daten holen. Das ist ein Protokolldesignproblem, das Zusammenfassungen und Drill-down unterstützen müsste

  • Auch wenn der Cache kostenlos wirkt, verursacht er in Wirklichkeit Aufmerksamkeitsverlust und Verlangsamung. Selbst wenn ein langer Präfix wiederverwendet wird, bleibt der Rechenaufwand hoch

• Ich frage mich, ob man überhaupt mehr als 80 Tools im Kontext haben muss. Kontext ist Gold wert, und je mehr Unrelevantes man hineinpackt, desto schlechter werden die Ergebnisse. Statt Datenkomprimierung ist Subagent-Trennung der bessere Ansatz

  • Stimmt. Die meisten verwalten MCP-Server aber nicht direkt pro Aufgabe. Schon mit 5 bis 6 installierten Servern werden standardmäßig 80 Tools geladen. Context Mode löst also nicht das Übermaß an Tool-Definitionen. Stattdessen behandelt es die Ausgabeseite nach der Tool-Ausführung. Schon ein einzelner Playwright-Snapshot oder ein git log kann 50.000 Tokens verbrauchen, und genau das wird in die Sandbox verschoben