██╗     ███████╗ █████╗ ███╗   ██╗     ██████╗████████╗██╗  ██╗
██║     ██╔════╝██╔══██╗████╗  ██║    ██╔════╝╚══██╔══╝╚██╗██╔╝
██║     █████╗  ███████║██╔██╗ ██║    ██║        ██║    ╚███╔╝
██║     ██╔══╝  ██╔══██║██║╚██╗██║    ██║        ██║    ██╔██╗
███████╗███████╗██║  ██║██║ ╚████║    ╚██████╗   ██║   ██╔╝ ██╗
╚══════╝╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝     ╚═════╝   ╚═╝   ╚═╝  ╚═╝

Files · repositories · tool results · configured providers
                          │
                          ▼
                LeanCTX Context Gateway
                Select → Control → Prove
                          │
                          ▼
                Your AI application / agent
                          │
                          ▼
                     Your model

• Select: give AI the context the task needs, with search, structural views, compression and reuse.
• Control: apply configured path permissions, content filters and context budgets to supported calls.
• Prove: inspect source references, policy decisions and usage evidence. A context-only integration records its prepared result; the host owns the subsequent model call.

For coding workflows, start with Claude Code, Cursor or Codex. The installation matrix distinguishes first-class paths from other compatibility references.

What is LeanCTX? · Where LeanCTX fits · Architecture

See it in action:

Read + Shell Map-mode reads + compressed CLI output

Gain (live) Token usage + estimated cost differences

Benchmark proof Measure compression by language + mode

_{All GIFs are generated from reproducible VHS tapes in demo/.}

• Focused input — use less of the context window for repeated reads and noisy output.
• Configured controls — bound file access and filter supported results before delivery.
• Continuity — retain local task, finding and decision records across sessions.
• Existing tools — configure a supported integration with lean-ctx setup.
• Inspectable usage — separate token estimates, provider observations and calculated costs.
• Model choice — keep your own model calls and application workflow.

Saves you tokens? Give it a star — it helps others discover LeanCTX.

Context Intelligence is how LeanCTX selects and prepares information for a task. These mechanisms support the Gateway's Select → Control → Prove flow.

For supported read and shell paths, LeanCTX can select compact representations of the files and command output your AI agent uses.

• Workload-specific token reduction on eligible context, with recovery paths and a local Shadow Mode baseline for measurement

• File reads: 16 read modes (full, map, signatures, diff, lines:N-M, density:X, …) — eligible cached re-reads return a compact reference instead of repeating content

• Target density (density:0.4): SDE-style budget compression — keeps the highest-entropy lines until ~40% of the original tokens remain, deterministic

• JIT disclosure: signatures carries line spans and points at lines:N-M for targeted expansion — outline first, bodies on demand

• Shell output: 85+ shell-output patterns compress git, npm, cargo, docker, kubectl, terraform and more (250+ passthrough rules)

• Tree-sitter AST: structural understanding for 27 languages — not just text compression

• Source recovery (CCR): supported compact views retain source or archive references for expansion through ctx_expand, ctx_retrieve or the reference API. Recovery depends on permissions, retention and the source remaining available. Read modes and detail →

Not every task or file needs the same depth. LeanCTX classifies the task, then sends the signal rather than the noise.

• 16 read modes: from full content down to AST signatures and entropy-filtered views
• Adaptive ModePredictor: learns the optimal read mode per file type from past sessions
• IntentEngine: classifies query complexity so simple lookups stay cheap

Relevant code, sessions, and connected sources become focused context instead of a larger prompt.

• Session memory (CCP): persist task/facts/decisions across chats — structured recovery queries survive compaction
• Knowledge graph: temporal facts with validity windows, episodic + procedural memory
• Property Graph: multi-edge code graph (imports, calls, exports, type_ref) powers impact analysis and search ranking
• Yours, not the vendor's: memory stays local and portable — export it as a .ctxpkg package and move it across machines or models, instead of locking it in a vendor's black box

Performance is the cost of a useful result, not just speed. LeanCTX records costs and outcomes locally; CPAO (Cost per Accepted Outcome) is the north-star metric for comparing useful AI work.

• Context Manager: browser dashboard with real-time token tracking, compression stats, utilization gauge
• Budgets & SLOs: profiles, roles, per-agent budgets, and throttling policies
• Context Proof (ctx_proof, ctx_verify): exportable audit trail (verifier, SLO, pipeline and provenance records) plus runtime-checked policy claims (PathJail per touched file, budget)

Shadow Mode estimates what the same work would have cost without LeanCTX, without changing the active workflow. The baseline is simulated from the uncompressed token counts and the same outcome signals, not a second measured run, so its reports estimate cost, tokens and CPAO deltas; they do not measure answer quality.

LeanCTX automatically tracks local cost and outcome signals; it does not add those reports to agent context. CPAO — cost per accepted outcome — is the north-star metric, while Shadow Mode provides a simulated baseline for savings estimates.

lean-ctx savings --period week                 # costs, token savings, and CPAO
lean-ctx value-report --format markdown --last 20  # recent outcome quality
lean-ctx shadow --latest                       # latest baseline comparison

# Enable shadow mode for savings comparison
lean-ctx config set shadow.enabled true

# After using LeanCTX for a while:
lean-ctx savings
lean-ctx shadow --latest

Addon manifests and gateway integration remain experimental Research interfaces. Local addon release|add|list commands handle signed packages; they do not provide a public marketplace, hosted registry, managed distribution or addon search. A package can carry a sandboxed WASM module or an [mcp] declaration for an external server.

lean-ctx addon release ./my-addon   # build a signed .ctxpkg — no artifact host, no CI
lean-ctx addon add ./my-addon-1.0.0.ctxpkg   # verify, disclose, ask, install
lean-ctx addon list                 # what's installed, what loads, what's wired

• Publish it yourself — the module travels inside the signed package, so the signature covers the executable bytes. Nothing external to host, hash or serve, and no pipeline of your own.
• Verified locally, then asked — add re-checks the signature on your machine rather than trusting its source, checks every module against its pinned SHA-256, prints the publisher key and the exact command any declared server would run, and only then prompts.
• LeanCTX never installs the server for you — no uv tool install, no npx. Fetching a declared tool stays your step, where your own package manager's trust model applies. The manifest says how to run it.
• Folded in, not just proxied — opt-in post-processing runs addon output through the same pipeline as your code: compress to a budget, spill oversized blobs to a ctx_expand handle, index into BM25 / graph / knowledge. A typed integration routes specific tools straight into ctx_expand, ctx_callgraph and ctx_knowledge.
• Untrusted by default — addon results pass through secret scrubbing and are tagged untrusted in the integration pipeline. Scrubbing covers configured detection patterns, not every possible secret.

The local workflow verifies signatures and module hashes, shows the publisher key and declared command before installation, and never installs the external server. Opt-in post-processing can send addon results through compression, ctx_expand, BM25, graph and knowledge. Results remain untrusted; configured secret scrubbing does not cover every possible secret. See the status-qualified addon guide for the boundary.

LeanCTX remains the Context Gateway for AI Systems. These research directions extend its context capabilities; they are not supported product commitments.

• Hosted context history — local snapshot create/show/verify/restore and signed file-based sharing are experimental Research; a hosted registry and model-view comparison remain future work. (concept →)
• Context as Code — declarative pipelines, profiles, and policies in TOML, versioned like infrastructure
• Unified Context Graph — code, tests, commits, CI runs, and knowledge entries in a single semantic graph
• Cross-agent context controls — explore context roles, budgets, and permissions while the host retains agent scheduling and workflow execution
• Context Observability — SLOs on context consumption, anomaly detection, OpenTelemetry / Prometheus export

The full roadmap lives in VISION.md.

LeanCTX works on two planes — what your agents read and what they send to the model:

read path:   AI tool  →  (MCP tools + shell)  →  lean-ctx  →  your repo + CLI
wire path:   AI tool  →  lean-ctx proxy        →  model provider   (supported, configured requests)

• MCP server (read path): exposes ctx_* tools (read modes, caching, deltas, search, memory, multi-agent)
• Shell hook (read path): transparently compresses common commands so the LLM sees less noise
• Request proxy (wire path, opt-in): lean-ctx proxy enable routes supported requests through a local proxy. Configured transformations can reduce eligible prompt, history and tool-result content while respecting supported provider-cache boundaries. Provider-specific effort mapping (proxy.effort), verbosity controls and volatile-prefix handling have their own compatibility limits. Recovery requires retained, authorized artifacts; usage and cost evidence depend on the provider data the path observes.
• Property Graph: multi-edge code graph powers impact analysis, related file discovery, and search ranking
• Session memory: persists selected session state for recovery when authorized records remain available
• Context Manager: browser dashboard for inspecting context activity and records visible to LeanCTX

# 1) Install (pick one)
curl -fsSL https://leanctx.com/install.sh | sh      # universal (no Rust needed)
brew tap yvgude/lean-ctx && brew install lean-ctx    # macOS / Linux
npm install -g lean-ctx-bin                          # Node.js
cargo install lean-ctx                               # Rust

