Human Genome Project · 2003$3 billion, once
~$3 billion and thirteen years, to read a single human genome one time. Reading DNA was the whole problem.
Sequencing · 2024~$100 a genome
Ultima's UG 100 reads a 30× human genome for about $100. Reading DNA isn't the cost anymore — computing on it is, and the reference you compute against is the part that won't fit in your pocket.
Background
Sequencing cost has fallen faster than compute: a 30× human genome is now on the order of $100 [9]. The binding constraint has moved downstream to analysis, and within analysis to an unglamorous cost — moving the reference. Three observations motivate the method.
- The expensive state is read-only and shared. The reference FASTA (~3 GB) and its derived indices (BWA-MEM ~5 GB; a STAR index 27–30 GB and ~30 GB resident; GATK known-sites bundles) total 8–40 GB of immutable bytes. Standard scatter-gather workflows [6][7] fan a single run across 50–1000 genomic intervals and re-localize that identical reference to every shard, re-staging it after each spot/preemptible interruption.
- Reproducibility is a first-class requirement. Genomics grades results on reproducibility, yet re-staging "the same" reference per worker depends on mirrors and tool versions agreeing at run time. Inputs that are identical by construction are a stronger guarantee than inputs that are identical by convention.
- The kernel is increasingly model-written. When the per-shard analysis is generated by a model rather than reviewed by a person, untrusted code requires disposable isolation, and its output requires a machine-checkable control before it is trusted.
measured quantity · CpG-island densityThe kernel computes one quantity per chromosome. A CpG island is a window in which the dinucleotide CpG occurs far above its genome-wide expectation [3][4]; such islands coincide with a large fraction of human gene promoters, which makes their density a coarse but well-characterized correlate of gene density [1]. The kernel reads candidate islands off the reference sequence (29,401,360 CpG sites genome-wide); it does not measure methylation, which is cell-type-specific and absent from the reference.
Methods
In a real genomics pipeline the expensive state is read-only and shared: the reference FASTA and its derived indices. A GRCh38 FASTA is about 3 GB; a BWA-MEM index adds ~5 GB, a STAR index 27–30 GB (and wants ~30 GB of RAM resident), plus GATK known-sites bundles — 8–40 GB of immutable bytes that never change during a run. Best-practice workflows (nf-core, GATK Best Practices) scatter-gather over hundreds of intervals — a HaplotypeCaller run is routinely fanned across 50–1000 shards — and the conventional answer re-localizes that identical reference to every task — re-downloading multi-gigabyte indices per shard, and re-staging them again on every spot/preemptible interruption.
Snapshot-fork inverts it. Warm one worker — open the reference, load the indices, page them resident — then snapshot that initialized address space once. Each shard is a restore-and-fork from that snapshot — the mechanism Firecracker microVMs [5] and AWS Lambda's on-demand loading [8] already use: restore maps the saved memory MAP_PRIVATE, so the reference and index pages are shared copy-on-write and only the pages a fork actually writes diverge. The analysis never writes the index, so it stays shared. Broadcasting the reference to the (N+1)th shard costs a page-table setup, not another multi-gigabyte read — and it's byte-identical by construction, because every fork maps the same physical pages instead of doing N independent loads that merely ought to agree.
- Warm — build the base once 88.6sBoot one machine and let it do the expensive, boring part exactly once: pull all 24 GRCh38 chromosomes, build the index, load the libraries, settle the page cache. About 90 seconds of work that nothing downstream should repeat — the step before the broadcast.
- Snapshot — freeze the warm machine 962.5 MB · 10.27sFreeze the whole warmed machine — disk, caches, the loaded reference — to a 962.5 MB image in 10.27s. This frozen image is the broadcast: instead of shipping the reference to every worker, you hand each one the machine that already has it. Off-the-shelf (CRIU, Firecracker copy-on-write, Lambda SnapStart) — pointed at a genome instead of a web app.
- Fork → map — one box per chromosome 24 shards · ~60sFork one machine per chromosome (chr1…chr22, X, Y) from that one snapshot — each a copy-on-write child that starts already warm — in waves of eight. Every fork is a mapper: scan its chromosome, count CpG sites, call CpG-island candidates. Warm, the whole genome-wide fan-out finishes in ~60 s of wall-clock; cold, with each worker re-staging the reference itself, the same work is estimated at ≈13 min run serially (one measured cold chr1 shard × 24). The result is identical; the reference is paid for once, not 24 times.
- Reduce — merge into one genome → rerun ≈ fan-outCollect the per-chromosome reports into one genome-wide picture — 3,088,269,832 bp, 29,401,360 CpG sites, 264,816 island candidates — then destroy every box. First end-to-end run (warm + snapshot + fan-out): ~159 s. Every rerun after, reusing the snapshot: only the fan-out (~60 s).
MechanismA container image is a cold start: every worker pulls and re-provisions. A VM snapshot is a warm start — disk and process state captured at an instant and restored copy-on-write — so the boot and the staging are skipped and the finished state is forked instead [5][8].
Orchestration — the harness is the agentThere is no scheduler and no cluster. The control plane is a Claude Code agent: it runs crabbox.sh / the islo CLI, warms the box, snapshots it, forks one shard per chromosome in waves, collects each shard's JSON, reduces, and tears the boxes down. In this genome-wide run a Claude Code sub-agent drove the entire 24-way fan-out end-to-end and reported the receipts the figures above are built from. You run it the same way: tell the agent to do it. The controller is itself disposable; only the snapshot persists.
Results: the genomic landscape
All 24 chromosomes of GRCh38 — 3.09 Gb. Each shard computed GC content and the CpG observed/expected ratio in 1 Mb bins and counted candidate CpG islands by the Gardiner-Garden & Frommer criterion (200 bp window, GC > 50%, obs/exp > 0.6) [3].
The validation quantity is candidate CpG islands per megabase of sequenced chromosome — the raw per-shard output, sorted descending (Figure 3).
// per-shard benchmark output, before any biological interpretation.
Positive controlCpG-island density is an established correlate of gene density [1][3][4], so a correctly wired scatter-gather must reproduce that gradient. Across all 24 chromosomes the ranking comes out as expected — chr19 densest (287.6 islands per sequenced Mb; chr19 carries ~25 protein-coding genes/Mb, roughly double the genome average [2]) down to chr4 sparsest (62.4, a gene-poor chromosome). Recovering a known gradient from an independently written kernel is evidence that the sharding, the per-shard computation, and the reduce step are jointly correct: a dropped shard, a coordinate off-by-one, or double-counted bins would distort it.
This is the whole genome, not a sample of it. The ranking tracks gene density broadly, with the coarse-metric wobble you'd expect — a few mid-density chromosomes swap rank, and counts are per sequenced (non-N) megabase so gene-poor heterochromatin (chrY, the acrocentric short arms) doesn't deflate its neighbours. Recovering the gradient genome-wide is therefore consistent with a correct pipeline rather than proof of one: a positive control, not a unit test.
// CpG-island density is a coarse, one-directional proxy for gene density, not a measurement of it: many genes have no CpG-island promoter (islands undercount them), an algorithmic candidate island is a sequence-composition call rather than an annotated promoter, and this run reads islands off the reference — it never measures methylation, which is cell-type-specific and absent from the sequence.
// chrY isn't dim because it's quiet. Its right two-thirds (≈27–55 Mb) reads near-black because the reference has no letters there — heterochromatin that has never been sequenced.
Results: performance and cost
Cold fan-out stages the reference on every worker; snapshot-fork stages it once. The first run is modestly faster; the larger effect is on every subsequent run, and on the redundant transfer avoided. The control below extrapolates from the measured per-shard times (Figure 5).
Figure 5 · cold fan-out vs snapshot-fork, total machine-seconds
Measured: per-shard cold staging 32.55s (chr1) · warm fork, restore + compute ~11.2s (mean of 24) · snapshot once 10.27s. Sliders extrapolate from the measured run.
Eliminates 4 repeated warm-ups and about 150 MB of redundant reference staging.
ScopeOnce the snapshot is frozen, every rerun pays only the fan-out — about 13× faster than the serial cold estimate (that figure also includes 8-way concurrency), and 862 MB of reference transfer that never happens again. This warm base is the ~900 MB gzipped reference — still smaller than the 3 GB FASTA plus 5–30 GB resident indices a real aligner holds, so the demonstration establishes the mechanism at genome scale, not the full at-scale economics. A snapshot also restores cleanly only on a compatible CPU and kernel; copy-on-write sharing holds only for pages nothing writes; and byte-identical output additionally requires pinning clocks, RNG seeds, and scratch state.
Application: automated, model-written analysis
The method matters most when the per-shard analysis is generated and executed by software rather than written and reviewed by a person. Three properties make that case.
- Untrusted model code gets disposable isolation. A model-written pipeline is code you didn't review, running against your reference data. Each shard is a fork off a clean, known-good warmed image; it runs and is discarded. A buggy or adversarial pipeline can only corrupt its own copy-on-write pages — the shared read-only reference is never writable, so it can't be mutated across shards.
- Reference broadcast is O(1) in reference size and byte-identical. Agents drive fan-out into the thousands — parameter sweeps, per-sample and per-interval reruns, per-tool variants — where the only shared thing is the expensive 8–40 GB reference state. Copy-on-write forking makes the marginal cost of the thousandth shard a page-table setup, not a thousandth multi-gigabyte load — and every fork provably starts from the identical physical pages, not N loads that merely should agree.
- Positive controls make model output trustworthy. Model output is only trustworthy if it's reproducible and checked. Baking a known-answer control into the warm-up — here, the CpG-island/gene-density gradient — gives each fork a ground-truth check it must reproduce before its real result is trusted. Byte-identical input pages plus a positive control turn "the model ran something" into "the model ran something that passed a check."
SummaryDisposable isolation, a byte-identical broadcast with constant per-shard setup and no reference re-download, and a baked-in positive control are exactly the guarantees an automated pipeline needs: an analysis environment that is instantiated, used, checked, and discarded rather than maintained.
Reproducibility and availability
The whole genome-wide run is one harness script, crabbox.sh, driven by a Claude Code agent on the islo fabric — no scheduler, no cluster account. crabbox.sh is a local script; it uses crabbox (openclaw) when a coordinator is configured, otherwise the islo CLI directly. Re-forking the retained snapshot reproduces a per-chromosome result byte-for-byte (verified on chr21).
# the agent runs the harness end-to-end: warm → snapshot → fork(24) → reduce → teardown
./crabbox.sh run
# which is, in islo verbs:
# 1 · warm base — all 24 chromosomes + index, paid once
islo use gx-warm -- bash -lc './warmup.sh chr1 chr2 ... chr22 chrX chrY'
# 2 · broadcast — freeze the warm box to a snapshot
islo snapshot save gx-warm --name genomics-wg
# 3 · MAP — fork one warm box per chromosome (waves of 8)
for chr in chr1 ... chrY; do
islo use gx-$chr --snapshot genomics-wg -- python3 compute.py $chr &
done; wait
# 4 · REDUCE — merge per-shard JSON → genome-wide receipts, then delete the boxes
python3 scripts/reduce_wg.py ...sourceFull kernel, warm-up, orchestrator and the raw receipts behind every number on this page: github.com/zozo123/genomics-sandboxes.
Limitations and objections
"This is GC content, not medicine." Correct — and on purpose. It's a transparent, verifiable proxy that exercises the exact pattern real pipelines use (scatter by interval, gather results). Swap the kernel for DeepVariant or a methylation caller; the map-reduce-on-snapshots shape doesn't change.
"Your island calls are loose." They are candidates. The Gardiner-Garden & Frommer 1987 rule (200 bp, GC > 50%, obs/exp > 0.6) over-calls GC-rich repeats; Takai & Jones (2002) tightened it to 500 bp / GC > 55% / obs/exp > 0.65. The point here is the shape and gradient across chromosomes, which both rules agree on — not a curated annotation like ENCODE's cCRE Registry (Moore et al., Nature 2020).
"Chromosomes aren't balanced shards." True — chr1 (~250 Mb) is ~5× chr21, so the fan-out wall-clock is set by the largest shard, which is why production pipelines shard by fixed intervals instead. The snapshot/broadcast argument is orthogonal to how you cut the work; here we shard by chromosome only to make the positive control legible.
"Is forking a snapshot really reproducible?" More than re-provisioning is. Every shard restores the same captured disk state, copy-on-write — not "the same Dockerfile, fingers crossed the mirrors agree today."
"Privacy theater?" The box is ephemeral and isolated, and it's yours for its lifetime. Your genome is analyzed in a computer you control and then destroy — not deposited into a third party's permanent, sellable database.
References
- International Human Genome Sequencing Consortium (Lander ES et al.). Initial sequencing and analysis of the human genome. Nature 409:860–921, 2001.
- Grimwood J et al. The DNA sequence and biology of human chromosome 19. Nature 428:529–535, 2004.
- Gardiner-Garden M, Frommer M. CpG islands in vertebrate genomes. J Mol Biol 196:261–282, 1987.
- Takai D, Jones PA. Comprehensive analysis of CpG islands in human chromosomes 21 and 22. PNAS 99:3740–3745, 2002.
- Agache A et al. Firecracker: lightweight virtualization for serverless applications. USENIX NSDI, 2020. [link]
- Ewels PA et al. The nf-core framework for community-curated bioinformatics pipelines. Nat Biotechnol 38:276–278, 2020. [link]
- DePristo MA et al. A framework for variation discovery and genotyping using next-generation DNA sequencing data (GATK). Nat Genet 43:491–498, 2011.
- Brooker M et al. On-demand container loading in AWS Lambda. USENIX ATC, 315–328, 2023. [link]
- Ultima Genomics. UG 100 and the $100 genome (AGBT 2024; UG 100 Solaris, 2025). [link]
- CRIU — Checkpoint/Restore In Userspace. criu.org. ENCODE cCRE Registry: Moore JE et al., Nature 583:699–710, 2020.