Software is normally measured in lines of code — a unit almost nobody defines the same way twice, and which no company states the definition of when they quote it. This page measures it in the unit that now decides what building it costs: language-model tokens. Then, more speculatively, it asks what an AI would spend regenerating that much text — a question the evidence can only answer to within a couple of orders of magnitude, which is itself the finding.
For 14 codebases we did it properly — cloned the source, ran tokei over every file, then tokenized every one of those files with six different tokenizers. No sampling, no extrapolation: 2.43M files, 533M lines, 30 GB of real source. Linux, Chromium, Android, LibreOffice, Blender, all of Debian 3.1. For the other 31 — Windows, Photoshop, Oracle, Google's monorepo, everything whose source you cannot get — we converted a published line count using ratios measured on those 14, and graded how much the published figure deserves to be trusted.
Then we modelled what a coding agent would spend to rebuild each one, from a flawless one-shot floor to what 2026 agents actually burn. Every dollar figure on this page is a model. No agent has been run to rebuild any of this. The largest program an AI has been measured attempting to rebuild from scratch is 250,000 lines (the Rust linter ruff, which it did not finish); the largest it finished is far smaller. Published costs exist for exactly two builds, both under 20,000 lines.
The paragraph above was true in August. Since then, large agent-built codebases have appeared, and one has published its bill: GitHub's 832K-line Rust port cost ~$120K, inside the band this page's model gives for a codebase that size.
Every codebase below sits on one axis: what a coding agent would spend to produce it, in the today's-practice scenario at Claude Fable 5 prices. Doom is 39,250 lines, measured; Google's monorepo is a reported two billion. Seven and a half orders of magnitude separate the first from the human-equivalent cost of the whole list.
The census is grouped by how each codebase’s source-token count was obtained — counted by tokenizing the real files, or estimated from a published line count. That grouping describes the input to the cost model, not the cost. Within each group a row carries its line-count range and an evidence grade for where those lines came from. The floor is real arithmetic and unreachable; the practice band rests on two published build costs, both for programs under 20,000 lines.
What is measured, and what is not. The green group is 14 codebases we downloaded and tokenized file by file, so their source-token counts are measurements. The plain group is 31 published line counts multiplied by a ratio, so their token counts are estimates. A measured token count buys you a firmer input to the cost model, not a measured cost. The two axes are also independent, which is why a row can be graded A and still be estimated: Google’s two-billion-line monorepo count is peer-reviewed, but nobody outside Google has tokenized it.
"Send the instruction, the agent writes it perfectly, pay for the output tokens once" — that bound is computable, and no real workflow has ever landed on it. Agents think, read, retry, and churn. The first multiplier below is arithmetic, the second is a decomposition, and the third is a judgment resting on four measurements — all of which the panel underneath lays out.
Final tokens × output price. Read this as a unit conversion — how much text is in the finished artifact — rather than a floor on spending. In the one benchmark that publishes the split (MirrorCode), output was 2–3% of tokens used and cost was dominated by input: 10B tokens ran about $6,000, or $0.60 per million against a $25 list output price. So the quantity priced here is a few percent of what actually gets billed.
exact arithmetic · unreachableSpec-driven bulk generation, decomposed: thinking ~1.5–3× visible output · retries + churn ~1.3–2× (only ~48% of agent runs succeed; ~7–8% of new code is revised within two weeks) · tool scaffolding ~1.2–1.5× · the input side of the loop adds ~1.5–2.5× of output cost even at 90–95% cache hits.
modeled · low–medium confidenceWhat it costs once you count thinking, reading, retries and the runs that fail. Only two whole-program builds have a published price: a 16K-line Go toolkit rebuilt for $251, and a shipped 20K-line macOS app. They imply ×42–54 and ×105 — and disagree by a factor of two at nearly the same size. A third figure exists, $2,600 for one large task, but the paper doesn't say which; the table below shows why that matters.
a judgment · two priced builds, both under 20K lines×100–400 is a choice, not a derivation. It starts above our best greenfield anchor and runs four times higher. We picked it that way on purpose: integration cost should grow with system size, and both priced builds were small enough to hold in one context window. That is a limit of the pricing, not of what has been attempted — MirrorCode has run agents at targets up to 250,000 lines; it just doesn't publish what each one cost. But the reasoning runs one direction only — the error above 20K lines points up, not both ways — so past roughly 100K lines these bands are better read as lower bounds than as central estimates. Nobody has run the experiment that would settle it: a 100K–1M-line rebuild, measured end to end. That is the result that would falsify this page, and we would rather see it than defend the band.
What this deliberately does not claimThat a 2026 agent can build Windows at any budget — or that tokens are what would stop it if it couldn't. MirrorCode's most useful result is that failure is rarely collapse: agents that miss still typically pass 90%+ of tests, and the best gotree runs passed 2000 of 2001 and still didn't count as solved. Getting most of the way to a working program is routine; closing the last few percent is where the difficulty concentrates, and it is what separates a model that finishes a target from one that doesn't. A line count doesn't tell you where that will bite — which is awkward, because a line count is the one thing this page measures. (For scale on the upper end: the largest single run they report cost $2,600 and ran 19 days unattended.) And these are costs per attempt, not per finished program. The expected cost of a successful build is roughly the attempt cost divided by the probability of success — Opus 4.7 finishes 56% of MirrorCode targets overall, about a third of them on every run, and never finished ruff at all. Where that probability is unmeasured, as it is at every size in this census, no finite dollar figure is the cost of getting the software. So read ×100–400 as a volume coefficient standing in for difficulty it cannot express, and read the dollar columns as what an agent might spend trying. A 2026-price envelope, not a quote, and not a feasibility claim.
You can almost never access a closed codebase — but you can bound it with evidence. Every figure in this census is graded by how it was obtained. This section is the playbook.
Available more often than people think: open source (clone and run tokei — we did this for Linux, Blender, Godot, LibreOffice, Chromium, GIMP, Krita, Inkscape, FreeCAD, Doom, Quake III, Doom 3, the AOSP core platform and all of Debian 3.1); source-available programs (Unreal Engine under Epic's free EULA, CryEngine, Unity's C# reference layer, Microsoft's Shared Source for qualified orgs); official historical releases (the Computer History Museum's Photoshop 1.0, MS-DOS, and Word 1.1a; id Software's GPL'd Doom, Quake, and Doom 3); and official audits (GAO's F-35 reports). We ran tokei plus exact tokenizers over fourteen codebases for this census, counting every file rather than a sample.
Companies reveal sizes in keynotes (Apple's "86 million lines" at WWDC 2006), engineering blogs (Microsoft's 3.5M-file Windows repo), conference talks (Blizzard's "5.5 million lines" at GDC 2009), and peer-reviewed papers (Google's two-billion-line CACM paper). Stated, not verifiable — and the unit "lines" is almost never defined.
Measured aggregators (Open Hub), academic distro studies (the Debian-counting series), journalism with named sources, and famous insider accounts — the anonymous Oracle engineer's "25 million lines of C": plausible, unverifiable, flagged as such.
When nothing credible exists (Maya, 3ds Max, Unity's core, GTA V, current Windows): measured comparables (Blender bounds Maya from below), dated anchors plus growth (XP's 45M in 2001 bounds Windows 11), and decomposition (engine + gameplay + tools). Modeled rows are labeled and get the widest error bars.
We downloaded fourteen real codebases (Doom, Quake III, Doom 3, Inkscape, GIMP, Krita, Blender, Godot 4.6, FreeCAD, LibreOffice, Linux 6.14, the AOSP core platform, Chromium with and without its DEPS tree, and all 8,727 source packages of Debian 3.1), ran tokei over every file, then tokenized every one of those files — no sampling — with exact o200k_base and cl100k_base encoders plus the Llama 3, Qwen3, DeepSeek-V3 and StarCoder2 tokenizers. That is 15 measurements of 14 codebases — Chromium is counted twice, with and without its vendored DEPS tree. Deduplicated, the corpus is 2.43M files, 30.2 GB and 533M lines:
A company saying "50 million lines" never says whether that counts blanks and comments — so every estimate converts twice: low = lines × tokens-per-physical-line, high = lines × tokens-per-SLOC. The 14 rows we tokenized ourselves don't need that guess: their band runs from source code only to every file in the repository, and both ends are counted, not converted. Where those two ends are far apart — Inkscape 7.3M–62.0M — the gap is the answer to "does shipping this include its translations and assets?", not uncertainty about the code.
One tokenizer, cited once, converted from. Every token figure in this census is
o200k_base, counted exactly with tiktoken over every file we
downloaded — not sampled, not estimated. Per-model figures are that count multiplied by a stated factor,
because tokenizers change between model generations and most vendors don't publish theirs.
Five of the six factors below are measured over the same 4.53B-token corpus; Claude's is not,
and is labelled accordingly.
The tokenizer table above is the small lever. Measured on the same corpus, language swings the rate 2.4× — Kotlin costs 8.02 tokens per line, JavaScript 19.35 — against 1.19× for the worst tokenizer disagreement on the page. For the 31 rows that convert a published line count, which language rate you pick matters far more than which tokenizer you count with. That is why four rows below carry an explicit language warning rather than a tighter-looking number.
COBOL, ABAP, Ada and HAL/S appear in this census and in none of this table. Those rows convert through a C-family proxy with the error unbounded in both direction and size, and they say so. Measuring them would need corpora we do not have; pretending the C rate transfers to an ABAP estate would be the exact failure this section documents.
The practical finding: on source code the big-vocabulary tokenizers are interchangeable — o200k, cl100k and Llama 3 agree within 1% — so tokenizer choice is a rounding error next to what you count. StarCoder2 is the outlier at +19% despite being code-specialised: a 49K vocabulary costs more tokens than a 200K one even on the code it was built for. Claude remains the one column resting on an assumption rather than a measurement.
Each of these propagates through listicles and infographics with no primary source behind it. They are why this census grades its evidence.
Census