# 2) One-command setup for your agent
lean-ctx wrap cursor      # or: wrap claude / wrap codex

# Inspect recorded context metrics after your AI's first lean-ctx call.
lean-ctx gain

lean-ctx wrap registers the MCP server and configures the supported local transport for that agent. Undo anytime with lean-ctx unwrap cursor.

Claude Pro/Max: subscription OAuth cannot use a custom ANTHROPIC_BASE_URL. lean-ctx wrap claude therefore adds no proxy redirect while enabling the ctx_* tools and shell-output compression; an existing custom endpoint remains untouched. Claude wire-level request compression requires ANTHROPIC_API_KEY. See advanced proxy setup.

lean-ctx onboard          # connect all detected AI tools (zero prompts)
lean-ctx setup            # interactive wizard with every option

Building from source on Windows? Clone the repo and run ./install.ps1 in PowerShell — it builds the release binary and installs it into Cargo's bin directory (pass -BuildOnly to build without installing).

LeanCTX grows with you. Below are the journeys most people actually take — each links to a complete, function-by-function walkthrough in the Reference (every CLI command and the complete MCP tools are documented there).

lean-ctx wrap cursor  # one-command setup for your agent
lean-ctx doctor       # confirm you're wired up

lean-ctx read src/server.rs -m map   # API surface, ~13 tok on re-read
lean-ctx -c "git status"             # compressed shell output

lean-ctx overview                    # task-aware project recap
lean-ctx knowledge recall "auth"     # facts that survive resets
lean-ctx knowledge consolidate       # import session + compact lifecycle
lean-ctx knowledge consolidate --all # compact every project store

lean-ctx graph impact src/auth.rs    # blast radius
lean-ctx smells scan                 # code-smell hotspots

lean-ctx provider list
lean-ctx serve --root ./api --root ./web   # multi-repo

lean-ctx doctor --fix
lean-ctx update

lean-ctx plan "refactor billing" --budget 8000
lean-ctx compile --mode balanced

ctx_agent action=register role=dev
ctx_handoff action=create        # baton-pass with full context

lean-ctx team serve --config team.toml
lean-ctx bootstrap            # zero-prompt CI setup

lean-ctx compression standard
lean-ctx harden               # enforce token discipline

lean-ctx gain --deep          # savings, cost, per-agent, heatmap
lean-ctx wrapped              # shareable recap (also: gain --svg / gain --share)
lean-ctx savings              # verified per-event ledger (auditable; savings verify)

LeanCTX provides an MCP server. Client support depends on transport, tool handling, and configuration; the matrix below records the integration scope. Two integration modes are selected for supported agents:

MCP clients need compatible transport, tool support, and configuration. The table lists setup targets; the client constraints distinguish verified integrations from generic compatibility.

Great fit if you...

• use AI coding tools daily and your sessions are shell-heavy (git/tests/builds)
• work in medium/large repos (50+ files / monorepos)
• want local context processing with inspectable network and telemetry controls

Skip it if you...

• mostly work in tiny repos and rarely call the shell from your AI tool
• always need raw/unfiltered logs (you can still use --raw, but ROI is lower)

The honest fine print: the payoff depends on three levers — reach (own the window via the proxy/engine, not just the ctx_* tool layer), context lifetime (one long-lived session vs. a fresh process per phase), and provider pricing (prompt-cache-priced vs. re-billed every turn). They stack into a clear win where they line up and net to break-even where they don't. See the win vs. break-even matrix for the full breakdown and how to tune for each case.

Try these in any repo:

lean-ctx read rust/src/server/mod.rs -m map
lean-ctx -c "git log -n 5 --oneline"
lean-ctx gain --live
lean-ctx dashboard                              # Context Manager (browser)
lean-ctx benchmark report .

• The repo ships the exact tapes used to render the GIFs in demo/
• Regenerate locally:

vhs demo/leanctx.tape
vhs demo/gain.tape
vhs demo/benchmark.tape

Measurements and estimates require a declared workload and method. The earlier per-read-mode compression table (map / signatures over 50 files) is withdrawn along with the other historical figures in BENCHMARKS.md; measure your own repository with lean-ctx benchmark report . instead. Cache references can reduce repeated context; their token cost depends on the emitted result and tokenizer.

