The Million-Token Codebase

For a decade, the working assumption behind every codebase-scale AI tool was that the model could see only a fraction of the code at once. Retrieval existed to paper over that limitation: find the few files that matter, show those, and hope the rest does not. By mid-2026, frontier models routinely accept a million tokens or more in a single window — enough to hold most production repositories, or a quarter's worth of design documents, in one prompt. The constraint that justified an entire architectural pattern has loosened.

The premature conclusion is that long context kills retrieval. It does not. What it does is move the boundary between the two, and the new boundary is less obvious than the old one. A million tokens is a large window and a small repository. It is also slow to fill, expensive to pay for repeatedly, and — past a few hundred thousand tokens — surprisingly unreliable in the middle.

This whitepaper is about where that boundary actually sits in production. It covers what genuinely changes when the whole repo fits in the window, an honest accounting of where full context beats retrieval and where retrieval still wins, the costs that vendors do not quote you, and why curating the window matters more when it is large, not less.

Our position, formed across embedded engagements building codebase-scale systems, is that the interesting architectures in mid-2026 are hybrids. Retrieval becomes a curator that assembles the right million tokens; the model reasons over the assembled context as a whole. The question is no longer "context or retrieval" but "what belongs in this particular window, and how do I pay for it."