Instead of keeping one coding agent alive, this system keeps the software project itself alive and lets short-lived agents build a C compiler from nothing
EvoX Genesis proposes making the software project persistent, defined as an accepted version plus a repository path, while individual coding agents stay finite-lived and are repeatedly re-instantiated. Using DeepSeek V4 Flash, it built a roughly 250k-line Rust C compiler from an empty repository over 120-plus hours for only US$44 in model-token charges. It also continued a GLM 5.2-built compiler after swapping agents and models, and reimplemented 13 MESA stellar-astrophysics modules from Fortran into a faster Rust workspace while preserving their numerical results.
METAL MEDIA explanatory visual
How a persistent recursive world operates
Evidence statusMeasured results reported
accepted version v + path pA local software world combining the accepted project state and history (v) with where an agent starts and what it's responsible for (p)
finite-lived agentAn agent that receives one objective, proposes a candidate change, and terminates without carrying private state to the next agent
recursive delegationA parent agent spawns a child at a different path within the same accepted version, moving work around without changing the project history
validation gateThe parent agent uses tests, constraints, and integration evidence to accept, reject, or request further work on a returned change
accumulated project historyOnly accepted changes advance the version history, which becomes the sole inheritance for the next round of finite-lived agents
An explanatory diagram made by METAL MEDIA, not a figure supplied by the paper's authors.
What they did
Motivation: software systems live far longer than any single coding agent's session, but existing continuity tricks (longer context, persistent memory, manager agents) all extend the agent side rather than the project side.
Method: Genesis defines a local software world as an accepted version v plus a repository path p; a finite-lived agent enters, proposes a change, and a parent agent accepts, rejects, or requests rework based on tests and integration evidence. Recursive delegation moves work to new paths without changing the accepted version, and only accepted changes advance the project's history.
Formation result: starting from a repository with no compiler code, DeepSeek V4 Flash ran for 123.4 hours across 1,019 archived agent episodes to produce a 248,989-line Rust compiler (jcc), costing US$44.38 in model-token charges.
Continuation result: two branches resumed the same completed GLM 5.2 compiler, one staying on GLM 5.2 and one switching to DeepSeek V4 Flash; both kept developing after repeated agent turnover and a model swap.
Redevelopment result: 13 MESA modules (about 139,414 Fortran lines) were reimplemented by DeepSeek V4 Flash into a Rust workspace (about 89,946 lines); across six numerical workloads Rust was faster in every case (1.55x-6.87x) while numerical results stayed essentially unchanged.
Figure 1: Persistent recursive worlds. a, An accepted software version can be viewed from different repository-relative paths, defining local worlds w=(v,p). The version v fixes the accepted project state and history, while the path p sets where an agent starts and what it is responsible for. Recursive delegation (v,p)↝(v,q) starts a child agent at path q without changing the accepted version v. b, A finite-lived agent receives a local objective and proposes a change. The responsible parent accepts, rejects or requests more work using tests, constraints and integration evidence. The isolated worktree is an execution workspace created from the accepted version; it is not a second software world or a partial repository in the formal model. c, Only an accepted change creates a software event (v,p)→(v′,p′) and advances the accepted version history. A rejected candidate leaves the accepted version unchanged, and the agent’s private execution state ends with the episode.
Table S1: Repository commits used in the three experiments.
Repository
Version
Commit ID (SHA-1)
jcc
DeepSeek generated jcc
a8c116ec7ed3d59479ad3be8fed3e63384f50a87
jcc
GLM generated jcc
37216cfa254a40e40af48cd528743fd7f2d6737c
jcc
GLM generated jcc continued with DeepSeek
10077f65686102deef2c228e8a49b0569218ec48
jcc
GLM generated jcc continued with GLM
ab58a91460adb24e9349a554e02d4522d3ae2db4
mesa-rs
DeepSeek ported mesa
2ad071e658f8d4de21aa9f0e906592c364e10023
Figure 2: Formation of a C compiler with DeepSeek V4 Flash through recursive development. a, Growth of the jcc codebase and cumulative input-token use against elapsed time; the phase boundary separates initialization from optimization. b, Final validation across LLVM, c-testsuite, Csmith, LZ4, SQLite, Rust workspace tests and the internal compiler corpus. c, Active agents and completed episodes throughout development, with episodes distinguished by whether their contributions were retained in the final accepted repository history. d, Agent time partitioned among front-end, intermediate-representation and optimization, back-end, integration and validation, and cross-cutting work during the two phases. Dollar annotations denote model-token charges only, not total compute, infrastructure or labour cost.
Table S2: Compiler archive and integration counts.
Quantity
Value
Raw archived records
1,019
Top-level agent_count field
1,065
Direct missing-parent records
4
Excluded descendants
0
Records in reconstructed tree
1,015
Initialization records
312
Optimization records
703
Retained
929
No change
78
Not integrated
5
Git object unavailable
3
First-parent commits
327
Maximum observed delegation depth
5
Peak active episodes
29
Figure 3: Continuation of the same compiler world with GLM 5.2 and DeepSeek V4 Flash. a, Codebase growth and cumulative token use across initial GLM 5.2 development and the two continuations from the same completed GLM jcc world. b, Compiler validation and project growth for the three recorded snapshots. The retained LLVM SingleSource test sets differ among snapshots, so the fractions are reported within each snapshot rather than compared on one fixed test set. c, Concurrent agent activity across initial development and both continuation runs. d, Lines added and deleted during each continuation relative to the shared starting codebase. e, Cached and fresh input-token fractions and corresponding recorded or reconstructed model-token costs. The costs were obtained differently for the two continuation runs, and the runs did not use matched resources, so no normalized dollar-efficiency comparison is made.
Table S3: Compiler-formation resource use.
Metric
Observed value
Elapsed wall time
123.402 h
Raw agent-hours
666.385 h
Median episode duration
12.76 min
Input tokens
4,134,593,954
Cached input tokens
4,026,336,896
Uncached input tokens
108,257,058
Cached input/input
97.382%
Output tokens
64,092,688
Total tokens
4,198,686,642
Logged cost
US$44.3760
Figure 4: Redevelopment of selected MESA modules in Rust. a, Repository growth and cumulative input-token use during the MESA-to-Rust migration. The plotted repository line count is the size of the generated repository, not the number of MESA source lines migrated. b, Mean prompt-cache hit rates for agent groups defined by total token use. c, Dependencies among the mapped modules, classified as present in both dependency graphs, absent as direct Rust crate dependencies, or newly present in Rust. d, Numerical agreement and median runtime for corresponding Fortran and Rust implementations across six audited workloads.
Table S4: Compiler-formation resource use by phase.
Phase
Records
Wall time (h)
Agent-hours
Total tokens
Cost (US$)
Initialization
312
23.905
163.925
1,052,907,912
13.5715
Optimization
707
99.497
502.460
3,145,778,730
30.8045
Total
1,019
123.402
666.385
4,198,686,642
44.3760
Supplementary Fig. S5: DeepSeek compiler-development tree. The radial tree shows the two root sessions and all 1,015 records used in the reconstructed parent–child tree after four records with missing parents were excluded. Radial distance shows delegation depth. Blue and coral show initialization and optimization; shade shows completion order within each phase. Symbols mark retained, no-change, not-integrated and Git-object-unavailable outcomes.
Table S5: Final compiler repository lines by tracked text-file type.
File type
Files
Physical lines
Share
Rust
354
219,676
88.23%
Markdown
77
17,005
6.83%
C source
130
5,036
2.02%
Python
14
3,265
1.31%
C header
49
3,163
1.27%
Expected output
106
271
0.11%
Shell
3
195
0.08%
Cargo.toml
9
132
0.05%
Makefile
1
101
0.04%
Cargo.lock
1
66
0.03%
TOML
2
42
0.02%
YAML
1
25
0.01%
.gitignore
2
10
0.00%
Info
1
2
0.00%
Total
750
248,989
100.00%
Supplementary Fig. S6: Final DeepSeek compiler repository. The final tracked repository contains 248,989 physical lines in 750 text files, including 219,676 Rust lines in 354 .rs files. a, Lines grouped by functional category. b, Line and file counts by tracked file type on a logarithmic scale. Counts include comments and blank lines and describe the whole repository, not compiler implementation alone.
Table S6: Final compiler test results and limits.
Test
Measure
Result
Rate
Notes
LLVM test suite
Passing cases
32/36
88.9%
Four reported cases did not pass
c-testsuite
Passing tests
220/220
100.0%
Complete reported c-testsuite set
Csmith
Executed random programs
93/93
100.0%
Seven of 100 seeds skipped; zero executed failures
LZ4
Essential checks
8/8
100.0%
All reported essential checks passed
SQLite
Test stages
2/2
100.0%
Compile/link and deterministic SQL checks; not the upstream suite
Rust unit tests
Workspace count
2,904 passed
—
One intentional ignore; no fixed external denominator
Internal corpus
Compiler cases
106/106
100.0%
86 compile-run and 20 compile-fail cases
Supplementary Fig. S7: Delegation trees for compiler continuation. The upper tree shows the 504 archived records from initial GLM development, including two root segments and depth to d5; agent roles were not recorded for this stage. The lower trees show the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash continuation records. Distance from the centre shows delegation depth, node shape shows the recorded role where available and colour shade shows completion order.
Table S7: Compiler task and run settings.
Item
Setting
Run setup
Genesis; two sequential root sessions; per-agent Git worktrees
.gitignore and genesis.toml; no compiler implementation
Root-task inputs
Phase-I compiler blueprint; Phase-II continuation with handoff summary
Turn limits
2,048 root turns; 128 turns per non-root episode
Delegation and retry limits
Maximum depth 8; maximum retries 15
External test sources
c-testsuite, LLVM test suite, LZ4 and SQLite
Generated-program tests
Csmith through the committed harness
Rust toolchain
Rust stable; edition 2024; minimum Rust version 1.85; rustfmt and clippy
Compiler target
C11 primary and C23 stretch; x86 and x86-64 mandatory; AArch64 optional
Supplementary Fig. S8: Agent roles and delegation depth in compiler continuation. a, Role counts for the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash records; roles were not recorded for initial development. b, Delegation-depth counts for initial development and both continuations. These counts describe archived records, not all spawned agents.
Table S8: Machine and software environment for the compiler experiments.
Item
Recorded value
CPU
AMD Ryzen 7 PRO 6850HS with Radeon Graphics
CPU layout
x86-64; one socket; 8 physical cores; 2 threads per core; 16 online logical CPUs
Memory
64 GB
CPU frequency
403.7300–4787.0820 MHz; frequency boost enabled
Cache
256 KiB L1d, 256 KiB L1i, 4 MiB L2 and 16 MiB L3 in aggregate
NUMA
One node containing CPUs 0–15
Container and host
ArchLinux container; NixOS-built Linux 6.18.39 host kernel
Supplementary Fig. S9: Physical line counts during compiler continuation. Tracked Rust, Cargo.toml, Markdown and shell lines are shown for the initial GLM compiler and the two continuation results. The horizontal axis is logarithmic so that small project-control files remain visible. Counts include blank lines.
Table S9: Compiler-continuation starting points and run settings.
Setting
Initial development
GLM continuation
DeepSeek continuation
Model path
New project → GLM 5.2
GLM compiler → GLM 5.2
Same GLM compiler → DeepSeek V4 Flash
Starting state
Empty tracked project
Completed compiler at 37216cfa254a
Same completed compiler at 37216cfa254a
Task
Build new compiler
Continue existing compiler
Continue existing compiler
Root role
Not recorded
Manager
Manager
Depth and retry limits
8; 15
8; 15
8; 15
Turn limits
2,048 root; 128 delegated
2,048 root; 128 delegated
2,048 root; 128 delegated
Compression threshold
150,000 tokens
150,000 tokens
150,000 tokens
Test families
Rust, LLVM, c-testsuite, LZ4, SQLite
Same families
Same families
Csmith
Requested; unavailable
Excluded
Excluded
Runs
1
1
1
Shared fixed budget
Not specified
Not specified
Not specified
Supplementary Fig. S10: Module-level source line counts for MESA and Rust. For each of the 13 mapped modules, physical Fortran lines in the module directory, including local test programs, are compared with Rust library lines and Rust library-plus-crate-test lines. The logarithmic axis shows both larger and smaller ports. Counts include comments and blank lines and do not imply feature equivalence.
Table S10: Run summary for compiler continuation.
Metric
Initial GLM
GLM continuation
DeepSeek continuation
Elapsed time (h)
136.56
21.99
17.10
Spawned Agents
562
98
178
Archived records
504
97
168
Archive coverage
89.7%
99.0%
94.4%
First-parent commits
619
88
31
Maximum observed depth
5
4
8
Peak active Agents
21
9
19
Mean active Agents
2.86
2.94
5.70
Summed Agent-hours
390.57
64.65
97.57
Median duration (min)
14.4
16.1
17.0
90th-percentile duration (min)
83.2
59.8
70.2
Code-changing records
479
90
160
No-change records
25
7
8
Supplementary Fig. S11: Accepted Rust source changes over time. First-parent Git activity is shown for the 13 migrated crates during the 33.22-h run. Colour intensity represents log(1+added+deleted) lines. The dashed line marks the root-level handoff at 31.72 h. Blank intervals mean that no first-parent source change was accepted at the plotted resolution; analysis or testing may still have been active.
Table S11: Archive coverage for compiler continuation.
Stage
Spawned
Archived
Coverage
Missing-parent issue
Initial development
562
504
89.7%
Six absent parent IDs referenced by 15 records
GLM continuation
98
97
99.0%
Two records reference absent parent 562
DeepSeek continuation
178
168
94.4%
No missing-parent reference among archived records
Supplementary Fig. S12: Concurrent agent episodes during migration. Active archived episodes are reconstructed at one-minute resolution and stacked by recorded role. The maximum overlap was 22 episodes. The plot uses archived start and finish times and does not show CPU use.
Table S12: Token use and cost in compiler continuation.
Metric
Initial GLM
GLM continuation
DeepSeek continuation
Input tokens
2,245,871,926
543,563,883
902,775,744
Cached input tokens
2,163,779,584
534,150,656
884,375,552
Fresh input tokens
82,092,342
9,413,227
18,400,192
Cached input/input
96.34%
98.27%
97.96%
Output tokens
19,334,886
3,702,697
8,704,733
Total tokens
2,265,206,812
547,266,580
911,480,477
Input cost (US$)
677.511916
152.057688
5.052314
Output cost (US$)
85.073659
16.291867
2.437395
Total cost (US$)
762.585575
168.349555
7.489709
Table S13: Tests reported at the end of compiler continuation.
Test target
Initial development
GLM continuation
DeepSeek continuation
Rust unit tests
1,136
1,226 (+90)
1,350 (+214)
LLVM SingleSource
1,558/1,870 (83.3%)
1,445/1,448 (99.79%)
1,820/1,820 (100%)
c-testsuite
220/220
220/220
220/220
LZ4
4/4 files
4/4 files
4/4 files
SQLite at -O0
Basic run passed
Compiled
Compiled, linked and ran
Csmith
Unavailable
Excluded
Excluded
Table S14: Physical line counts for the compiler-continuation snapshots.
Table S16: MESA-to-Rust resource use and archive coverage.
Quantity
Recorded value
Experiment interval
3–5 August 2026 (UTC)
Elapsed wall time
33.219 h
Root-agent handoff
31.720 h
Spawned agents
272
Archived agent records
260
Archive coverage
95.6%
Input tokens
771,755,551
Cached input tokens
744,102,016
Cached input share
96.4168%
Output tokens
16,721,326
Total tokens
788,476,877
Recorded model-token cost
US$10.636892
Table S17: Module-level source line counts for MESA and mesa-rs.
Layer
Module
Fortran LOC
Rust lib
Rust tests
Rust total
Fortran/Rust
Foundation
const
308
836
90
926
0.33
Foundation
utils
3,569
1,384
370
1,754
2.03
Foundation
math
1,020
1,474
807
2,281
0.45
Foundation
mtx
5,206
8,244
1,728
9,972
0.52
Foundation
interp_1d
5,851
2,002
937
2,939
1.99
Foundation
interp_2d
16,176
5,592
1,300
6,892
2.35
Foundation
num
18,357
10,225
3,078
13,303
1.38
Physics
chem
4,424
3,753
900
4,653
0.95
Physics
rates
18,547
12,304
4,975
17,279
1.07
Physics
neu
2,263
2,222
995
3,217
0.70
Physics
net
17,799
16,332
2,429
18,761
0.95
Physics
eos
25,817
1,426
1,514
2,940
8.78
Physics
kap
20,077
1,579
832
2,411
8.33
All
Total
139,414
67,373
19,955
87,328
1.60
Table S18: Numerical agreement and runtime performance for six migrated workloads.
Workload
Fortran (s)
Rust (s)
Speedup
Checksum difference
End-to-end burn
0.446
0.287
1.55×
3.1×10−9
EOS lookup
1.786
1.115
1.60×
Bit-exact
Opacity lookup
0.532
0.269
1.98×
1.3×10−13
2D interpolation
0.159
0.101
1.58×
4.9×10−12
ROS2 integration
0.722
0.136
5.30×
5.1×10−15
Newton solve
0.084
0.012
6.87×
Bit-exact
Table S19: Separate 40-run timing check for the burn proxy.
Statistic
Fortran (s)
Rust (s)
Fortran/Rust
Minimum
0.2897
0.2372
1.22×
P10
0.2922
0.2385
1.22×
P25
0.2927
0.2392
1.22×
Median
0.2996
0.2427
1.23×
Mean
0.3447
0.2735
1.26×
P75
0.4416
0.3609
1.22×
P90
0.4458
0.3729
1.20×
Maximum
0.4490
0.3815
1.18×
Table S20: Mapped dependency counts for MESA and mesa-rs.
Category
Edges
Interpretation
MESA
142
Provider-to-dependent edges parsed from INTERNAL_DEPENDS_ON
mesa-rs
41
Mapped crate dependencies parsed from Cargo.toml
Retained
40
Edges present in both mapped graphs
MESA-only
102
No matching direct Rust crate dependency in the mapped graph
Rust-only
1
Dependency introduced in mesa-rs
Table S21: What each experiment supports and what remains unresolved.
Experiment
What else could explain the result
Evidence in this study
What the result supports
Compiler formation
The task specification and model knowledge may explain part of the resulting organization
Repository with no compiler implementation, a 1,015-record reconstructed parent–child tree, repository counts and seven test families
One observed run formed and broadly tested a working compiler; no repeated mechanism test
Compiler continuation
Model differences, unequal resource use or the source code alone may explain the observed continuation
Same saved GLM starting world and instruction, but one run per path, different resource use, different LLVM case lists and no code-only or fresh-agent control
The same completed compiler was continued with GLM 5.2 and DeepSeek V4 Flash
MESA migration
Limited module and workload coverage and the timing setup may explain part of the result
Thirteen mapped module directories, 13 Rust crates, six 25-run workload summaries and a separate 40-run burn-proxy summary
Numerical agreement on the tested workloads and lower measured runtimes under the reported setup
Table S22: Observed failures, missing records and how they are handled.
Experiment
Observed issue
How it is handled
Compiler formation
Four direct missing-parent records; four of 36 reported LLVM cases did not pass; seven of 100 Csmith seeds were skipped
Rows with missing parents are excluded only from the parent–child tree; non-passing and skipped test cases remain in the reported denominators
Compiler continuation
GLM 5.2 passed 1,445/1,448 on its retained LLVM manifest
The exact count is reported. No cause is claimed for the three non-passing cases because per-case diagnostics are unavailable
Continuation archives
Archive coverage is 89.7% for initial GLM development, 99.0% for GLM continuation and 94.4% for DeepSeek continuation
Parent–child, role, depth and concurrency summaries use only the archived records available for each stage
MESA numerical checks
Four of six tested workloads have small non-zero checksum differences; the module and workload coverage is incomplete
The numerical differences and coverage limits are reported directly; no claim of complete MESA equivalence is made
MESA timing checks
One noisy interleaved end-to-end timing run favoured Fortran (0.82× Rust/Fortran speed ratio), whereas the dedicated 40-run summary favoured Rust at 1.23× median
Both observations are reported; runtime claims are limited to the reported host and timing setup and are not generalized to Rust versus Fortran
MESA line counts
Independent workspace counting paths differ by one physical Rust line (89,946 versus 89,945)
The discrepancy is reported and is not used in the main comparison; the mapped 13-crate total of 87,328 lines is the comparison value
Findings
Compiler formation: 123.4 hours, 1,019 archived agent episodes, a 248,989-line repository, US$44.38 in model-token charges; the compiler passed 220/220 c-testsuite cases, 32/36 evaluated LLVM cases, 93/93 Csmith programs, and 2,904 Rust workspace tests.
Compiler continuation: on the same completed GLM 5.2 compiler world, the GLM 5.2 branch passed 1,445/1,448 cases on its own retained LLVM test set while the DeepSeek V4 Flash branch passed 1,820/1,820 on its own set; the two test sets differ, so this is not a direct head-to-head comparison.
MESA redevelopment: 33.22 hours, 272 agents, a 89,946-line Rust workspace passing 1,052 tests (no failures, 18 ignored), US$10.64 in model-token charges.
Across six numerical workloads, EOS lookup and Newton solve were bit-exact, the other four workloads showed tiny relative checksum differences (5.1x10^-15 to 3.1x10^-9), and Rust was faster in all six (1.55x-6.87x).
A separate 40-run burn-workload check gave a median of 0.2996s for Fortran versus 0.2427s for Rust (1.23x), with both implementations reporting identical integrator step counts.
Where it can be used
Organizing long-running, multi-contributor software projects where continuity needs to survive changes in personnel, tooling, or the underlying AI model.
Migrating legacy scientific software (e.g., Fortran) to another language while trying to preserve previously validated numerical behavior.
Situations where teams want to avoid lock-in to one foundation model by allowing development to continue smoothly after a model swap.
Limits and open work
Each experiment was run once (one compiler-formation run, two continuation branches, one MESA run), so success rates or reproducibility across repeated runs are not established.
The two continuation branches (GLM 5.2 vs DeepSeek V4 Flash) used different retained test sets and unmatched resource budgets, so their results cannot be read as a controlled model comparison.
The MESA redevelopment covers only 13 core numerical and physics modules and explicitly excludes higher-level engines like star, astero, and binary, plus the full EOS blend and REACLIB dataset.
Fortran and Rust timers differ (system_clock/cpu_time vs Instant) and timings were sensitive to host load, so the reported speedups are specific to this build, host, and benchmark setup rather than a general Rust-vs-Fortran claim.
The paper does not yet run causal experiments isolating whether recursive delegation or persistent non-code records are actually necessary for the observed continuity, such as holding code fixed while varying only stored context.
Why it matters
This shows a genuinely different way to organize long-horizon AI-assisted software development: instead of trying to keep one agent alive longer, keep the project's accepted state alive and treat agents as disposable. For teams maintaining large codebases or migrating legacy scientific software, it suggests a design axis where swapping agents or even swapping the underlying model does not have to stop ongoing development.
Terms in this paper
EvoX Genesis · The system introduced in the paper, which represents software as a persistent recursive world so agents can stay short-lived while development continues
persistent recursive world · A local workspace defined by an accepted software version plus a repository path; the version persists while new agents are repeatedly instantiated at paths
recursive delegation · A parent agent spawning a child agent at a different path within the same accepted version; it moves work around without itself changing the project's history
MESA · Modules for Experiments in Stellar Astrophysics, an open-source suite for one-dimensional stellar-evolution calculations
c-testsuite / Csmith · External test suites and a random C program generator used to check compiler correctness
Original abstract (English)
Complex software systems develop over timescales that exceed the lifespan of any individual coding agent. Most agentic software systems preserve continuity through persistent sessions, memories, managers or shared context. We introduce EvoX Genesis (hereafter, Genesis), which instead makes the software project persistent while allowing local agents to remain finite-lived. Genesis represents software as a persistent recursive world: each local world is situated by an accepted version and a repository path, finite-lived agents propose local changes, recursive delegation moves work across paths, and only accepted consequences advance the persistent version history. We evaluate this organization across formation, continuation and redevelopment. Starting from a repository with no compiler implementation, Genesis used DeepSeek V4 Flash to build a Rust-based C compiler with about 250k tracked lines; the run lasted over 120 hours, archived over 1,000 agent episodes and incurred only US$44 in model-token charges. The compiler passed the complete c-testsuite and most LLVM and Csmith tests. In a separate compiler world generated with GLM 5.2, development continued after repeated agent replacement while retaining full test performance. Genesis also reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace with nearly 90k Rust lines; across six numerical workloads, it achieved median speedups of 1.55--6.87x. These results show that long-horizon software development can be organized around a persistent project rather than a persistent agent.
