token‑mass

The keyhole

A real codebase doesn't fit in a context window.

• You work it through a keyhole: slices, not the whole thing.
• What it costs = how much you must load per task.
• That is not the bulk. It's the structure.

The pain is the shape

• What you must load to change a file = its closure in the dependency graph.
• Closures, coupling, cycles - graph properties, not line counts.
• Bulk is the mean. Pain is the distribution.

What hurts an LLM following the graph

• Big closure - load everything a file reaches (datacreator.ts: ~27k tokens)
• Cyclic knot (SCC) - a mutual dependency can't be loaded in pieces (the app's 5-file knot)
• God-node (high fan-in) - reloaded constantly; change = huge blast radius (insecurity.ts: 63 dependents)
• Deep chain - many hops before the code makes sense (route → service → model → config)
• Over-window core - closure bigger than the context window (none here; the monolith failure mode)
• Invisible edge (DI / reflection) - real coupling the graph can't see (the one it hides, not reveals)

Measure it for free

• Closures, SCCs, fan-in, hot core = classical graph algorithms.
• Deterministic. No LLM. No tokens.
• The LLM is reserved for two bookends: completing edges a parser can't resolve, and judging whether a flagged structure is real.

The cheapest tool for measuring the expensive resource spends none of it.

What the graph says

• lib/insecurity.ts - fan-in 63. The security primitives are a hub: a change there re-implicates 77% of the app.
• A 5-file cyclic knot (SCC) you can't keyhole apart.
• The median file is cheap; the pain concentrates in a few foundational hubs.

verdict  concentrated, with high-stakes hubs.

The honest part

• It's a re-derivation: MacCormack's propagation cost, Aider's repo-map. Not new.
• Construction is language-dependent - Joern under-resolves TS, so source-parsed imports are used.
• The verdict label is an uncalibrated heuristic - a prompt, not a measurement.

Trust the numbers. Judge the labels.