We just published a technical paper on Zenodo. It describes how Blueprint — Atlarix's section-scoped structural graph — manages codebase context in multi-repository workspaces, and what a controlled benchmark actually showed when we measured it honestly. The headline finding is counterintuitive: the arm equipped with Blueprint used more total context than the arm without it. Here is why that is the correct result, and what it means for how we think about context management.

What we measured

We ran two arms of the same task on a production multi-repository workspace — 25 sections, 3,250 tracked files, target section a 99-file TypeScript codebase. Both arms used Kimi K2.6 via OpenRouter with identical deliverables: a narrative of the request flow, key file paths, and a Mermaid sequence diagram. Arm A called get_blueprint first. Arm B used only search and read_file. Provider-billed input tokens from OpenRouter logs: 63,541 (with Blueprint) vs 41,327 (without).

The counterintuitive finding

Blueprint used more total context, not less. This surprised us until we looked at the turn-by-turn growth curves. Blueprint arm: 8,661 → 13,966 → 24,771 → 25,012 → 31,717 → 54,188 → 63,541. No-Blueprint arm: 2,253 → 3,567 → 8,629 → 13,934 → 14,175 → 37,876 → 41,327. The Blueprint arm took six tool-call turns; the no-Blueprint arm took five. With a structural map of the codebase, the model was more confident about which files to read — so it read more of them. Without the map, it explored more conservatively and stopped sooner.

What Blueprint actually delivers

The Blueprint slice itself — 13 rooms, 44 edges, full section structure — was ~6,500 provider-billed tokens, parsed in ~3 seconds. That is the bounded cost of structural understanding: predictable, section-scoped, independent of how many files exist in the rest of the workspace. The no-Blueprint arm paid zero tokens for structural understanding and ~41K for the full turn. The Blueprint arm paid ~6.5K for structural understanding and ~63K for a more thorough exploration. These are separable problems.

The separability thesis

The honest framing is not 'Blueprint reduces total context.' It is that structural understanding cost and execution context are separable. Blueprint bounds the first — ~6,500 tokens regardless of section depth. Post-turn tool-result summarisation manages the second: individual read_file results compressed 95–98% before they enter long-term message history. Both mechanisms operate at different lifecycle points and solve different halves of the same problem.

Quality comparison

Both arms passed the task. Blueprint arm surfaced more internal function names — consistent with the symbol index making individual callables visible before any file was read. The no-Blueprint arm found a client module in an eval/ subdirectory not present in the Blueprint slice, and named specific environment variables and API constants the text search found directly. Different coverage strategies, comparable quality, no clear winner on correctness.

Read the full paper

The paper is published on Zenodo (CERN's open research repository) with a permanent DOI. It covers the full Blueprint architecture — the four-layer index stack, section scoping, richness-gated hybrid merge, blast radius analysis — as well as post-turn summarisation mechanics and the complete benchmark methodology including exact prescribed prompts for both arms. DOI: 10.5281/zenodo.20381860 Full paper: https://zenodo.org/records/20381860

Publishing this was a first for us. The findings are honest — we did not get the clean '12x reduction' story we originally hypothesised. What we got is more useful: a clear account of what Blueprint actually costs, what it actually delivers, and why bounding structural understanding is worth the token overhead on non-trivial codebases. If you are evaluating Atlarix for a large multi-repo project, this is the technical evidence we have.