How it works — turning code into knowledge
BRK compiles Python source into structural knowledge and compresses it. 2.0GB of source fits in 4.75MB while keeping API signatures exact. Here is how.
What this site does
When you ask for code, this site first searches a knowledge base for API signatures verified to exist, then passes them to the model along with your question. Mistakes like calling a method that does not exist, or getting an argument name wrong, come from missing or stale knowledge. Supplying accurate information removes that class of error.
The BRK format
BRK decomposes source code into five relations
(defines / contains / inherits / calls / imports) and stores
them in a binary container. Implementation bodies, whitespace and comments
are not kept. Only what exists and how it connects.
Four compression mechanisms
- Fact graph conversion — code becomes (subject, predicate, object) triples. Implementation is already gone at this stage.
- Knowledge knapsack — the size limit is treated as an information budget. Low value-per-byte knowledge is dropped first, but public APIs are protected and survive even under a tight budget.
- Template folding — thousands of identical signatures
like
__repr__(self)collapse into one template plus a member list. - Multi-stage binary compression — string interning, varint and delta encoding, and per-section selection of the compression method by actual measurement.
Measured results
| Metric | Value |
|---|---|
| Repositories | 805 |
| Public APIs | 126,529 |
| Original source | 2.00 GB |
| Compressed | 4.75 MB |
| Ratio | 0.237% (421.6x) |
| Search latency | 15 ms |
Protecting public APIs
Raising the compression ratio alone is easy — dropping everything gives you zero bytes. The hard part is keeping what people actually need.
The first approach ranked symbols by importance (PageRank). That failed. PageRank measures how often something is called, but public API endpoints are rarely called from inside the library — they are called by users, whose code is not in the corpus. Internal helpers survived while the entry points people care about disappeared.
The current design uses a protected tier: anything public that carries a docstring is excluded from pruning entirely. Even at 91% reduction, the surface API of every major library survives.
Limitations
- Call resolution is best-effort static analysis. Dynamic dispatch and
getattrare not tracked. - Source code cannot be reconstructed from BRK — the transform is one-way.
- Python only at present.
- Code is generated by the model, not by BRK. BRK handles search and knowledge.