Du hast bereits Tools.
Hier ist der Unterschied.
Kompressions-Tools verkleinern, was du auf der Leitung sendest. LeanCTX macht das auch — und entscheidet zusätzlich, was überhaupt erst gelesen wird, schützt es dann, merkt es sich und beweist es. Ein klarer Blick darauf, was es besser macht, was gleich, und wann du es gar nicht brauchst.
Dein Agent, mit und ohne.
Derselbe Agent, dasselbe Repo. Die einzige Variable ist der Layer dazwischen.
| Feature | Kein Tool | Manuelle Regeln | LeanCTX |
|---|---|---|---|
| Token-Einsparung | Keine | Gering (statische Regeln) | 60–95% (gecacht: 99%) |
| Setup-Aufwand | Keiner | Manuell pro Projekt | Ein Befehl |
| Agent-Support | — | Nur ein Agent | 29+ Agenten |
| Caching | Keins | Keins | Automatisch + Delta |
| Shell-Kompression | Keine | Keine | 95+ Patterns |
| Code-Analyse | Keine | Keine | Tree-sitter-AST |
| Wartung | Keine | Manuelle Updates | Automatisch |
| Sicherheit & Governance | Keine Durchsetzung | Einfache Datei-ACL | OWASP-konform: PathJail, Shell-Allowlist, Secret-Redaction, OS-sandboxed Code-Ausführung (ctx_execute), Audit-Trail |
| Compliance & Evidence | Screenshots | Manuelle Evidenz-Sammlung | Signiertes Evidence Bundle + offline leanctx-verify, Abdeckung für EU AI Act / ISO 42001 / SOC 2, CGB + Policy-Coverage |
| SDKs & Erweiterbarkeit | Keine | Maßgeschneiderter Glue-Code | Python- + TypeScript-SDKs (14-Check-Konformität), /v1 OpenAPI + Capabilities, ctx_tools-Gateway, WASM- & Plugin-Erweiterungen |
The cached figure (99%) is a repeat read served from cache at ~13 tokens; a first read never returns more tokens than the raw file, and every saving is measured net of injection (the tokens lean-ctx itself adds), so the number reconciles to your provider bill.
Wie sich LeanCTX vergleicht mit anderen Tools
Ein Feature-für-Feature-Vergleich mit RTK, Context+, MemGPT/Letta und Headroom — den am häufigsten genannten Alternativen. Faktenbasiert, aus deren öffentlicher Dokumentation.
| Feature | RTK | Context+ | MemGPT / Letta | Headroom | lean-ctx |
|---|---|---|---|---|---|
| Read-Modi | Einzelner Modus | Einfache Filterung | — (Memory-fokussiert) | Komprimiert nach dem Read | 10 Modi (auto, map, signatures, diff, entropy …) |
| Shell-Kompression | Nein | Nein | Nein | Nein | 95+ Patterns, automatisch erkannt |
| Session-Memory | Einfacher State | Konversationsverlauf | Kernfeature (gestuftes Memory) | Cross-Agent-Store mit Dedup | Episodisch + prozedural + Knowledge-Graph |
| Multi-Agent | Nein | Nein | Begrenzt (Fokus Einzelagent) | Shared Store | Handoff, Shared Sessions, Context Bus |
| Code-Graph / AST | Einfache Indexierung | Nein | Nein | Nein | Tree-sitter-AST, 26 Sprachen, Symbol-Auflösung |
| Governance & Budgets | Nein | Nein | Nein | Nein | Rollenbasierte Budgets, SLOs, Audit-Trail |
| Local-First / Privacy | Cloud-abhängig | Lokal | Serverbasiert | Python-Paket + Proxy | 100% lokal, null Telemetrie |
| MCP-Tools | Begrenzt | Kein MCP | Kein MCP | Umhüllt externe Tools | 81 granulare MCP-Tools |
| Security Hardening | None | None | Basic auth | None | Sandboxing, signed bundles, audit reports |
Basierend auf öffentlich verfügbarer Dokumentation und Quellcode (Stand Juni 2026). RTK (github.com/rtk-ai/rtk), Context+ (github.com/ForLoopCodes/contextplus), MemGPT/Letta (arxiv.org/abs/2310.08560), Headroom (github.com/chopratejas/headroom). Alle Tools lösen echte Probleme. LeanCTX deckt einfach mehr Schichten des Kontextproblems in einer Binary ab.
Kompression verkleinert, was gelesen wurde. Context Engineering entscheidet, was gelesen wird.
Tools wie Headroom komprimieren den Request auf der Leitung. LeanCTX liefert diesen Layer bereits — ein optionaler lokaler Proxy komprimiert jeden Request, prompt-cache-sicher — und geht eine Ebene tiefer, an der Quelle: Es entscheidet überhaupt, was gelesen wird. Kompatibel mit Headroom, aber meist brauchst du es nicht obendrauf. Hier ist der ehrliche Unterschied.
| Dimension | Kompressions-Layer (z. B. Headroom) | LeanCTX |
|---|---|---|
| Wo es sitzt | Message-Pfad: komprimiert, was der Agent bereits gelesen hat | An der Quelle: entscheidet, was und wie gelesen wird (10 Modi, Intent-Routing, gecachte Re-Reads für ~13 Tokens) |
| Memory | Cross-Agent-Store mit Dedup | Persistentes Wissen: Property-Graph, Sessions, Handoffs, Evidence-Ledger |
| Governance | — | PathJail, Shell-Allowlist, Secret-Redaction, Budgets, Injection-Erkennung |
| Beweis | Stats-Endpoint | Ed25519-signiertes, hash-verkettetes Ledger + reproduzierbarer Benchmark |
| Reversibilität | Referenz-Abrufspeicher | Ebenfalls reversibel: jedes Original ist nur ein ctx_retrieve entfernt |
| Form | Python-Paket + Proxy | Eine Rust-Binary, 30+ Tools automatisch erkannt, null Konfiguration |
Hinweis: Manche Vergleichstabellen von Dritten führen lean-ctx als "Reversibel: Nein"; das ist falsch. Jeder komprimierte Read wird in LeanCTX lokal archiviert und ist via ctx_retrieve abrufbar. Kompression ist eines von fünf Subsystemen in LeanCTX. Die beiden Tools können sogar zusammen laufen; Headroom führt lean-ctx als kompatibles Kontext-Tool.
Dein Stack kann davon schon einiges. Hier ist, was er nicht kann.
LeanCTX ersetzt nicht grep oder deinen Editor. Es ist der Layer, der entscheidet, was die Aufmerksamkeit deiner KI wert ist.
Warum nicht einfach grep?
grep findet Text. LeanCTX findet die richtigen Symbole, ordnet sie nach Relevanz und liefert budgetierten, strukturellen Kontext statt 500 roher Treffer, die du noch lesen und filtern musst.
Warum nicht einfach die Dateien lesen?
Ein roher Read schüttet 4.200 Tokens aus, wenn ~920 das Signal tragen. LeanCTX behält das Signal und entfernt das Rauschen, und ein gecachter Re-Read kostet etwa 13 Tokens statt erneut die ganze Datei.
Warum nicht einfach öfter komprimieren?
Kompaktierung wirft Historie weg, die du noch brauchen könntest. Mit LeanCTX gibt es nie eine Sackgasse: Jedes Original wird auf der Platte archiviert, und dein Agent ruft es auf Abruf ab. Nichts geht still verloren.
Warum nicht ein weiterer MCP-Server?
Die meisten MCP-Server fügen Tool-Definitions-Overhead hinzu und geben rohen Output zurück. LeanCTX ist ein vollständiger Cognitive Context Layer: Caching, persistentes Gedächtnis, Shell-Hooks und ein Governance-Layer, alles in einer lokalen Binary.
Wann lean-ctx glänzt
In diesen Szenarien liefert LeanCTX den größten Mehrwert.
Große Codebasen
Projekte mit Hunderten oder Tausenden Dateien profitieren am meisten. Je mehr Kontext zu verwalten ist, desto größer die Einsparung.
Multi-Agent-Workflows
Wenn mehrere KI-Agenten am selben Projekt arbeiten, gibt LeanCTX ihnen ein gemeinsames Gehirn: konsistenter, kontrollierter Kontext für jeden Agenten.
Iterative Entwicklung
Lange Coding-Sessions mit wiederholten Datei-Reads treffen den Cache — Re-Reads kosten nur ~13 Tokens statt Tausender.
Wann du es nicht brauchst
Wir glauben an ehrliche Tools. LeanCTX ist für Projekte mit substanziellen Codebasen gemacht — nicht für alles.
- Einzeldatei-Skripte oder kleine Utilities
- Projekte unter 50 Dateien
- Einmalige Prompts ohne Datei-Kontext
In diesen Fällen ist der Overhead eines Kontext-Layers nicht gerechtfertigt. LeanCTX glänzt, wenn deine Projekte wachsen und Kontext-Management zum Engpass wird.
Vergleiche, beantwortet.
Wie vergleicht sich LeanCTX mit manuellem Prompt Engineering?
Manuelles Prompt Engineering erfordert, jedes Kontextfenster von Hand zu gestalten. LeanCTX automatisiert das mit 10 Read-Modi, AST-bewusster Kompression und Session-Gedächtnis und spart 88%+ Tokens ohne manuellen Aufwand.
Ist LeanCTX besser als andere MCP-Kontext-Tools?
LeanCTX ist ein vollständiger Cognitive Context Layer statt eines reinen MCP-Servers: CLI-Integration, Shell-Hooks, 81 MCP-Tools, persistentes Gedächtnis, Code-Intelligence-Graphen und ein Governance-Layer mit Rollen und Budgets.
Funktioniert LeanCTX mit meinem KI-Coding-Tool?
Ja. LeanCTX unterstützt 30+ KI-Tools, darunter Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Codex und JetBrains-IDEs. Führ lean-ctx setup für die automatische Konfiguration aus.
Wie unterscheidet sich LeanCTX von Kompressions-Tools wie Headroom?
Tools wie Headroom komprimieren den Request auf der Leitung — den Proxy-Layer. LeanCTX liefert diesen Layer bereits: Ein optionaler lokaler Proxy (lean-ctx proxy enable) komprimiert jeden Request — System-Prompt, History und Tool-Ergebnisse — prompt-cache-sicher und misst die real gesparten Dollars, sodass du meist keinen separaten Request-Compression-Proxy obendrauf brauchst. Und LeanCTX geht eine Ebene tiefer, an der Quelle: Es entscheidet überhaupt erst, was gelesen wird (10 Read-Modi, gecachte Re-Reads für ~13 Tokens), merkt sich Wissen über Sessions hinweg, schützt Datei- und Shell-Zugriff und signiert jede Einsparung in einem verifizierbaren Ledger. Kompression — Read- und Wire-seitig — ist eines seiner fünf Subsysteme, und es ist vollständig reversibel: Jedes Original ist nur ein ctx_retrieve entfernt.
Ist die LeanCTX-Kompression reversibel?
Ja. Jeder komprimierte Read wird lokal archiviert, und das vollständige Original ist auf Abruf via ctx_retrieve abrufbar. Nichts geht still verloren; LeanCTX sagt deinem Agenten sogar, wann er den vollen Inhalt anfordern soll.
Wie unterscheidet sich LeanCTX von Vendor-Agent-Memory wie Claude in Slack oder ClickUp Brain?
Solche Tools lassen deinen KI-Anbieter dein Unternehmen merken — du taggst ihn, folgst im Thread, und er baut Gedächtnis auf. Aber dieses Gedächtnis liegt in ihrer Blackbox: Du siehst nicht, wo es sitzt, kannst es nicht mitnehmen und das Modell darunter nicht tauschen. Das ist ein Kontext-Login, kein Modell-Login — am Ende mietest du dein eigenes Unternehmenswissen zurück. LeanCTX hält den Burggraben auf deiner Seite: Sessions, ein Knowledge-Graph und portable .ctxpkg-Pakete bleiben lokal und einsehbar, modell-agnostisch über OpenAI, Anthropic und Gemini. Gleicher Agent-als-Teammitglied-Workflow; der Kontext bleibt deiner.
Sieh es auf deinem Repo.
Installiere in unter einer Minute, fahr eine Session, dann prüf das Ledger. Deine Zahlen liefern das Argument.