Measure the Engine's own advertised schema, instruction, and briefing overhead with lean-ctx doctor overhead --gate. The deterministic lean-ctx benchmark dual-arm --json replay reports a synthetic upper bound: its baseline never uses the provider's prompt cache, while agent hosts can cache the prefix with or without LeanCTX. It is not a provider invoice, an on/off comparison or an outcome-quality evaluation. Available comparison methods include the lean-ctx eval ab subcommand (requires a suite file via --suite), the injected-context footprint comparison in lean-ctx eval footprint (requires a suite via --suite and a baseline via --compare), and the proxy's opt-in compression holdout ([proxy] compression_holdout).

Accuracy is gated, within stated limits. A model-free A/B gate checks that the JSON crusher keeps every gold answer in its fixtures while cutting tokens, and proxy rewrites preserve stable output for prompt-cache eligibility under the same inputs and settings. Actual cache hits, prices, and discounts depend on the provider. The off-vs-on testbench (lean-ctx eval testbench) runs pinned real repos through a raw-dump baseline and through lean-ctx at an identical token budget, grades free-form QA with an LLM judge and code with each repo's own tests, and emits FINDINGS.md (tokens / turns / walltime / quality) plus a regressions file. What CI replays is a small committed recording: it is a mechanism gate (it catches a broken pipeline or a changed grade), not evidence that compression preserves answer quality. Every eval report states its evidence tier (A mechanism … E production); a run below 30 paired tasks is UNDERPOWERED and fails --gate unless run as an explicit --mechanism check — see context-quality-v1. A powered with/without quality study has not been run yet; the proxy's compression holdout measures prompt size on real traffic and reports answer quality as unknown. What each number can and cannot show, per data path: measurement scope.

• Latest snapshot: BENCHMARKS.md
• Reproduce: lean-ctx benchmark report .

• GitHub activity and releases show the current repository counts and release history.
• Supported integration paths distinguish verified setups from protocol compatibility.
• Generated MCP registry shows the current tool count and status.
• Published metrics state their measurement scope; adoption counts do not establish savings or outcome quality.

• Reference (every function, by user journey): docs/reference/ — 11 journeys + CLI/MCP/config appendices
• For AI agents / LLMs: llms.txt — a curated, machine-readable map of lean-ctx (per the llms.txt convention)
• Getting started: https://leanctx.com/docs/getting-started
• Tools reference: https://leanctx.com/docs/tools/
• CLI reference: https://leanctx.com/docs/cli-reference/
• What is LeanCTX: https://leanctx.com/what-is-leanctx/
• Comparison (vs RTK, Context+, MemGPT): https://leanctx.com/compare/
• Community and commercial options: https://leanctx.com/pricing/
• FAQ: discord-faq.md
• Feature catalog (SSOT snapshot): LEANCTX_FEATURE_CATALOG.md
• Monorepo guide: docs/guides/monorepo.md
• Semantic code intelligence: docs/guides/semantic-intelligence.md
• Architecture: ARCHITECTURE.md
• Vision: VISION.md

• Inspectable telemetry controls: run lean-ctx telemetry status to see the effective setting and lean-ctx telemetry show to inspect the payload; lean-ctx telemetry disable turns reporting off.
• Disableable update check (config update_check_disabled = true or LEAN_CTX_NO_UPDATE_CHECK=1)
• 40+ security hardening fixes in v3.5.16 (path traversal, injection, CSPRNG, CSP, resource limits — details)
• Context Governance Benchmark self-assessment: graded C2 — Managed against the 32-control CGB v1.0-draft spec, gaps declared — docs/compliance/cgb-self-assessment.md
• Context processing runs locally; configured source providers, proxy/model requests, submitted feedback, updates, and enabled telemetry have their own network paths.

See SECURITY.md.

One command removes everything — it stops all processes, then deletes hooks, editor configs, rules, autostart (LaunchAgent/systemd), the data dir, and the binary itself:

lean-ctx uninstall                 # full clean removal
lean-ctx uninstall --dry-run       # preview every change, write nothing
lean-ctx uninstall --keep-config   # keep MCP configs + rules (for reinstall)
lean-ctx-off                       # or just disable for the current shell session

No binary on PATH (or you used the curl installer)? Run the same removal from the installer:

curl -fsSL https://leanctx.com/install.sh | sh -s -- --uninstall

If you installed via a package manager, uninstall removes everything it wrote and tells you the one command to finish removing the binary:

brew uninstall lean-ctx        # Homebrew
cargo uninstall lean-ctx       # cargo install
npm uninstall -g lean-ctx-bin  # npm

Start with CONTRIBUTING.md. Easy first PR: propose a new CLI compression pattern via the issue template.

Mixed licensing: the Trust Core remains Apache-2.0 while explicitly mapped v4 modules may use commercial source-visible terms. See LICENSE.md and LICENSE_MATRIX.toml.