Why not just grep?
grep finds text. LeanCTX finds the right symbols, ranks them by relevance, and returns budgeted, structural context instead of 500 raw matches you still have to read and filter.
Ehrlicher Vergleich
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.
Direkter Vergleich
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, so the number reconciles to your provider bill.
Context engineering isn't compression. It's what decides what gets read.
vs. Alternativen
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 | LeanCTX |
|---|---|---|---|---|---|
| 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.
vs. Kompressions-Layer
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.
Warum nicht einfach …
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.
Why not just read the files?
A raw read dumps 4,200 tokens when ~920 carry the signal. LeanCTX keeps the signal and drops the noise, and a cached re-read costs about 13 tokens instead of the whole file again.
Why not just compact more often?
Compaction throws away history you might still need. With LeanCTX there's never a dead end: every original is archived on disk and your agent retrieves it on demand. Nothing is silently lost.
Why not another MCP server?
Most MCP servers add tool-definition overhead and hand back raw output. LeanCTX is a full cognitive context layer: caching, persistent memory, shell hooks, and governance, all in one local binary.
Beste Eignung
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.
Transparenz
Wann du es nicht brauchst
Wir glauben an ehrliche Tools. LeanCTX ist für Projekte mit substanziellen Codebasen gemacht — nicht für alles.
Nicht immer nötig
- 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. answered.
Straight answers about where LeanCTX fits and what makes it different.
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.
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.
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.
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.
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.
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 aufdeinem Repo.
Installiere in unter einer Minute, fahr eine Session, dann prüf das Ledger. Deine Zahlen liefern das Argument.