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.
Honest Comparison
You already have tools. Here's the difference.
Compression tools shrink what you send on the wire. LeanCTX does that too — and decides what gets read in the first place, then guards it, remembers it and proves it. A straightforward look at what it does better, what it does the same, and when you don't need it at all.
Side by Side
Your agent, with and without.
The same agent, the same repo. The only variable is the layer between them.
| Feature | No Tool | Manual Rules | LeanCTX |
|---|---|---|---|
| Token Savings | None | Low (static rules) | 60–95% (cached: 99%) |
| Setup Effort | None | Manual per-project | One command |
| Agent Support | N/A | One agent only | 29+ agents |
| Caching | None | None | Automatic + delta |
| Shell Compression | None | None | 95+ patterns |
| Code Analysis | None | None | Tree-sitter AST |
| Maintenance | None | Manual updates | Automatic |
| Security & Governance | No enforcement | Basic file ACL | OWASP-aligned: PathJail, shell allowlist, secret redaction, OS-sandboxed code execution (ctx_execute), audit trail |
| Compliance & Evidence | Screenshots | Manual evidence gathering | Signed Evidence Bundle + offline leanctx-verify, EU AI Act / ISO 42001 / SOC 2 coverage, CGB + policy coverage |
| SDKs & Extensibility | None | Bespoke glue code | Python + TypeScript SDKs (14-check conformance), /v1 OpenAPI + capabilities, ctx_tools gateway, WASM & plugin extensions |
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. Alternatives
How LeanCTX Compares to Other Tools
A feature-by-feature comparison with RTK, Context+, MemGPT/Letta and Headroom, the most commonly referenced alternatives. Fact-based, from their public documentation.
| Feature | RTK | Context+ | MemGPT / Letta | Headroom | LeanCTX |
|---|---|---|---|---|---|
| Read Modes | Single mode | Basic filtering | N/A (memory-focused) | Compresses after the read | 10 modes (auto, map, signatures, diff, entropy...) |
| Shell Compression | No | No | No | No | 95+ patterns, auto-detected |
| Session Memory | Basic state | Conversation history | Core feature (tiered memory) | Cross-agent store with dedup | Episodic + procedural + knowledge graph |
| Multi-Agent | No | No | Limited (single agent focus) | Shared store | Handoff, shared sessions, context bus |
| Code Graph / AST | Basic indexing | No | No | No | Tree-sitter AST, 26 languages, symbol resolution |
| Governance & Budgets | No | No | No | No | Role-based budgets, SLOs, audit trail |
| Local-First / Privacy | Cloud-dependent | Local | Server-based | Python package + proxy | 100% local, zero telemetry |
| MCP Tools | Limited | No MCP | No MCP | Wraps external tools | 81 granular MCP tools |
| Security Hardening | None | None | Basic auth | None | Sandboxing, signed bundles, audit reports |
Based on publicly available documentation and source code as of June 2026. RTK (github.com/rtk-ai/rtk), Context+ (github.com/ForLoopCodes/contextplus), MemGPT/Letta (arxiv.org/abs/2310.08560), Headroom (github.com/chopratejas/headroom). All tools solve real problems. LeanCTX simply covers more layers of the context problem in one binary.
vs. compression layers
Compression shrinks what was read. Context engineering decides what gets read.
Tools like Headroom compress the request on the wire. LeanCTX already ships that layer — an optional local proxy compresses every request, prompt-cache-safe — and goes one layer deeper, at the source: it decides what gets read at all. Compatible with Headroom, but you usually don't need it on top. Here is the honest difference.
| Dimension | Compression layer (e.g. Headroom) | LeanCTX |
|---|---|---|
| Where it sits | Message path: compresses what the agent already read | At the source: decides what and how to read (10 modes, intent routing, ~13-token cached re-reads) |
| Memory | Cross-agent store with dedup | Persistent knowledge: property graph, sessions, handoffs, evidence ledger |
| Governance | — | PathJail, shell allowlist, secret redaction, budgets, injection detection |
| Proof | Stats endpoint | Ed25519-signed, hash-chained ledger + reproducible benchmark |
| Reversibility | Reference retrieval store | Also reversible: every original stays one ctx_retrieve away |
| Form | Python package + proxy | One Rust binary, 30+ tools auto-detected, zero config |
Note: some third-party comparison tables list lean-ctx as "Reversible: No"; that is incorrect. Every compressed read in LeanCTX is locally archived and retrievable via ctx_retrieve. Compression is one of five subsystems in LeanCTX. The two tools can even run together; Headroom lists lean-ctx as a compatible context tool.
Why not just…
Your stack already does some of this. Here's what it doesn't.
LeanCTX doesn't replace grep or your editor. It's the layer that decides what's worth your AI's attention.
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.
Best Fit
When lean-ctx Shines
LeanCTX delivers the most value in these scenarios.
Large Codebases
Projects with hundreds or thousands of files benefit most. The more context there is to manage, the bigger the savings.
Multi-Agent Workflows
When multiple AI agents work on the same project, LeanCTX gives them one shared brain: consistent, governed context for every agent.
Iterative Development
Long coding sessions with repeated file reads hit the cache - re-reads cost just ~13 tokens instead of thousands.
Transparency
When You Don't Need It
We believe in honest tooling. LeanCTX is designed for projects with substantial codebases - not everything.
Not Always Necessary
- Single-file scripts or small utilities
- Projects under 50 files
- One-off prompts without file context
In these cases, the overhead of a context layer isn't justified. LeanCTX shines when your projects grow and context management becomes a bottleneck.
Comparisons, answered.
Straight answers about where LeanCTX fits and what makes it different.
Manual prompt engineering requires hand-crafting every context window. LeanCTX automates this with 10 read modes, AST-aware compression, and session memory, saving 88%+ tokens with zero manual effort.
LeanCTX is a full cognitive context layer rather than a plain MCP server: CLI integration, shell hooks, 81 MCP tools, persistent memory, code intelligence graphs, and a governance layer with roles and budgets.
Yes. LeanCTX supports 30+ AI tools including Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Codex, and JetBrains IDEs. Run lean-ctx setup for automatic configuration.
Tools like Headroom compress the request on the wire — the proxy layer. LeanCTX already ships that layer: an optional local proxy (lean-ctx proxy enable) compresses every request — system prompt, history and tool results — prompt-cache-safe, metering the real dollars saved, so you usually don't need a separate request-compression proxy on top. And LeanCTX goes one layer deeper, at the source: it decides what gets read in the first place (10 read modes, ~13-token cached re-reads), remembers knowledge across sessions, guards file and shell access, and signs every saving in a verifiable ledger. Compression — read-side and wire-side — is one of its five subsystems, and it is fully reversible: every original stays one ctx_retrieve away.
Yes. Every compressed read is archived locally and the full original is retrievable on demand via ctx_retrieve. Nothing is silently lost; LeanCTX even tells your agent when to ask for the full content.
Those make your AI vendor remember your company — you tag it, follow up in a thread, and it builds up memory. But that memory lives in their black box: you can't see where it sits, move it, or swap the model under it. That's a context login, not a model login — you end up renting your own company knowledge back. LeanCTX keeps the moat on your side: sessions, a knowledge graph and portable .ctxpkg packages stay local and inspectable, model-agnostic across OpenAI, Anthropic and Gemini. Same agent-as-teammate workflow; you keep the context.
See it onyour repo.
Install in under a minute, run one session, then check the ledger. Your numbers will make the argument.