Entroly: Reversible Context Compression With Auditable Receipts
Cut AI context cost without trusting the compressor. Every reduction is reversible, byte-exact recoverable, and carries an auditable receipt. Local-first, works through proxy, MCP, SDK, or agent wrapper.
At a glance
- What is it?
- Entroly is a local-first Python tool that selects evidence under a token budget, emits a receipt for every selection, and lets you recover the exact original bytes. It is aimed at teams whose agent requests are large enough that context cost has become a line item, and who are unwilling to trust an opaque compressor. The design is unusual: the recovery handle, not the compression ratio, is the product.
- Who is it for?
- Adopt Entroly if your agent traffic already traverses a route you control (a proxy, an MCP server, or an SDK call) and you need to prove that a reduced request still contains the bytes the model needed. Do not adopt it if you rely on hosted subscription inference you cannot intercept, because the README is explicit that provider-bound savings exist only when the request traverses an Entroly-controlled route, and a listed integration name is not a claim of interception.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Entroly targets: unverifiable context reduction
Most context compression tools ask for trust. They drop tokens, return a shorter prompt, and give you no way to check what disappeared. If the model then gets something wrong, you cannot tell whether the cause was the compression or the model. Entroly's answer is to make every reduction reversible and every selection auditable. The README states the core promise directly: every selection emits a receipt showing what was kept, what was omitted, and the handle that recovers the exact original bytes. That is a different product category from a summarizer. A summarizer produces new text; Entroly produces a selection plus a content-addressed pointer back to the source. The audience is engineers running coding agents and long-context pipelines who have already accepted that context costs money and now want to know what they are paying for. The repository topics list agent harnesses, MCP, token optimization, and hallucination detection, which is a fair description of the intended user.
How the receipt and recovery handle actually work
The mechanism visible in the material is budgeted evidence selection plus content-addressed recovery. A request arrives with more context than the budget allows. Entroly selects which spans to keep under that budget, records the omitted spans, and issues a handle that maps back to the original bytes. The README describes this as content-addressed evidence recovery, which implies the handle resolves by content identity rather than by position, so recovery does not depend on the file still being at the same offset. The repository ships two verification artifacts referenced from the badge row: benchmarks/results/receipt_fragment_fidelity_default.json, described as 5,117 of 5,117 native source fragments independently verified, and benchmarks/results/receipt_public_integrity.json, described as 13 of 13 public SDK recovery probes exactly matching their source spans. Those are self-reported artifacts in the repository, not third-party audits, and the README links the measurement contract separately in docs/live-tokenomics.md. Read those files rather than the badges if the guarantee matters to you.
Tool-schema deferral is opt-in, not guessed
A large share of agent request tokens often comes from tool schemas, not from retrieved documents. Entroly handles this with an explicit header rather than a relevance heuristic. The README states that tool schemas are never hidden by a relevance guess, and that a caller opts in per request by sending a comma-separated active set such as X-Entroly-Active-Tools: search_files,read_file. Forced tool choices and unnamed provider tools remain available, and an invalid or non-matching set leaves the request unchanged. That last property is the interesting design decision: a malformed header degrades to no change rather than to a broken tool call. The savings from this path are tracked separately from compression savings, under entroly.proxy.tokens.tool_schema_saved and the Prometheus counter entroly_proxy_tool_schema_tokens_saved_total. Keeping the two numbers apart matters, because a team that defers schemas aggressively will otherwise misread its compression ratio.
Install paths and the commands named in the README
The install line in the README is pip install -U entroly && entroly go. That is the only end-to-end command shown in the supplied material, and it is worth noting that entroly go is not documented further here, so treat it as an entry point to discover rather than a known quantity. Beyond it, the material names several concrete surfaces. entroly value prints cumulative local totals; entroly value --json emits the same as JSON; entroly dashboard opens a local view. On the metrics side, the proxy exposes entroly.proxy.tokens.saved and entroly_proxy_tokens_saved_total, entroly.proxy.tokens.compression_saved and entroly_proxy_compression_tokens_saved_total, and the tool-schema pair above. Integration is offered through proxy, MCP, plugin, wrapper, and SDK paths, with a docs/integration-hub.md that has per-target anchors such as docs/integration-hub.md#vercel-ai-sdk. There is also an npm package, so a JavaScript-side install exists alongside the Python one. The README does not give a config file schema in the supplied text, so configuration keys beyond the header are not something I can state.
Where Entroly stops being the right tool
The README contains its own strongest limitation, and it is stated plainly: a listed integration name is not automatically a claim that hosted subscription inference is intercepted, and provider-bound savings exist only when the request traverses an Entroly-controlled route. If your developers use a hosted coding assistant over a subscription and you cannot put a proxy or MCP server in that path, Entroly has nothing to reduce. This is not a minor caveat. It is the boundary that decides whether the tool applies to you at all. A second limitation is measurement scope. The token and cost figures are local: the README says exact totals stay in each installation's local Value Receipt and that the provider invoice remains billing truth. The public counter is described as a conservative community lower bound, with each provider-bound delta rounded down to whole 1,000-token units and whole cents before upload, and no prompt, content, model, price, or exact per-request value included. That is a privacy-respecting design, but it means the headline number is explicitly not an exact worldwide total. A third consideration: the release cadence visible in the material is fast, with v1.0.81, v1.0.82, and v1.0.83 landing within roughly two weeks. Frequent patch releases in a component that sits in your request path imply an upgrade cost, even if each one is small.
Compared with a summarization middleware
The obvious alternative is a summarization or truncation layer in front of the model, of the kind Vercel AI SDK middleware or a custom prompt assembler can provide. The difference is what happens after the request. A summarizer rewrites the context into shorter text and discards the original mapping; if the model's answer looks wrong, your only recourse is to re-run with more context and compare outputs by hand. Entroly keeps the mapping and exposes it as a handle, so a wrong answer can be traced back to a specific omitted span. That is a real operational difference, and it costs something: you carry a recovery store and a receipt format, and you accept that selection under a budget is a heuristic that can still omit the one span that mattered. Entroly does not make selection correct. It makes selection inspectable. If your failure mode is cost rather than unexplained model behavior, a plain summarizer is simpler and has no recovery store to maintain.
Licence, maintenance, and what to verify before adopting
Entroly is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive choice, and it means you can vendor the selection logic if you need to. It also means nothing in the licence obliges the maintainer to keep the receipt format stable, so pin a version and read the release notes before upgrading a component that sits in your request path. The material does not describe a support commitment, a compatibility policy, or a deprecation window. The verification steps that follow from what is documented: run entroly value --json against a representative workload and reconcile the local ledger with your provider invoice, since the README states the invoice is billing truth; open benchmarks/results/receipt_fragment_fidelity_default.json and benchmarks/results/receipt_public_integrity.json and confirm the verification method matches your own recovery requirement; and test the X-Entroly-Active-Tools header with a deliberately malformed value to confirm for yourself that the request passes through unchanged, as the README claims. If your traffic never crosses an Entroly-controlled route, stop before the install line.
Editorial conclusion
Adopt Entroly if your agent traffic already traverses a route you control (a proxy, an MCP server, or an SDK call) and you need to prove that a reduced request still contains the bytes the model needed. Do not adopt it if you rely on hosted subscription inference you cannot intercept, because the README is explicit that provider-bound savings exist only when the request traverses an Entroly-controlled route, and a listed integration name is not a claim of interception. Before committing, run entroly value --json on a representative workload and check the local Value Receipt against your provider invoice, since the README states the invoice remains billing truth.
Community notes