Repomix Compresses Your Repository by 70%, Which Does Not Solve the Problem
Repomix is the leader in context packing, with roughly 26,000 stars and around 255,000 npm downloads a month. It walks your repository, respects your ignore rules, and produces a single file an agent can read, using tree sitter based compression that cuts token count by about 70% while keeping signatures and structure intact.
It is a well built tool and the compression is real. We have used it, and it does what it says it does.
The thing worth thinking about carefully is what 70% means once it is applied to a number as large as a real codebase.
Run the arithmetic
At a conservative 1,000 tokens per source file, 10 million files is roughly 10 billion tokens of code.
Compress that by 70% and you are left with 3 billion tokens. A 200,000 token context window holds 0.007% of it. A 1 million token window holds 0.03%. A 10 million token window holds 0.3%.
Before compression those same figures were 0.002%, 0.01% and 0.1%. So the best context packing tool in the category moves you from three orders of magnitude short to slightly less than three orders of magnitude short. The gap is not one model generation away, and it is not two.
Compression applies a constant factor to a problem that is off by orders of magnitude, which is arithmetic rather than an engineering shortcoming, and no amount of further work on the packer changes the result.
The number nobody in this category publishes
Here is a pattern that becomes obvious once you read the primary sources rather than the marketing pages. Almost every tool in the context packing and code indexing category publishes a token reduction multiple. Almost none of them publishes a correctness figure.
That is not an accident or an oversight. Token reduction is easy to measure and easy to guarantee, because it is a property of the transformation itself. Correctness requires knowing whether the answer was right, which requires ground truth, which is expensive to build and genuinely risky to publish once you have it.
The commercial consequence matters more than the technical one. Token cost is a line item that a platform engineer optimises with a small budget and no meetings. A production incident is a board level event with a large budget attached to it. A tool that only decreases AI cost gets bought by an engineering manager, and a tool that raises the accuracy of code before it merges gets bought by a CTO, and those are entirely different procurement conversations with entirely different ceilings.
There is also a documented edge case worth knowing about. On small single file changes, structural metadata can exceed a raw file read, producing a reduction below one times. Compression is not free in every direction.
What compression discards, and why it is the important part
Tree sitter compression keeps signatures and structure while dropping bodies and detail. If the goal is fitting more of the repository into a window, that is exactly the correct thing to keep.
It is the wrong thing to keep if the goal is knowing whether a change is safe, because everything that decides safety lives in what got dropped. The flag that has been off in every environment since March. The fact that one of three implementations is live and the other two are deprecated or unshipped. The decision, taken in a review thread two years ago, not to enforce the row limit on this endpoint. The mobile client that decodes this payload strictly, so an added field fails the parse there and nowhere else.
None of that is a signature. Some of it is not even in the code, and a packer can only pack what is in the repository.
The research supports this reading directly. In the MSR 2026 dataset of agentic pull requests rejected by maintainers, only about 36% reflected a clear failure in the agent’s code, while another 31% were rejected because the contribution violated a workflow constraint or a decision the project had already taken. Roughly a third of failures are failures of intent, and no compression ratio touches them.
Reading once instead of packing repeatedly
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files, and it attacks the same cost problem from the other side.
Instead of compressing the code so more of it fits, we read it once and store the meaning. Cheap open source models read every file at indexing time and produce, for each one, what it does, why it exists in business terms, what users lose if it fails, the capabilities it provides, its edge cases, its contracts and preconditions, and the places where its behaviour is genuinely undecided. All of that goes into a graph with a specification layer on top, written in plain English, with the file and the line kept on every claim.
A query then touches a handful of pre-digested graph nodes rather than a packed dump of the repository. The window never has to hold the codebase, because the codebase was already read.
The structural difference is where the expensive work happens. Packing moves the reading cost around inside question time. The layer moves it out of question time entirely, into indexing, where it happens once on cheap models and then stops.
The numbers on our side
Indexing runs about 0.89, against roughly 0.11.
Accuracy of code holds above 93% while token spend drops by roughly 80%. Those numbers move together rather than against each other, because a model reading pre-established meaning skips the chain of inference that both costs the most and introduces the most error.
Because providers charge per token, a packing based flow becomes more expensive with every question, since every question repacks. Cost per question against a prebuilt layer stays close to flat.
Where Repomix is genuinely the right tool
If you want to hand a single small repository to a model in one shot, produce a snapshot for an offline review, or feed a codebase into something with no MCP support at all, Repomix does that better and faster than anything else, and it costs nothing. For repositories that genuinely fit in a window after compression, packing is the simpler answer and you should take it without feeling that you have settled for something.
The two are also not mutually exclusive in any meaningful way. Packing is a transport format and the layer is a knowledge store, and they solve different halves of the same difficulty.
The honest limitation
Our indexing pass is slower and more expensive than running a packer, because we are paying a model to reason about every file rather than parse and strip it. On a large estate the first run is a real cost and a real wait. What you get for it is that the reasoning never repeats, and only changed files get re-derived after that.
We also do not cover every language yet. Mojo is not indexed today.
This is what ByteBell builds
The comparison worth making is not between token reduction multiples, because that comparison is designed to be won by compression. Compare the answers instead. Ask the same hard cross repository question of a packed context and of a derived specification layer, then check which answer was right against the code. That is the number the category has been avoiding, and it is the only one that decides whether a change should merge.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, a one time pass where a model reads every file and lowers it into a verifiable code IR capturing purpose, business context and cross repository relationships, on your own infrastructure through Docker, with your source never leaving your environment. Every engineer, on any copilot, queries the same representation through a single MCP url, and every agent edit is checked against it before it lands, using per file SHA-256 diffing so only what actually changed gets examined again. Across 46 Kubernetes ecosystem repositories and 150,000 files we measured roughly 10% higher accuracy at 70% lower cost, on about a fifth of the tokens.