The token saving is self-reported

Where it sits, and where it explicitly stops

The architecture diagram is the fastest way to understand the scope, and it is worth reading as a statement of limits as much as of capability:

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

The application, the agent loop and the model all stay with you; the gateway sits above them and below the data. Three verbs describe what it does. Select means giving the agent the context the task needs, using search, structural views, compression and reuse. Control means applying configured path permissions, content filters and context budgets to the calls that support them. Prove means being able to inspect source references, policy decisions and usage evidence afterwards. The scoping note is the most reassuring line in the file: a context-only integration records its prepared result and the host owns the subsequent model call. So the component does not phone anywhere on your behalf, and a context-only deployment never invokes a model.

The headline number comes from the component that benefits from it

The repository description leads with the claim, and the phrasing is worth parsing closely. It promises sixty to ninety percent fewer tokens, and it says the receipt is the token saving itself. The same description adds a count of tools, a count of supported agents, and a local-first label. The claims are not absurd for aggressive context compression, and the file does contain the beginnings of an answer. There is a dedicated benchmarks document at the repository root and a navigation entry for it, the demonstration table includes a cell for measuring compression broken down by language and by mode, and the compression section describes a local shadow mode that provides a baseline so a run can be compared against the uncompressed path. That is the right mechanism and it is more than most projects offer. The problem is that none of the headline figures cite any of it. Sixty to ninety percent is a range wide enough to cover almost any outcome, it is measured by the tool whose purpose is to produce it, and no model, hardware, corpus or task shape is attached to it anywhere in the description. Read it as a direction of travel and run the benchmark yourself before it enters a capacity plan.

Expansion depends on permissions, retention, and the source still existing

This is the caveat with the most practical consequences, and it sits inside the compression section rather than in a limitations page. Compact views retain source or archive references, and expansion back to the full content goes through one of three paths: an expand command, a retrieve command, or a reference interface. Then the condition is stated plainly. Recovery depends on permissions, on retention, and on the source remaining available. Take that seriously in an agent context. The design explicitly caches compact representations, and an eligible re-read returns a compact reference rather than repeating content. That is where the saving comes from, and it is also where correctness risk enters. If a file is edited between the first read and a later expansion, or deleted, or the retention window has passed, the agent is holding a compact view that can no longer be expanded into what the file actually says. Nothing in the file says the agent is warned when that happens. If your agent writes code against files that change under it, this is the behaviour to test rather than assume.

Sixteen read modes, and a density budget ranked by entropy

The compression mechanism is specific enough to evaluate. Sixteen read modes are offered, ranging from full content down to structural signatures and entropy-filtered views, with named examples covering a whole-file read, a structural map, signatures only, a diff, an explicit line range, and a density parameter. The density form is the interesting one. Setting it to a fraction applies what the file calls SDE-style budget compression, which keeps the highest-entropy lines until approximately that fraction of the original token count remains, and it is described as deterministic. Deterministic matters more than it might sound: it means the same file at the same density produces the same output every time, so a result is reproducible and a regression can be bisected. The design also uses progressive disclosure. Signature mode carries line spans and points at the line-range mode, so an agent gets an outline first and fetches bodies only where it needs them. Alongside files there is shell output compression, with more than eighty-five output patterns covering common developer tools and a much larger set of passthrough rules for everything unrecognised.

The development build target deletes before copying, because Apple Silicon invalidates the signature

This one is a gift, and it is commented in the build file. The fast development target builds the Rust crate, creates the target directory, copies the binary to a local bin path, and prints the version. The copy step is preceded by a removal, and the comment explains why in four lines. Overwriting an existing Mach-O file in place invalidates its ad-hoc code signature on Apple Silicon. The copied binary then dies with a kill signal on exit code 137 on every execution. Removing the file first gives the new file a fresh identity, and the target re-signs it ad hoc afterwards where the signing tool exists. So on that architecture the symptom is not a compile error or a crash in your code, it is a binary that is killed immediately every single time, with an exit code that looks like an out-of-memory kill rather than a signing problem. Anyone who has hit this will recognise it instantly. The release install path does not need the dance because the package manager handles it.

The SDK is in another repository under different terms

The audience table at the top splits three ways, and one of the splits is about licensing rather than audience. Community setup is the path for improving the context path of existing tools. Enterprise is described as licensed controls and deployment scope. And the SDK is described as stable interfaces plus separate SDK and original-equipment terms, and it links to a repository under a different organisation entirely from this one. So the engine you install from this repository is under the Apache licence, and the component you would embed in your own application is not, and lives elsewhere. That is a reasonable commercial arrangement for a project with an open core, but it is easy to miss because the SDK appears in the same table as the other two options with no licence information at all. If you are evaluating this to embed rather than to configure, that row is the one to read closely. The engine itself reaches you five ways: the Rust registry, an npm wrapper package, the Arch user repository, and shell and PowerShell installers in this repository.

A preflight target exists to mirror CI, and enterprise CI lives in the next directory

Two build targets reveal how seriously this project treats reproducibility. The first is a gate explicitly described as mirroring the continuous integration workflow, with the stated goal that green locally means green in CI for the deterministic jobs: formatting, linting, documentation, generated documentation, and a cross-platform compile check. It comes in a full form and a fast form, and the fast form is what runs before a push. Designing a local gate whose purpose is to be a faithful copy of the remote one is a discipline most projects skip, and it is the reason the release history can be as frequent as it is. The second target is for enterprise CI and it points at a directory beside this repository rather than inside it. So part of the continuous integration story is not in this repository at all. Alongside those, the root carries a machine-readable deprecation registry as a separate configuration file, and a considerable amount of editor and agent configuration: a plugin directory for one assistant, rule files for three more, an agent instructions file, a skills directory, a kits directory, and a file that describes the project to language models. There is also an archived directory tracked in the repository.

Editorial conclusion

LeanCTX suits a team running coding agents over large or noisy repositories that wants to cut context spend and, more usefully, wants an auditable record of what the agent was shown and what it was allowed to touch. Four things to check before you rely on it. Run the benchmark rather than quoting the headline figure, because the sixty to ninety percent range is measured by the component that produces it and no methodology accompanies it. Test the expansion path on files that change underneath your agent, since recovery is explicitly conditional on the source still existing and cached compact views are what make the saving. Read the SDK terms before you plan to embed, because that component is in another repository under different terms from this engine. And be aware that the local preflight gate is deliberately a mirror of CI, which is a good sign for release discipline and a reason to trust a green run more than usual.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes