Where each arm keeps what it knows.

Resident parameters are what the arms are matched on. Disk is where TOMX puts the knowledge instead: what it serves is read from disk per query instead of from weights, which is why the left-hand number can stay flat while the right-hand one grows. Every figure below is measured when this page loads: torch parameter counts, stat on the deployed files, and RSS from the OS.

Physical 5M-world systems run

5,000,000 entities served from w5m-abstracts.

This is the scale proof, not a mechanism diagram: world size, resident model bytes, served disk, bytes opened per query, latency, fast-vs-exact agreement, and crowding curves are shown together. Artifact pin: TOMX 8e673924fd69 / bench w5-8e6739.

World

Served disk

842.0 MB

Query read

64 KiB

cache: warm-cache after one priming pass; cold-start parser and OS page-cache fill excluded
index: fast path uses the deployed approximate index; exact path scans the same candidate ledger for audit samples
accounting: symmetric: model-resident bytes, served disk bytes, and per-query read bytes are shown for every arm with zeros left visible

Arm	World size	Resident memory	Disk storage	Bytes read / query	p50 latency	Exact vs fast agreement	Condition
TOMX symmetric accounting row	5,000,000	24.64 MB	842.0 MB	64 KiB	38 ms	99.8%	warm-cache + approximate-index; exact audit checks matched rows
TX symmetric accounting row	5,000,000	25.08 MB	0.0 MB	0 KiB	31 ms	100.0%	warm-cache; no external knowledge files read by construction
RAG symmetric accounting row	5,000,000	25.08 MB	191.7 MB	256 KiB	74 ms	97.2%	warm-cache + approximate-index; exact audit reranks sampled candidates

Scaling curve · warm-cache + approximate-index

Disk grows with the world; resident bytes and bytes read per query stay nearly flat because the query opens bounded served rows.

100k / 100,000 entities 17.0 MB disk · 24.64 MB resident · 60 KiB read · 34 ms

500k / 500,000 entities 84.0 MB disk · 24.64 MB resident · 61 KiB read · 35 ms

1M / 1,000,000 entities 168.0 MB disk · 24.64 MB resident · 62 KiB read · 36 ms

5M / 5,000,000 entities 842.0 MB disk · 24.64 MB resident · 64 KiB read · 38 ms

Crowding curve · exact-versus-fast audit

More aliases mean more candidate crowding. The table keeps the approximate-index condition visible and checks it against exact audit rows.

Sparse names

46% of sampled queries

99.9% agreement

34 ms p50

Moderate ambiguity

39% of sampled queries

99.7% agreement

39 ms p50

Crowded aliases

15% of sampled queries

99.1% agreement

47 ms p50

Arm	Resident parameters	Resident MB	Knowledge on disk
TOMX knowledge on disk, read per query	6,460,208	24.64 MB	842.0 MB + 4,225.2 MB shipped but not read at serve time
TX knowledge in weights; nothing on disk to read	6,573,312	25.08 MB	0.0 MB zero by construction: this zero is the comparison the panel is making
RAG same weights as TX, plus a document index	6,573,312	25.08 MB	191.7 MB

Process memory

3,125 MB needed / 4,096 MB budget

RSS 3,556 MB, of which 431 MB is disk pages the OS has cached for this process. Cache pages are reclaimed under memory pressure; the needed figure is what has to fit in RAM.

Within the charter §3 budget: what this process needs fits the box, so the "runs on a $30/mo CPU box" line is demonstrated as measured. Growing a document loads a ~5 GB document parser on first use; that cost appears here when it is paid.

Memory is not divided between arms to make a per-arm number; the per-arm figures above and these totals are not expected to sum.

Resident basis

allocated

Torch-measured parameter and buffer bytes for each arm's modules. TOMX's count is serve-resident and excludes training-only structures. The resident number does not scale with entity count; disk does.