Great paper from Meta Superintelligence Labs on compounding inference for long-horizon agents.

One clear approach that’s working with large multi-agent systems is persistent memory.

Meta researchers describe a concrete approach for this in this paper.

You’ll find that inference-time compute usually goes to separate attempts, so most runs ignore partial work and failed ideas.

Here is how they solve this problem:

GitSwarm gives hundreds of asynchronous agents one shared Git repository.

Each contribution is a commit that records which earlier commits, on any branch, it builds on. There is no central planner. Each worker decides whether to explore, verify, refine, or combine existing work.

With GPT-5.5 Codex workers, it solves all 30 IMOProofBench-Advanced problems in one run. On ProgramBench, it scores 79.4%, against 65.1% for a single Codex agent prompted to keep going at a similar budget.

Score keeps rising with more workers, from 73.1% at 100 to 79.4% at 500. Later workers build on 94.7% of published contributions, and 70.1% of failed research commits are cited by later accepted work.

Paper: https://arxiv.org/abs/2610.04862

Chat with Paper: https://academy.dair.ai/papers/gitswarm-decentralized-compounding-inference-2610.04862…

GitSwarm: Decentralized Compounding Inference

Source: https://arxiv.org/html/2610.04862 Vedant ShahAffiliation:Meta Superintelligence LabsAffiliation:Mila - Québec AI InstituteAffiliation:Université de MontréalParas DahalAffiliation:Meta Superintelligence LabsMikhail PlekhanovAffiliation:Meta Superintelligence LabsCarole-Jean WuAffiliation:Meta Superintelligence LabsScott YihAffiliation:Meta Superintelligence LabsRemi MunosAffiliation:Meta Superintelligence LabsRob FergusAffiliation:Meta Superintelligence LabsJakob FoersterAffiliation:Meta Superintelligence LabsRuslan SalakhutdinovAffiliation:Carnegie Mellon UniversityWork done at MetaSanjeev AroraAffiliation:Princeton UniversityWork done at MetaJason WestonAffiliation:Meta Superintelligence LabsAaron CourvilleAffiliation:Mila - Québec AI InstituteAffiliation:Université de MontréalAnirudh GoyalAffiliation:Meta Superintelligence Labs

Abstract

Long-horizon problem solving and scientific research require computation to accumulate across successive attempts. Partial solutions, experimental findings, and even unsuccessful approaches can become useful to later work, yet most inference-time computation is organized around individual trajectories or candidates rather than a persistent body of reusable work. We call this paradigmcompounding inference: organizing inference-time computation so that intermediate work persists and can be inspected, extended, combined, or challenged by subsequent computation. We instantiate compounding inference inGitSwarm, an asynchronous system in which homogeneous agents independently decide how to advance a task while collaborating through structured persistent memory. Agents explore, experiment, verify, refine, and synthesize previous work in a shared, branchable Git repository. Atomic commits preserve intermediate artifacts, while explicit semantic dependencies record how later contributions build on work across branches. We evaluateGitSwarmon long-horizon problem solving and sustained GPU-backed experimental research. On IMOProofBench-Advanced,GitSwarmsolves all 30 problems in one run using GPT-5.5. On ProgramBench, it achieves a 79.4% mean score, compared with 65.1% for the strongest reported baseline under the stated budget. Across three neural architecture research tasks: Residual Matrix Transformer, Looped Transformer, and NanoChat,GitSwarmimproves upon the respective starting architectures through successive experimentation. Beyond final performance, we measure whether computation actually accumulates: on ProgramBench, 94.7% of contributions are subsequently built upon, while the selected solution’s transitive ancestry covers 82–93% of the contribution graph. Together, these results show that inference-time computation can accumulate across otherwise independent episodes, forming an evolving body of work that subsequent inference can reuse.

††correspondence:Vedant Shah ([email protected]), Anirudh Goyal ([email protected])Figure 1:Overview ofGitSwarm(Schematic).Homogeneous workers independently inspect, extend, and contribute to a shared, branchable repository. Contributions may include exploration, verification, repair, experimentation, or synthesis. Atomic commits preserve intermediate artifacts, while semantic dependencies link work across branches. The highlighted ancestry illustrates how successive contributions can accumulate into a final solution.## 1Introduction

Scaling inference-time computation improves language model performance through repeated sampling, longer reasoning trajectories, search, and multi-agent collaboration(Brown et al., 2024;Snell et al., 2024;Du et al., 2023). These approaches largely ask how additional computation should be spent. Long-horizon problem solving and scientific research pose a complementary challenge: useful computation must also accumulate across attempts.

The value of intermediate work is often unknown when it is produced. An unsuccessful experiment may reveal a promising direction; a partial solution may establish an ingredient used much later; competing approaches may contain ideas that become useful only when combined. If such work disappears when an episode terminates, later computation may need to rediscover it. Preserving it instead allows subsequent agents to build on an accumulated body of prior work. We call this paradigmcompounding inference: organizing inference-time computation into a persistent, evolving body of reusable work.

Existing approaches support different parts of this process. Independent sampling explores diverse candidates, longer reasoning trajectories retain work within an episode, and multi-agent systems enable collaboration, often through predefined roles, centralized planning, or shared conversations(Hong et al., 2024;Chen et al., 2024;Wang et al., 2025;Wu et al., 2023). Other approaches distill earlier attempts into summaries that guide subsequent inference(Madaan et al., 2025;Venkatraman et al., 2025;Kim et al., 2026). We investigate a different organization: independent workers preserve competing lines of work and their dependencies, while deciding for themselves which previous contributions to extend.

We instantiate compounding inference inGitSwarm, which uses a shared, branchable Git repository as structured persistent memory. Homogeneous workers operate asynchronously, inspect previous contributions, and independently decide whether to explore, experiment, verify, refine, or combine existing work. Each contribution is published as an atomic commit. Importantly,GitSwarmdistinguishes the repository state from which a worker begins from the additional prior contributions that its work depends on. Explicit semantic dependencies therefore allow a worker to extend one branch while drawing on discoveries from others. This preserves competing approaches without losing the connections between them. No central intellectual planner assigns tasks or roles; an execution harness manages scheduling and validation, while workers nominate candidates for final selection.

Our evaluation spans two settings. The first islong-horizon problem solving, where tasks have well-defined objectives and verifiable outcomes. We study mathematical proof and program reconstruction. On IMOProofBench-Advanced(Luong et al., 2025),GitSwarmsolves all 30 problems in one run using Codex (GPT-5.5-High) workers and slightly under one million output tokens. On ProgramBench(Yang et al., 2026), with Codex (GPT-5.5-High) workers, it achieves a 79.39% mean score, as compared to 65.12% for Forced Codex - a single Codex (GPT-5.5-High) agent repeatedly prompted to continue, at a comparable compute budget. Mean performance improves with inference-time computation over the tested ranges.

The second setting issustained experimental research, where agents must decide which experiments to run and learn from their outcomes. We evaluateGitSwarmon Residual Matrix Transformer(Mak and Flanigan, 2025), Looped Transformer(Geiping et al., 2025), and NanoChat.GitSwarmimproves upon the respective starting points in all three tasks. On Residual Matrix Transformer, two configurations achieve held-out losses of 2.890 and 2.894, compared with 3.147 for the reference, using the same 1.3B-token training budget. The resulting research histories show workers combining architectural changes developed on separate branches and revisiting initially unsuccessful experiments.

Beyond final performance, we examine whether earlier computation actually accumulates. Across the analyzed ProgramBench runs, 94.7% of contributions are subsequently referenced, and the selected solution’s transitive ancestry covers 81.6–92.6% of the contribution graph on average across budgets, largely through declared cross-branch dependencies. Execution traces provide separate evidence that workers consume earlier artifacts. Mathematical proof exhibits a different pattern: workers frequently reuse previous work to verify and compare candidates even when that work does not enter the selected proof’s ancestry. Together, these results show that persistent memory can support both the synthesis of earlier contributions and the accumulation of evidence that guides subsequent computation.

Our contributions are therefore threefold: we formulatecompounding inferenceas a paradigm for accumulating reusable inference-time computation across episodes; we introduceGitSwarmas a concrete realization based on persistent, branchable contributions with explicit cross-branch dependencies; and we evaluate both task performance and the accumulation process itself across problem solving and sustained experimental research.

2GitSwarm

GitSwarmimplements compounding inference through asynchronous, homogeneous workers collaborating over a shared Git repository. Workers independently decide how to advance the task, while an execution harness manages concurrency, isolation, validation, and publication. The repository preserves intermediate work as a branchable computation graph.

2.1Design Principles

We seek to accumulate computation without prescribing how agents should organize their work. This requires three properties of the shared memory:persistence, so intermediate discoveries survive their authors;branchability, so competing approaches can develop without prematurely committing to a single solution; andattribution, so subsequent workers can identify dependencies between contributions, including across branches. These properties supportadaptive, decentralized control: workers independently choose what to explore, verify, refine, or combine based on the evolving shared state. The harness coordinates execution but does not assign intellectual roles or prescribe a sequence of problem-solving stages.

2.2Shared Computation Graph

Consider a taskqq, a fixed language modelpθp_{\theta}, and a budget ofBBcharged worker episodes. For each task,GitSwarminitializes a Git repository containing the task specification and required artifacts, committed as an immutable rootv0v_{0}. Accepted contributions form an evolving graphGt=(Vt,Et)G_{t}=(V_{t},E_{t}), whereVt={v0,…,vt}V_{t}=\{v_{0},\ldots,v_{t}\}contains the root and the firstttpublished contributions. Each contributionviv_{i}is an atomic Git commit with a physical parentpi∈Vi−1p_{i}\in V_{i-1}. This parent identifies the state from which the worker began, but need not capture all the information used in its contribution.

To record additional dependencies, each worker declares a set of semantic sourcesUi⊆Vi−1U_{i}\subseteq V_{i-1}in a mandatoryinformed_by=field. The physical parent must be included inUiU_{i}. The graph contains both Git-parent edges and additional semantic-dependency edges:

Et=\displaystyle E_{t}={}{(pi,vi):1≤i≤t}\displaystyle\{(p_{i},v_{i}):1\leq i\leq t\}(1)∪{(u,vi):u∈Ui∖{pi},1≤i≤t}.\displaystyle}{\displaystyle\cup\{(u,v_{i}):u\in U_{i}\setminus\{p_{i}\},\ 1\leq i\leq t\}. Edges point from an earlier contribution to one that depends on it. This representation allows a worker to inherit one branch while using discoveries from others, without requiring merges. Semantic dependencies are declared by workers, not independently established as causal influence.

2.3Asynchronous Worker Protocol

A run has a budget ofBBcharged worker episodes and maximum concurrencyCC. The harness maintains up toCCactive workers, launching replacements as slots become available. All workers use the same model and behavioral contract, without predefined roles.

Each worker operates in an isolated Git worktree. It inspects the repository, selects a starting commit, and independently decides how to advance the task. Each episode ends with one of three actions:

1. 1.Contribute:Publish one validated, atomic commit containing new work, such as a partial solution, experiment, test, or refinement. Validation enforces task-specific publication requirements, not solution correctness.
2. 2.Nominate:Select an existing candidate and publish a separate nomination record with a rationale, without modifying the candidate.
3. 3.Abstain:Terminate without publication when no useful additional work is identified or equivalent work is already underway.

Voluntary abstentions trigger replacement without consumingBB, although they incur inference costs; other episode outcomes consume the budget. Workers may therefore allocate effort adaptively among exploration, refinement, experimentation, verification, integration, and selection.

2.4Live Swarm State: Dashboard and In-Flight Activity

Workers also see the current state of the run and what their peers are doing, through two interfaces that report state but do not assign work (Figure2).

Dashboard.Every worker receives a dashboard snapshot at spawn time and can query the live state withgs_dashboard. It reports the remaining worker budget, the workers in flight, and the nomination tally, noting that votes are not evidence of correctness. For research tasks, which use a wall-clock budget and select the final model by validation score, the budget and nomination fields are replaced by shared GPU, CPU, and job usage, a warning when GPU utilization is low, and the best validation score with its commit.

In-flight activity.Since uncommitted work is invisible in the repository, each worker keeps a public activity log viags_inflight. It announces its scope (gap, deliverable, success and abort criteria) before editing and posts progress updates. Peers can list active workers or inspect a worker’s log and uncommitted changes, but cannot modify them. This is meant to help workers avoid taking up work which is already being undertaken by their in-flight peers.

Figure 2:Live swarm state.(a) A dashboard combining fields from a ProgramBench worker (B=200B=200) and a Residual Matrix Transformer worker; shading marks fields shown only for one task type. (b) A ProgramBench worker inspecting a peer’s activity log. Text is taken from worker traces and abridged.

2.5Decentralized Readout

While the agents work asynchronously, eventually a consensus needs to form on which exact commit to submit. We keep this process distributed across workers rather than delegating to privileged final judge, referring to the process asdecentralized readout. Letcic_{i}be the candidate identified in nomination recordii. After the worker budget is exhausted, the harness selects the candidate with the most nominations:

v⋆=argmaxv∈Vcand∑i𝕀[ci=v],v^{\star}=\arg\max_{v\in V_{\mathrm{cand}}}\sum_{i}\mathbb{I}[c_{i}=v],(2)with deterministic tie-breaking. Nomination records remain separate from the computation graph. Workers can therefore evaluate existing candidates while others continue constructing new ones, without changing the ancestry of the eventually selected solution.

Summary.Together, persistent commits, cross-branch reuse, and decentralized worker decisions allow computation to accumulate across otherwise independent episodes. We next evaluate this approach on long-horizon problem solving and sustained experimental research, and examine how intermediate work is reused.

3Experiments

We evaluateGitSwarmin two settings: long-horizon problem solving and sustained experimental research. We first measure benchmark performance and inference-time scaling on mathematical proof and program reconstruction. We then study three GPU-backed architecture research tasks. Finally, we examine reuse, transitive accumulation, and adaptive coordination. Controlled synthetic tests (AppendixC) and architectural comparisons probe individual system properties.

3.1Experimental Setup

Problem-solving tasks.IMOProofBench-Advanced(Luong et al., 2025)contains 30 mathematical proof problems. ProgramBench(Yang et al., 2026)asks agents to reconstruct programs from documentation and an execute-only reference. We evaluate all 30 proof problems and a fixed subset of 50 ProgramBench tasks, stratified by language, difficulty, test-suite size, and runtime (AppendixB.2). We use nine separate programming tasks and six proof problems during development; the latter are included in the full proof evaluation. Scoring rules and task selection are detailed in AppendixB.1.

Models and baselines.For IMOProofBench-Adavnced, we useGitSwarmwith Gemini-3.1-Pro and GPT-5.5-high workers. We compare against single agents using bash, mini-SWE-agent(Lieret and Jimenez, 2025), or Codex(OpenAI, 2025)(as appropriate to the model), repeatedly prompted to continue after stopping. For ProgramBench, we use Codex (GPT-5.5-high) workers and GPT-5.5 workers at the default reasoning effort, and compare against a repeatedly continued Codex (GPT-5.5-high) agent. We always use a worker concurrency of 5 forGitSwarmin the case of problem-solving tasks. We call these continued single-agent baselinesForcedand evaluate their intermediate natural stopping checkpoints.

Compute accounting.GitSwarm’s budgetBBcounts charged worker episodes. Voluntary abstentions are replaced without consuming the budget, although they still incur inference costs. Programming runs use budgets of 100, 200, 300, and 500 episodes; proof runs use 20, 40, 80, 120, and 160. These measurements account for differences in the amount of work performed within an episode.

We report performance scaling curves with respect to input and output token counts in the case of problem-solving tasks. We count tokens per model request and sum them over all requests made by a worker or agent: input tokens count the full prompt sent with each request, including all previously accumulated context. Output tokens count only the tokens newly generated in that request, including hidden reasoning tokens. Reported values are per-problem totals averaged across problems. record input and output tokens. The research experiments use separate GPU and time budgets, introduced alongside each task. Full prompts and compute protocols appear in the appendix.

3.2Benchmark Performance and Inference-Time Scaling

We first test whether additional inference-time compute improves performance on tasks with well-defined answers. We evaluate program reconstruction and mathematical proof, measuring both final performance and how it changes as workers receive larger budgets.

ProgramBench.Figure3examines scaling on the 50 tasks shared by all plotted runs. With Codex workers,GitSwarmimproves from 73.1% with 100 workers to 79.4% with 500. With GPT-5.5 workers, it improves from 64.6% with 100 workers to 71.2% with 300. In comparison, the sequentially continued Codex baseline remains between 63.1% and 65.1% across its plotted checkpoints.GitSwarm’s gains diminish at larger budgets, while input-token costs grow as workers inspect an expanding repository.

IMOProofBench-Advanced.We next test whether scaling also helps on mathematical proof problems. With Gemini-3.1-Pro, the mean number of fully correct proofs increases from 23.3 at a budget of 20 workers to 29.0 at 160. The curve is not monotonic: performance decreases locally at a budget of 80. The forced mini-SWE-agent baseline reaches at most 23 fully correct proofs on its plotted curve. The continued bash agent baseline solved 26.5 problems at similar input token budget. With GPT-5.5-high workers,GitSwarmsolves 28 of 30 problems at a budget of 20 workers and all 30 at budgets of 40 and 80. Note that Best-of-N baselines (with oracle verifier) also reach the benchmark ceiling at lower token consumptions, so saturating this benchmark does not establish a unique advantage for GitSwarmFull proof results and compute breakdowns appear in AppendixD.

Figure 3:Inference-time scaling.Performance against input and output tokens on ProgramBench (a, b) and IMOProofBench-Advanced with Gemini-3.1-Pro (c, d). EachGitSwarmpoint represents one run at the indicated worker budget.These benchmarks show how performance changes with additional inference-time compute. Both, however, have fixed targets and established evaluation procedures. We next consider open-ended research, where workers must also decide which experiments to run and how to build on their results.

3.3Sustained Experimental Research

We next move from fixed-answer problems to open-ended research, where workers must decide what to investigate, run experiments, and interpret their results. We study three neural architecture tasks: Residual Matrix Transformer (RMT)(Mak and Flanigan, 2025), Looped Transformer(Geiping et al., 2025), and NanoChat(Karpathy, 2025). Workers share code and experimental findings through the repository and submit GPU jobs to a shared resource allocation through SLURM. Each task has its own research objective and compute budget. We stripGitSwarmof the nomination based decentralized readout for these experiments since all tasks discussed here support a validation performance based candidate selection (AppendixE.1).

Residual Matrix Transformer.Starting from RMT(Mak and Flanigan, 2025), workers seek architectural improvements while preserving its matrix-valued residual state and remaining below 350M parameters. We run two 12 Codex (GPT-5.6-sol; xHigh effort) worker swarms with for 72 hours on an 8 GPU H200 node, allocating either eight or four GPUs collectively to the swarm for running experiments.

The two swarms achieve held-out losses of 2.890 and 2.894, compared with 3.147 for the reference. All three models train on 1.3B tokens. Forced GPT-5.6-sol (xHigh effort) reaches 2.927 with 3.0B training tokens, while Codex reaches 2.690 with 10.1B. Thus, both swarms improve the reference architecture at its original training-token budget. Figure4shows how the 8-GPU swarm arrived at its final architecture. Four of its six changes originated on other branches. Notably, one of them began as a failed attempt to use the previous token’s memory. Another worker revisited the result 49.5 hours later, extended the idea to multiple preceding tokens, and developed a temporal mixer that entered the final model. The best architecture’s declared dependencies span 24 commits by 24 workers. The changes made by codex on the other hand involved simply increasing the width of the attention layer and scaling the training budget. Thus,GitSwarmcame up with more interesting architecture modifications.

The repository also supports reuse across completed searches. In a separate run, we seededGitSwarmwith the winning commits from three prior independentGitSwarmruns. Workers combined their discoveries and reduced the inherited best development loss from 2.909 to 2.898 in approximately 28 hours. This run inherited prior research, so its progress is not directly comparable to an independent run. Full trajectories, experimental histories and a more detailed discussion of the findings appear in AppendixE.2.

(a) Development loss

(b) Research dependencies

Figure 4:RMT research.(a) Best-so-far development loss over the 72-hour research budget; the reference loss is 3.158. (b) The 8-GPU swarm’s research graph, showing competing branches, integration into the final architecture, and recovery of an earlier failed idea.Looped Transformer.We next study Huginn(Geiping et al., 2025), a 308M-parameter transformer with weight-tied recurrence. Workers must preserve recurrence and remain below 350M unique parameters. A 12-worker swarm uses Codex (GPT-5.5; High effort) workers with a 48-hour budget on one 8 GPU H200 node.

After 26 hours, the swarm reaches a protected-development loss of 3.187, compared with 3.265 for the reference, 3.274 for direct GPT, and 3.479 for Codex. The winning architecture changes the recurrent input adapter from a linear layer to a gated feed-forward network. A parameter-matched control reaches 3.212, retaining two thirds of the improvement. Its research history tells a different story from RMT. The winning adapter was proposed early but rejected after evaluation on 128 examples subset of the full development set. Other workers re-evaluated it on 512 examples and confirmed the improvement on the full development set. Subsequent analysis found that the smaller evaluation misranked five of twelve model pairs, compared with one at 512 examples.

As Figure5shows, the winning code follows a relatively short development path, but its declared dependencies span 89 commits. Much of this additional history consists of experimental evidence rather than transferred code. During the first 26 hours, workers conducted 395 architectural experiments across twelve idea families; 74% of negative architectural results were subsequently cited. Full controls and research histories appear in AppendixE.3.

(a) Development loss

(b) Research dependencies

Figure 5:Looped Transformer research.(a) Best-so-far development loss at eight recurrences. Arrows mark ongoing runs; the two-node GPT-5.6 run is not compute-matched. (b) The winning adapter’s development path and its wider evidence dependencies, including reversal of an early rejection and reuse of negative results.NanoChat.Finally, we study joint architecture and training-system improvement on NanoChat. Workers start from a 50.3M-parameter language model and may change its architecture, optimizer, and training implementation. The data, tokenizer, and evaluator remain fixed. Each candidate is trained from scratch under a five-minute GPU training clock and evaluated using validation bits per byte (BPB; lower is better). We compareGitSwarmwith single-agent Codex and an Atlas-style evolutionary-search baseline(Hambardzumyan et al., 2026), using 16 GPUs per run over the first 24 active research hours on H200 or GB300 hardware.

In the GPT-6-Astra + GB300 run, a 20-worker swarm reduces validation BPB from 0.993 to 0.905 through 1,465 successful evaluations. Its incumbent combines several changes developed on separate branches, including shared hashed bigram and trigram embeddings. Unlike the preceding tasks, NanoChat does not constrain model capacity: the incumbent grows to approximately 1.72B parameters, predominantly in its lexical table. The improvement therefore reflects joint search over architecture, capacity, optimization, and training systems.

The research graph in Figure6shows how an early failure also informs the final design. Separate trigram tables initially perform poorly. Approximately 21 active hours later, another worker reuses their hashing scheme in a shared-table design. A subsequent worker enlarges the table, producing the 24-hour incumbent. More broadly, 70.1% of negative-labelled research commits are cited by later accepted contributions. Complete source comparisons and protocol details appear in AppendixE.4.

These histories reveal distinct forms of compounding research. RMT integrates architectural changes from separate branches. Looped Transformer accumulates evidence that overturns an early experimental verdict. NanoChat explores a broader space of model and training changes, including ideas recovered from unsuccessful experiments. We next examine how frequently workers reuse earlier contributions across the benchmark runs.

(a) Validation BPB

(b) Research dependencies

Figure 6:NanoChat research over the first 24 active hours.(a) Validation BPB across methods and hardware configurations. (b) Selected dependencies in the Astra/GB300 swarm. Green marks incumbent ancestry, gray dashed edges mark code or evidence reuse, and purple marks reuse of negative results. Crossed red nodes are negative results; hollow amber nodes are inconclusive. The graph contracts omitted ancestry and is not a time axis.

3.4Evidence for Compounding Computation

The research histories show how earlier discoveries can shape later work. We now examine how frequently this happens across the benchmark runs. We measure three aspects of reuse: declared dependencies, artifact consumption observed in execution traces, and ancestry of selected solutions. We conduct this analysis on the ProgramBench and IMOProofBench-Advanced evaluation runs reported in Section3.2.

Declared reuse.Workers cite earlier contributions in nearly every eligible episode: 99.9% on ProgramBench and 96.2% on IMOProofBench-Advanced. Later workers build upon 94.7% and 44.4% of published contributions, respectively, by naming them as Git parents orinformed_by=sources. These measurements pool 200 ProgramBench runs and 150 proof runs across the evaluated budgets.

Figure 7:Selected-solution ancestry.Share of contributions reached through Git-parent ancestry, additionalinformed_by=dependencies, or neither, across worker budgets. ProgramBench solutions incorporate much of the contribution graph, primarily through cross-branch dependencies. In contrast, selected IMOProofBench proofs have shallower ancestry: later work often evaluates and compares existing candidates rather than extending the selected proof.Selected-solution ancestry.The two tasks differ in how earlier work enters the final solution. On ProgramBench, the selected solution’s transitive ancestry covers 81.6–92.6% of the contribution graph on average across budgets. Git-parent ancestry accounts for only about one quarter of the graph; declared cross-branch dependencies connect most of the remainder (Figures7and8). On IMOProofBench-Advanced, selected proofs reach only 21.3–33.0% of the graph. This can be explained by the fact that final solutions appear relatively early in the graph in the case of IMOProofBench. Later workers often evaluate and nominate existing candidates rather than extending them. Thus, programming typically accumulates contributions into a final implementation, while proof solving uses earlier work to compare and select candidates. Contribution graphs also reveal interesting collaboration workflows, such as late integration of separately developed branches and a gradual pivot between subsystems (Figure9).

Figure 8:Selected-solution ancestry in a ProgramBench run (FFmpeg B100).Commits over normalized task runtime. The selected winner’s transitive ancestry (green), reached through Git parents andinformed_by=edges, covers 83.7% of the contribution graph; only a few commits, mostly late in the run, lie outside it (gray).Artifact consumption.We ask workers to leave informative and reusable artifacts in their commits, meant to be consumed by future workers which build upon their work. Declared dependencies do not by themselves establish that workers consume earlier artifacts. We thus analyse artifact consumption by workers from execution traces. On ProgramBench, 79.9–82.5% of eligible voluntary artifact bundles are actively reused, often across Git branches. On IMOProofBench-Advanced, workers open 583 of 759 computational probe bundles. Later workers execute or adapt 172 of these while citing their producers; 52 feed contributions in the selected solution’s ancestry. Required reasoning and evaluation artifacts are also accessed in approximately 98–99% of eligible revisions across both domains. Together, these measurements show that persistent memory supports both synthesis and candidate evaluation. They establish observed reuse, not the causal contribution of individual dependencies to performance. Measurement definitions, more detailed artifact breakdowns and discussion on the workflow examples appear in AppendicesF.1,F.2, andF.3.

Figure 9:Collaboration workflows in two ProgramBench runs.Commits over normalized task runtime. (a) Separately developed branches (colored) converge late on the strongest integration (diamond), which the selected winner builds on. (b) Work pivots from CLI and configuration (orange) to renderers (blue), which become the selected lineage.

3.5Adaptive Coordination and Design Tradeoffs

Figure 10:ProgramBench worker activity over inference.Share of worker episodes by activity category (Table12) against worker-spawn progress, per worker budget; the black line tops all contribution commits. After a short bootstrap wave, workers keep expanding, repairing, and synthesizing candidates until termination, and nomination rises only near the end. The IMOProofBench-Advanced counterpart appears in Figure20.The different ancestry patterns are reflected in how workers allocate their effort. The workers inGitSwarmhave no fixed assigned roles. New workers dynamically decide the kind of contribution to make depending on the work committed so far. We analyse the work done by workers over the systems’ progress. We label each worker episode after the run with one primary activity, using a bottom-up taxonomy derived separately for each benchmark (AppendixG.1). On ProgramBench (Figure10), a short wave creates initial candidates, after which capability expansion, fidelity repair, and candidate synthesis persist through termination. Nomination becomes more prominent near the end - eating into, yet not completely replacing implementation work. Thus additional workers find several ways to improve the candidate rather than only repeat comparisons. Empirical validation remains uncommon and becomes visible mainly at larger budgets. Consistent with this sustained construction, the selected candidate first appears at a median of 93.1–98.0% of run progress across budgets. On IMOProofBench-Advanced, by contrast, workers shift early toward selecting among existing proofs (Appendix Figure20): selected proofs appear at 8.6–17.5% of run progress, and the share of episodes devoted to selection rises from 44.2% to 69.7% as the budget grows from 20 to 160. These patterns emerge without assigned worker roles.

Workers also avoid some redundant work and inspect the repository (AppendixG.5). About one in six ProgramBench workers abstains after identifying equivalent work, compared with fewer than 2.7% of proof workers. Abstention avoids duplicate publication but cannot recover computation already spent. Programming workers typically inspect five to seven candidate commits, and proof workers about three, rather than reading the entire growing graph. Detailed activity and coordination analyses appear in AppendicesG.1,G.3andG.4.

Design tradeoffs.We compare asynchronous execution and decentralized readout on nine ProgramBench development tasks, using GPT-5.5 workers, a budget of 50 workers, five concurrent workers, and three seeds. Asynchronous execution takes 38.0 minutes on average, versus 49.3 minutes for synchronized waves. Their observed scores are62.06±2.44%62.06\pm 2.44\%and63.11±0.58%63.11\pm 0.58\%, respectively.

For readout, decentralized nomination achieves62.06±2.44%62.06\pm 2.44\%in 38.0 minutes, compared with64.40±1.49%64.40\pm 1.49\%in 34.9 minutes for a central selector. A central aggregation agent achieves58.19±4.53%58.19\pm 4.53\%in 43.9 minutes. These small development-set experiments characterize latency and readout tradeoffs; they do not establish statistical equivalence or isolate the benefits of persistent memory. Full results appear in AppendixG.6.

4Discussion and Limitations

Our results reveal different forms of compounding inference. In program reconstruction, workers repeatedly integrate discoveries from different branches into increasingly capable solutions. In mathematical proof, workers often use previous work to verify and compare candidates without extending the selected proof’s lineage. The architecture research experiments illustrate both cross-branch synthesis and the value of revisiting earlier failures: the RMT architecture incorporates mechanisms developed on separate branches, while the Looped Transformer run recovers an initially rejected idea through further evaluation. Useful computation therefore need not appear directly in the final candidate’s ancestry; it may also inform which directions are pursued, rejected, or selected.

Causal attribution.Our dependency and execution-trace analyses establish that workers inspect, reuse, and accumulate previous work, but do not isolate the resulting performance gains. The mandatoryinformed_by=field records worker-declared dependencies, while observed artifact consumption provides evidence of use rather than causal influence. Conversely, selected-solution ancestry omits potentially useful verification and candidate comparison. A direct intervention would resume matched runs from the same candidate, with and without access to its preceding research history, under equal remaining compute. Separate interventions would be needed to isolate the effects of persistence, branchability, and cross-branch dependencies. Our synthetic experiments demonstrate their operational benefits but do not establish their individual contributions to benchmark performance.

Evaluation scope.Our results are conditional on the evaluated tasks and budgets. ProgramBench performance is measured on a fixed 50-task subset out of a total of 200 tasks. The perfect IMOProofBench-Advanced result is a single run; some independent-sampling and Forced baselines also reach the benchmark ceiling, and execution conditions differ across some proof comparisons. In AutoResearch, the RMT swarm models and reference share the same 1.3B-token training budget, whereas the compared single-agent models use more training tokens. The seeded RMT run additionally inherits earlier research. The recorded Looped Transformer runs were still in progress, and NanoChat comparisons vary in starting checkpoint and GPU allocation.GitSwarmimproves upon the starting points across all three research tasks, but the results do not establish superiority over every single-agent configuration.

Computational overhead.Persistent collaboration incurs costs as the repository grows. Workers consume input tokens inspecting previous contributions, while redundant and unsuccessful episodes can spend compute without producing accepted work. GPU-backed research adds resource contention and scheduling overhead. Although performance improves with additional inference-time compute over the tested ranges, understanding when the benefits of accumulated work outweigh these costs requires longer-horizon evaluations with matched total compute and wall-clock budgets.

5Conclusion

We introducedcompounding inference, in which intermediate work persists and can be extended across independent agent episodes.GitSwarmprovides a substrate for this process through asynchronous workers, a shared branchable repository, and explicit cross-branch dependencies, without a central intellectual planner. Across problem solving and GPU-backed research, we observe extensive reuse of earlier work, including the synthesis of independent discoveries and the recovery of initially unsuccessful ideas. We view this substrate as afoundation for long-horizon discovery. It supports a continuing loop in which agents propose ideas, run experiments, preserve their findings, and use earlier evidence to guide new research. A natural next step is to train agents with reinforcement learning across diverse tasks within this environment. Rather than rewarding only the outcome of an individual episode, such training could incentivize contributions whose value emerges through subsequent work, enabling agents to learn not just to solve problems, but to advance acollective process of discovery.

AI Usage Statement

Large language model based digital agents are the object of study in this work: every agent is a frontier model accessed through a provider API. An LLM is also used as a measurement instrument. Experiments combine semantic judgments by an LLM analyzer, and also to design synthetic tasks. LLMs based coding agents were used to assist in implementing code, which was reviewed by one author, and for generating draft versions of scientific figures. LLMs and generative AI tools were not used to develop theoretical models or conceptual frameworks, formulate mathematical claims, provide critical ingredients for proving mathematical claims, assist in the writing of proofs, propose or refine hypotheses, to support qualitative and thematic data analysis, design or provide feedback on research methodology or experiments, assist with translation, clean and reformat dataset, interpret results. We have reviewed all AI-assisted work and take responsibility for the final content of this paper, including text, claims, and artifacts produced with the aid of generative AI.

Ethics Statement

This work involves no human subjects, crowdsourced annotation, or personal data; all experiments use public benchmarks (IMOProofBench-Advanced and ProgramBench) and research tasks based on publicly available research papers. BecauseGitSwarmlets LLM agents execute code and launch GPU jobs autonomously, workers operated in isolated Git worktrees and isolated environments with no internet access throughout our experiments. Candidates were scored by fixed evaluators on protected development and separate held-out sets. Two capabilities studied here are dual-use: reconstructing programs from an execute-only reference and its documentation could facilitate unauthorized re-implementation of proprietary software, and automating architecture research could accelerate AI development, including of systems with potential for misuse. We therefore viewGitSwarmas a tool for human-supervised research; as our analyses show, agents’ intermediate conclusions can be wrong (small proxy evaluations mis-ranked candidate models), so results should be independently verified before they are relied upon. With recents events involving swarms of agents showing increasingly mis-aligned behavior and escaping sandboxes, we believe that extensive behavioral analysis, including the kind discussed in this paper, is warranted pre-deployment.

Acknowledgements

The authors would like to thank Sneha Silwal, Harman Singh, Vineet Jain, Nanda H Krishna, Sinong Wang, Hanjun Dai, Xinyun Chen, Xin Wang, Tianhe Yu, Liang Tan, Roshan James and Trapit Bansal for helpful discussions and feedback.

References

• Baars (1988)Bernard J. Baars.A Cognitive Theory of Consciousness.Cambridge University Press, Cambridge, 1988.ISBN 9780521301336.
• Brown et al. (2024)Bradley Brown, Jordan Juravsky, Ryan Ehrlich, Ronald Clark, Quoc V. Le, Christopher Ré, and Azalia Mirhoseini.Large language monkeys: Scaling inference compute with repeated sampling.arXiv preprint arXiv:2407.21787, 2024.https://arxiv.org/abs/2407.21787.
• Chen et al. (2024)Weize Chen, Yusheng Su, Jingwei Zuo, Cheng Yang, Chenfei Yuan, Chi-Min Chan, Heyang Yu, Yaxi Lu, Yi-Hsin Hung, Chen Qian, Yujia Qin, Xin Cong, Ruobing Xie, Zhiyuan Liu, Maosong Sun, and Jie Zhou.AgentVerse: Facilitating multi-agent collaboration and exploring emergent behaviors.InThe Twelfth International Conference on Learning Representations, 2024.https://iclr.cc/virtual/2024/poster/19109.
• Du et al. (2023)Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch.Improving factuality and reasoning in language models through multiagent debate.arXiv preprint arXiv:2305.14325, 2023.https://arxiv.org/abs/2305.14325.
• Erman et al. (1980)Lee D. Erman, Frederick Hayes-Roth, Victor R. Lesser, and D. Raj Reddy.The HEARSAY-II speech-understanding system: Integrating knowledge to resolve uncertainty.ACM Computing Surveys, 12(2):213–253, June 1980.10.1145/356810.356816.
• Fourney et al. (2024)Adam Fourney, Gagan Bansal, Hussein Mozannar, et al.Magentic-one: A generalist multi-agent system for solving complex tasks.arXiv preprint arXiv:2411.04468, 2024.https://arxiv.org/abs/2411.04468.
• Garikaparthi et al. (2026)Aniketh Garikaparthi, Manasi Patwardhan, and Arman Cohan.ResearchGym: Evaluating language model agents on real-world AI research.arXiv preprint arXiv:2602.15112, 2026.https://arxiv.org/abs/2602.15112.
• Geiping et al. (2025)Jonas Geiping, Sean McLeish, Neel Jain, John Kirchenbauer, Siddharth Singh, Brian R. Bartoldson, Bhavya Kailkhura, Abhinav Bhatele, and Tom Goldstein.Scaling up test-time compute with latent reasoning: A recurrent depth approach.InAdvances in Neural Information Processing Systems, 2025.https://arxiv.org/abs/2502.05171.
• Geng and Neubig (2026)Jiayi Geng and Graham Neubig.Effective strategies for asynchronous software engineering agents.arXiv preprint arXiv:2603.21489, 2026.https://arxiv.org/abs/2603.21489.
• Gottweis et al. (2025)Juraj Gottweis, Wei-Hung Weng, Alexander Daryin, Tao Tu, Anil Palepu, Petar Sirkovic, Artiom Myaskovsky, Felix Weissenberger, Keran Rong, Ryutaro Tanno, Khaled Saab, Dan Popovici, Jacob Blum, Fan Zhang, Katherine Chou, Avinatan Hassidim, Burak Gokturk, Amin Vahdat, Pushmeet Kohli, Yossi Matias, Andrew Carroll, Kavita Kulkarni, Nenad Tomasev, Yuan Guan, Vikram Dhillon, Eeshit Dhaval Vaishnav, Byron Lee, Tiago R. D. Costa, José R. Penadés, Gary Peltz, Yunhan Xu, Annalisa Pawlosky, Alan Karthikesalingam, and Vivek Natarajan.Towards an AI co-scientist.arXiv preprint arXiv:2502.18864v1, 2025.https://arxiv.org/abs/2502.18864v1.
• Goyal et al. (2022)Anirudh Goyal, Aniket Rajiv Didolkar, Alex Lamb, Kartikeya Badola, Nan Rosemary Ke, Nasim Rahaman, Jonathan Binas, Charles Blundell, Michael Curtis Mozer, and Yoshua Bengio.Coordination among neural modules through a shared global workspace.InInternational Conference on Learning Representations, 2022.
• Hambardzumyan et al. (2026)Karen Hambardzumyan, Nicolas Baldwin, Edan Toledo, Rishi Hazra, Michael Kuchnik, Bassel Al Omari, Thomas Simon Foster, Anton Protopopov, Jean-Christophe Gagnon-Audet, Ishita Mediratta, Kelvin Niu, Michael Shvartsman, Alisia Lupidi, Alexis Audran-Reiss, Parth Pathak, Tatiana Shavrina, Despoina Magka, Hela Momand, Derek Dunfield, Nicola Cancedda, Pontus Stenetorp, Carole-Jean Wu, Jakob Nicolaus Foerster, Yoram Bachrach, and Martin Josifoski.AIRA2: Overcoming bottlenecks in AI research agents.arXiv preprint arXiv:2603.26499, 2026.https://arxiv.org/abs/2603.26499.
• Hong et al. (2024)Sirui Hong, Mingchen Zhuge, Jiaqi Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber.MetaGPT: Meta programming for a multi-agent collaborative framework.InThe Twelfth International Conference on Learning Representations, 2024.https://iclr.cc/virtual/2024/poster/19756.
• Huang et al. (2024)Qian Huang, Jian Vora, Percy Liang, and Jure Leskovec.MLAgentBench: Evaluating language agents on machine learning experimentation.InProceedings of the 41st International Conference on Machine Learning, volume 235 ofProceedings of Machine Learning Research, pages 20271–20309. PMLR, 2024.https://proceedings.mlr.press/v235/huang24y.html.
• Juneja et al. (2026)Gurusha Juneja, Arnav Kumar Jain, Deepak Nathani, William Yang Wang, and Xin Eric Wang.Learning the ARTS of search for automated discovery.arXiv preprint arXiv:2606.21891, 2026.
• Karpathy (2025)Andrej Karpathy.nanochat: The best chatgpt that $100 can buy, 2025.https://github.com/karpathy/nanochat.
• Karpathy (2026)Andrej Karpathy.Autoresearch: Ai agents running research on single-gpu nanochat training automatically.Software repository, 2026.https://github.com/karpathy/autoresearch.
• Kim et al. (2026)Joongwon Kim, Wannan Yang, Kelvin Niu, Hongming Zhang, Yun Zhu, Eryk Helenowski, Ruan Silva, Zhengxing Chen, Srinivasan Iyer, Manzil Zaheer, Daniel Fried, Hannaneh Hajishirzi, Sanjeev Arora, Gabriel Synnaeve, Ruslan Salakhutdinov, and Anirudh Goyal.Scaling test-time compute for agentic coding.arXiv preprint arXiv:2604.16529, 2026.https://arxiv.org/abs/2604.16529.
• Lee et al. (2026)Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, and Chelsea Finn.Meta-harness: End-to-end optimization of model harnesses.arXiv preprint arXiv:2603.28052, 2026.
• Li et al. (2025)Yang Li, Siqi Ping, Xiyu Chen, Xiaojian Qi, Zigan Wang, Ye Luo, and Xiaowei Zhang.AgentGit: A version control framework for reliable and scalable LLM-powered multi-agent systems.arXiv preprint arXiv:2511.00628, 2025.https://arxiv.org/abs/2511.00628.
• Lieret and Jimenez (2025)Kilian Lieret and Carlos E. Jimenez.mini-SWE-agent: A simple software engineering agent.https://github.com/SWE-agent/mini-swe-agent, 2025.Software repository.
• Lu et al. (2024)Chris Lu, Cong Lu, Robert Tjarko Lange, Jakob Foerster, Jeff Clune, and David Ha.The AI scientist: Towards fully automated open-ended scientific discovery.arXiv preprint arXiv:2408.06292, 2024.https://arxiv.org/abs/2408.06292.
• Luong et al. (2025)Thang Luong, Dawsen Hwang, Hoang H. Nguyen, Golnaz Ghiasi, Yuri Chervonyi, Insuk Seo, Junsu Kim, Garrett Bingham, Jonathan Lee, Swaroop Mishra, Alex Zhai, Clara Huiyi Hu, Henryk Michalewski, Jimin Kim, Jeonghyun Ahn, Junhwi Bae, Xingyou Song, Trieu H. Trinh, Quoc V. Le, and Junehyuk Jung.Towards robust mathematical reasoning.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, 2025.https://aclanthology.org/2025.emnlp-main.1794/.
• Lupidi et al. (2026)Alisia Lupidi, Bhavul Gauri, Thomas Simon Foster, Bassel Al Omari, Despoina Magka, Alberto Pepe, Alexis Audran-Reiss, Muna Aghamelu, Nicolas Baldwin, Lucia Cipolina-Kun, Jean-Christophe Gagnon-Audet, Chee Hau Leow, Sandra Lefdal, Hossam Mossalam, Abhinav Moudgil, Saba Nazir, Emanuel Tewolde, Isabel Urrego, Jordi Armengol Estape, Amar Budhiraja, Gaurav Chaurasia, Abhishek Charnalia, Derek Dunfield, Karen Hambardzumyan, Daniel Izcovich, Martin Josifoski, Ishita Mediratta, Kelvin Niu, Parth Pathak, Michael Shvartsman, Edan Toledo, Anton Protopopov, Roberta Raileanu, Alexander Miller, Tatiana Shavrina, Jakob Foerster, and Yoram Bachrach.AIRS-Bench: A suite of tasks for frontier AI research science agents.arXiv preprint arXiv:2602.06855, 2026.https://arxiv.org/abs/2602.06855.
• Madaan et al. (2025)Lovish Madaan, Aniket Didolkar, Suchin Gururangan, John Quan, Ruan Silva, Ruslan Salakhutdinov, Manzil Zaheer, Sanjeev Arora, and Anirudh Goyal.Rethinking thinking tokens: LLMs as improvement operators.arXiv preprint arXiv:2510.01123, 2025.https://arxiv.org/abs/2510.01123.
• Maheswaran et al. (2026)Monishwaran Maheswaran, Leon Lakhani, Zhongzhu Zhou, Shijia Yang, Junxiong Wang, Coleman Hooper, Yuezhou Hu, Rishabh Tiwari, Jue Wang, Harman Singh, Qingyang Wu, Yuqing Jian, Ce Zhang, Kurt Keutzer, Tri Dao, Xiaoxia Wu, Ben Athiwaratkun, James Zou, and Chenfeng Xu.Squeeze Evolve: Unified multi-model orchestration for verifier-free evolution.arXiv preprint arXiv:2604.07725, 2026.10.48550/arXiv.2604.07725.https://arxiv.org/abs/2604.07725.
• Mak and Flanigan (2025)Brian Mak and Jeffrey Flanigan.Residual matrix transformers: Scaling the size of the residual stream.arXiv preprint arXiv:2506.22696, 2025.https://arxiv.org/abs/2506.22696.
• Nathani et al. (2025)Deepak Nathani, Lovish Madaan, Nicholas Roberts, Nikolay Bashlykov, Ajay Menon, Vincent Moens, Amar Budhiraja, Despoina Magka, Vladislav Vorotilov, Gaurav Chaurasia, Dieuwke Hupkes, Ricardo Silveira Cabral, Tatiana Shavrina, Jakob Nicolaus Foerster, Yoram Bachrach, William Yang Wang, and Roberta Raileanu.MLGym: A new framework and benchmark for advancing AI research agents.arXiv preprint arXiv:2502.14499, 2025.https://arxiv.org/abs/2502.14499.
• Nii (1986)H. Penny Nii.The blackboard model of problem solving and the evolution of blackboard architectures.AI Magazine, 7(2):38–53, 1986.10.1609/aimag.v7i2.537.
• Novikov et al. (2025)Alexander Novikov, Ngân Vũ, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli, and Matej Balog.AlphaEvolve: A coding agent for scientific and algorithmic discovery.arXiv preprint arXiv:2506.13131, 2025.https://arxiv.org/abs/2506.13131.
• OpenAI (2025)OpenAI.Introducing Codex.https://openai.com/index/introducing-codex/, 2025.
• Packer et al. (2023)Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez.MemGPT: Towards LLMs as operating systems.arXiv preprint arXiv:2310.08560, 2023.https://arxiv.org/abs/2310.08560.
• Schmidgall et al. (2025)Samuel Schmidgall, Yusheng Su, Ze Wang, Ximeng Sun, Jialian Wu, Xiaodong Yu, Jiang Liu, Michael Moor, Zicheng Liu, and Emad Barsoum.Agent laboratory: Using LLM agents as research assistants.InFindings of the Association for Computational Linguistics: EMNLP, 2025.https://aclanthology.org/2025.findings-emnlp.320/.
• Shanahan (2006)Murray Shanahan.A cognitive architecture that combines internal simulation with a global workspace.Consciousness and Cognition, 15(2):433–449, 2006.10.1016/j.concog.2005.11.005.
• Shanahan (2008)Murray Shanahan.A spiking neuron model of cortical broadcast and competition.Consciousness and Cognition, 17(1):288–303, 2008.10.1016/j.concog.2006.12.005.
• Shinn et al. (2023)Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao.Reflexion: Language agents with verbal reinforcement learning.InAdvances in Neural Information Processing Systems, 2023.https://arxiv.org/abs/2303.11366.
• Snell et al. (2024)Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar.Scaling LLM test-time compute optimally can be more effective than scaling model parameters.arXiv preprint arXiv:2408.03314, 2024.https://arxiv.org/abs/2408.03314.
• Toledo et al. (2025)Edan Toledo, Karen Hambardzumyan, Martin Josifoski, Rishi Hazra, Nicolas Baldwin, Alexis Audran-Reiss, Michael Kuchnik, Despoina Magka, Minqi Jiang, Alisia Maria Lupidi, Andrei Lupu, Roberta Raileanu, Kelvin Niu, Tatiana Shavrina, Jean-Christophe Gagnon-Audet, Michael Shvartsman, Shagun Sodhani, Alexander H. Miller, Abhishek Charnalia, Derek Dunfield, Carole-Jean Wu, Pontus Stenetorp, Nicola Cancedda, Jakob Nicolaus Foerster, and Yoram Bachrach.AI research agents for machine learning: Search, exploration, and generalization in MLE-bench.arXiv preprint arXiv:2507.02554, 2025.https://arxiv.org/abs/2507.02554.
• Venkatraman et al. (2025)Siddarth Venkatraman, Vineet Jain, Sarthak Mittal, Vedant Shah, Johan Obando-Ceron, Yoshua Bengio, Brian R. Bartoldson, Bhavya Kailkhura, Guillaume Lajoie, Glen Berseth, Nikolay Malkin, and Moksh Jain.Recursive self-aggregation unlocks deep thinking in large language models.arXiv preprint arXiv:2509.26626, 2025.10.48550/arXiv.2509.26626.https://arxiv.org/abs/2509.26626.
• Virk et al. (2026)Yuvraj Virk, Zack Edds, Chunqiu Steven Xia, and Lingming Zhang.SwarmResearch: Orchestrating coding agents for open-ended discovery.arXiv preprint arXiv:2607.02807, 2026.https://arxiv.org/abs/2607.02807.
• Wang et al. (2023)Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar.Voyager: An open-ended embodied agent with large language models.arXiv preprint arXiv:2305.16291, 2023.https://arxiv.org/abs/2305.16291.
• Wang et al. (2025)Junlin Wang, Jue Wang, Ben Athiwaratkun, Ce Zhang, and James Zou.Mixture-of-agents enhances large language model capabilities.InThe Thirteenth International Conference on Learning Representations, 2025.https://iclr.cc/virtual/2025/poster/28787.
• Wu et al. (2023)Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang.AutoGen: Enabling next-gen LLM applications via multi-agent conversation.arXiv preprint arXiv:2308.08155, 2023.10.48550/arXiv.2308.08155.https://arxiv.org/abs/2308.08155.
• Xu et al. (2025)Wujiang Xu, Zujie Liang, Kai Mei, Hang Gao, Juntao Tan, and Yongfeng Zhang.A-MEM: Agentic memory for LLM agents.arXiv preprint arXiv:2502.12110, 2025.https://arxiv.org/abs/2502.12110.
• Yamada et al. (2025)Yutaro Yamada, Robert Tjarko Lange, Cong Lu, Shengran Hu, Chris Lu, Jakob Foerster, Jeff Clune, and David Ha.The AI scientist-v2: Workshop-level automated scientific discovery via agentic tree search.arXiv preprint arXiv:2504.08066, 2025.https://arxiv.org/abs/2504.08066.
• Yang et al. (2026)John Yang, Kilian Lieret, Jeffrey Ma, Parth Thakkar, Dmitrii Pedchenko, Sten Sootla, Emily McMilin, Pengcheng Yin, Rui Hou, Gabriel Synnaeve, Diyi Yang, and Ofir Press.ProgramBench: Can language models rebuild programs from scratch?arXiv preprint arXiv:2605.03546, 2026.https://arxiv.org/abs/2605.03546.
• Yao et al. (2023)Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan.Tree of thoughts: Deliberate problem solving with large language models.InAdvances in Neural Information Processing Systems, 2023.https://arxiv.org/abs/2305.10601.
• Zhang et al. (2025)Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, and Jeff Clune.Darwin Gödel machine: Open-ended evolution of self-improving agents.arXiv preprint arXiv:2505.22954, 2025.https://arxiv.org/abs/2505.22954.
• Zhang et al. (2026)Yifan Zhang, Yunheng Zou, Shaokun Zhang, Jian Hu, Hao Zhang, Binfeng Xu, Jan Kautz, and Yi Dong.Agora: Git as shared memory for collective autoresearch.arXiv preprint arXiv:2609.18094, 2026.https://arxiv.org/abs/2609.18094.
• Zhao et al. (2024)Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong-Jin Liu, and Gao Huang.Expel: Llm agents are experiential learners.InProceedings of the AAAI Conference on Artificial Intelligence, 2024.https://doi.org/10.1609/aaai.v38i17.29936.
• Zhou et al. (2024)Andy Zhou, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, and Yu-Xiong Wang.Language agent tree search unifies reasoning, acting, and planning in language models.InInternational Conference on Machine Learning, 2024.https://proceedings.mlr.press/v235/zhou24r.html.
• Zhuge et al. (2024)Mingchen Zhuge, Wenyi Wang, Louis Kirsch, Francesco Faccio, Dmitrii Khizbullin, and Jürgen Schmidhuber.GPTSwarm: Language agents as optimizable graphs.InInternational Conference on Machine Learning, 2024.https://proceedings.mlr.press/v235/zhuge24a.html.

Contents

ContentsSupportsPageARelated WorkABExperimental Setup DetailsSec.3.1BB.1Benchmarks, Scoring, and ModelsSec.3.1B.1B.2ProgramBench Task SubsetsSec.3.1B.2B.3Baseline Continuation ProtocolSec.3.1B.3B.4Run Corpus for the Trace AnalysesSecs.3.2,3.4,3.5B.4CControlled Tests of Substrate PropertiesSec.3CC.1Persistence: Hidden RulebookSec.3.1C.1C.2Branchability: Hidden MazeSec.3.1C.2C.3Attribution: Retracted EvidenceSec.3.1C.3C.4Scope of the Controlled TestsSec.3.1C.4DBenchmark Performance DetailsSec.3.2DEAutoResearch: Additional DetailsSec.3.3EE.1Common SetupSec.3.3E.1E.2Residual Matrix TransformerSec.3.3E.2E.3Looped TransformerSec.3.3E.3E.4NanoChatSec.3.3E.4E.5Findings Across Research TasksSecs.3.3,4E.5FReuse, Artifacts, and AccumulationSec.3.4FF.1Declared Reuse and Selected-Solution AncestrySec.3.4F.1F.2Persistent Artifact Production and ConsumptionSec.3.4F.2F.3Collaboration WorkflowsSec.3.4F.3GWorker Activity, Coordination, and Design TradeoffsSec.3.5GG.1Worker-Activity Taxonomies, Activity, and Coordination-Tool Use over TimeSec.3.5G.1G.2Worker Episode Outcomes and System HealthSecs.3.5,4G.2G.3Voting Dynamics and Selection TimingSec.3.5G.3G.4Voluntary Abstention and RedundancySec.3.5G.4G.5Selective Inspection of Shared HistorySec.3.5G.5G.6Architectural TradeoffsSec.3.5G.6HGitSwarmWorker PromptsSecs.2,3.1HH.2System PromptSec.2H.2H.5User PromptsSec.3.1H.5

Appendix ARelated Work

Our work lies at the intersection of inference-time search, agent memory, multi-agent coordination, and automated research. These approaches differ in how they preserve intermediate work, support competing lines of exploration, record dependencies, and decide what to investigate next. Table1compares representative systems along these dimensions.

Inference-time search and reflection.Repeated sampling and compute-aware inference allocate additional computation to candidate solutions(Brown et al., 2024;Snell et al., 2024). Tree of Thoughts explores and evaluates alternative reasoning paths(Yao et al., 2023), while Language Agent Tree Search combines tree search with environmental feedback(Zhou et al., 2024). These approaches preserve intermediate states within a search. In contrast,GitSwarmpreserves partial solutions, executable artifacts, and negative results across independently scheduled worker episodes.

Other methods retain information across attempts. Reflexion preserves verbal feedback for subsequent trials(Shinn et al., 2023); ExpeL extracts and retrieves insights from previous tasks(Zhao et al., 2024); and Voyager accumulates reusable executable skills(Wang et al., 2023). MemGPT manages long-term context(Packer et al., 2023), while A-MEM links and updates memories as new information arrives(Xu et al., 2025). These systems establish the value of external memory. Our focus is a shared, versioned contribution history in which independent workers can pursue competing approaches and explicitly declare dependencies across them.

PDR(Madaan et al., 2025)study inference as an iterative improvement process. Their Parallel-Distill-Refine method generates diverse drafts in parallel, distills them into a bounded textual workspace, and refines a candidate over successive rounds. Similarly, Recursive Self-Aggregation (RSA)(Venkatraman et al., 2025)involves sampling multiple (NN) outputs in parallel, curating new contexts by randomly sub-sampling and collectingKKoutputs, andaggregatingthem using an LLM operator. This workflow is then repeated over successive rounds. PDR and RSA allow inference to accumulate information without continually expanding the model’s context. SqueezeEvolve(Maheswaran et al., 2026)follows a similar orchestration.GitSwarmshares the goal of building on earlier computation but uses a different memory model. Rather than repeatedly compressing drafts into a single workspace, it preserves individual contributions in a shared, branchable repository. Independent workers choose which previous results to inspect or extend, while each commit explicitly records its dependencies across branches.GitSwarmalso operates entirely at inference time, whereas Madaan et al. additionally investigate training models to use their iterative improvement operator.

Kim et al.(Kim et al., 2026)extend inference-time scaling to long-horizon coding agents. They summarize each agent trajectory into a structured record of its hypotheses, progress, and failures. These summaries support recursive tournament voting over parallel attempts and sequential refinement through Parallel-Distill-Refine (PDR). LikeGitSwarm, their method allows later computation to benefit from earlier attempts. The difference lies in how that work is preserved and organized. Their approach distills trajectories into compact contexts for selection and subsequent rollouts.GitSwarminstead preserves individual contributions and artifacts in a shared, branchable repository. Workers independently choose which contributions to extend, while each commit explicitly records its dependencies across branches.

Multi-agent coordination.Multi-agent debate improves candidate answers through interaction between model instances(Du et al., 2023), while Mixture-of-Agents aggregates responses across successive model layers(Wang et al., 2025). AutoGen supports configurable patterns of agent conversation(Wu et al., 2023). MetaGPT assigns specialized roles within a prescribed software-development workflow(Hong et al., 2024), and AgentVerse studies configurable teams and collaboration patterns(Chen et al., 2024). Magentic-One uses an orchestrator to assign work and revise plans(Fourney et al., 2024).

GPTSwarm represents agent operations and communication as an optimizable computation graph(Zhuge et al., 2024). Its graph specifies how a multi-agent program executes, whereas ours records how published contributions accumulate over time. Rather than assigning roles or optimizing a communication topology,GitSwarmlets homogeneous workers independently choose whether to explore, repair, verify, integrate, or nominate existing work. Its harness still centrally manages execution and applies deterministic plurality readout.

Version control for collaborating agents.AgentGit introduces version-control operations such as committing, branching, and rollback to agent workflows, supporting recovery and alternative execution paths(Li et al., 2025). CAID uses parallel Git worktrees and branch-and-merge integration for asynchronous software engineering, with a central manager that plans and delegates subtasks(Geng and Neubig, 2026). SwarmResearch also runs coding agents on separate Git branches, but uses a Shepherd Agent to direct their search and adjust parallelism(Virk et al., 2026).

These systems demonstrate how version control can organize parallel agent work. InGitSwarm, the repository instead serves as a persistent substrate for self-directed contributions. Each accepted commit has a physical Git parent and must declare its semantic dependencies throughinformed_by=, including references to work on other branches. Nomination records remain separate from the contribution graph, so evaluating an existing candidate does not alter its ancestry.

Concurrent work: Agora.Agora(Zhang et al., 2026), developed in parallel with our work, also investigates compounding research by self-directed agents over a persistent Git-backed contribution graph. Its workers operate without assigned tasks or a central planner. Contributions retain their dependencies through Git parent relationships, including multiple parents, while searchable frontier views and diversity-aware recommendations help workers navigate the research history.

GitSwarmstudies a closely related design space with a different contribution and selection protocol. It separates each commit’s physical Git parent from mandatory semanticinformed_by=references and selects final candidates through worker nominations and deterministic plurality readout. Our evaluation also examines fixed-answer benchmarks, controlled substrate properties, and sustained GPU-backed research, with separate measurements of declared dependencies, artifact consumption, and selected-solution ancestry. Agora’s extended weight-transfer study instead emphasizes research diversity and independent verification. The two studies provide complementary evidence about repository-mediated collective research rather than a direct performance comparison.

Blackboards and global workspaces.GitSwarm belongs to a long lineage of architectures that coordinate distributed computation through shared state. Classical blackboard systems such as HEARSAY-II allow independent knowledge sources to opportunistically read from and contribute to a common workspace(Erman et al., 1980;Nii, 1986). Global Workspace Theory similarly organizes cognition around multiple specialist processes whose information can gain access to a shared broadcast workspace(Baars, 1988). Shanahan developed computational realizations of this principle in cognitive and neural architectures based on competition and global broadcast(Shanahan, 2006;Shanahan, 2008), andGoyal et al. (2022)brought the idea to modern neural architectures, allowing learned specialist modules to communicate through a capacity-limited shared workspace.

GitSwarm inherits the shared-workspace principle but changes the temporal and structural role of the workspace. Rather than maintaining a transient common state for coordinating computation within a cognitive cycle or neural forward process, GitSwarm preserves an explicit history of contributions across agent episodes. The workspace is durable and branchable, and dependencies between contributions are recorded explicitly, allowing competing lines of work to persist and later recombine. Our focus is therefore not only coordination through shared state, but theaccumulation of reusable computationover long horizons.

Autonomous experimentation and evolutionary search.Karpathy’s AutoResearch repeatedly modifies, trains, and evaluates a NanoChat model in a single-agent loop(Karpathy, 2026). The AI Scientist automates stages from idea generation to paper writing(Lu et al., 2024), while AI Scientist-v2 uses progressive agentic tree search directed by an experiment manager(Yamada et al., 2025). Agent Laboratory organizes literature review, experimentation, and writing into a staged research workflow(Schmidgall et al., 2025).

AlphaEvolve maintains an evaluated population of programs and uses evolutionary selection for algorithm discovery(Novikov et al., 2025). AIRA2combines agentic experimentation, consistent evaluation, and asynchronous multi-GPU execution(Hambardzumyan et al., 2026). These systems demonstrate the value of experimental feedback, persistent candidate pools, and parallel research.

Our question is how independent research episodes can additionally preserve hypotheses, failed experiments, code, and supporting evidence in an auditable contribution graph, without a central agent selecting each next experiment. The research histories in Section3.3illustrate cross-branch architectural synthesis and the later reconsideration of initially rejected results. These observations demonstrate reuse, but do not by themselves establish its causal effect on performance.

Earlier work on autonomous research establishes complementary ways to organize experimental search. AIRA(Toledo et al., 2025)studies how search policies and operators interact in machine learning research, while AI Co-Scientist(Gottweis et al., 2025)uses asynchronous agents and tournament-based refinement to develop scientific hypotheses. The Darwin Gödel Machine(Zhang et al., 2025)maintains an expanding archive of coding agents, empirically validating modifications that improve the agents themselves. ARTS(Juneja et al., 2026)uses a central reasoning model to inspect the logs of earlier experiments and choose which node of a search tree to expand, separating weak hypotheses from flawed implementations rather than ranking nodes by score. Because this scientist carries the entire search, ARTS condenses the growing history into short written insights and, in a variant, into the model’s weights via test-time training, and it returns the best validated node.GitSwarmhas no central scientist: independent workers, each starting with a fresh context, retrieve what they need from a shared version-controlled persistent repository that is never summarized or pruned, can combine separate branches into a single contribution, and select the final solution through decentralized nomination when no reliable validation score exists.GitSwarminstead keeps the worker model fixed and accumulates contributions to an external research task. Its repository preserves competing experiments, including unsuccessful ones, with explicit dependencies between contributions.

Meta-Harness(Lee et al., 2026)searches over the code of LLM harnesses with a single coding-agent proposer that reads the source code, scores, and execution traces of all prior candidates from a filesystem. LikeGitSwarm, it exposes the full, uncompressed history for selective retrieval rather than summarizing it. Its search, however, proceeds in sequential iterations, and every stored candidate is a complete harness, evaluated on a fixed search set and logged in a predefined per-candidate directory.GitSwarmcontributions can instead be bounded partial work that later workers extend, providing a higher branching factor and thus allowing more exploration. Branches and explicit dependencies let many asynchronous workers build on one another concurrently under version control, and beyond a small core layout, workers choose which artifacts to leave.GitSwarmis also applied across program reconstruction, proof search, and architecture research rather than to a single class of artifact.

Evaluating autonomous research.MLAgentBench(Huang et al., 2024), MLGym(Nathani et al., 2025), ResearchGym(Garikaparthi et al., 2026), and AIRS-Bench(Lupidi et al., 2026)provide environments and benchmarks for end-to-end machine learning research. MLGym additionally provides an environment for developing reinforcement learning algorithms for research agents. These works motivate evaluation beyond fixed-answer coding tasks. Our experiments instead examine how independently scheduled workers accumulate code and experimental evidence through shared persistent memory.

Table 1:How related systems organize intermediate work.Representative mechanisms for retaining state, exploring alternatives, recording dependencies, and choosing subsequent work. This is a comparison of system designs, not a performance ranking.##### Comparison by design principles.

Table2compares systems along seven properties relevant to compounding inference: shared memory that persists across agent episodes; durable branches for competing approaches; self-directed work selection without a central task planner; absence of predefined specialist roles; asynchronous workers; explicit dependencies across branches; and dependency records that distinguish the physical starting state from other sources used by a contribution.

These properties are not independent, nor are they a performance ranking. In particular, systems can provide several of them through different mechanisms. We compare the protocols described in the cited papers, rather than every configuration their underlying frameworks could support.

Table 2:Design properties of related systems.Shared memory persists across worker episodes; branching preserves competing contributions; self-direction means workers choose their next task rather than receive assignments. Cross-branch dependencies explicitly connect contributions from different branches. Separate sources means the physical starting state is recorded apart from additional semantic sources.✓\checkmark: part of the reported design;∼\sim: partial or configuration-dependent; –: not part of the reported protocol.

Relation to repository-based collaboration.

CAID and SwarmResearch use Git branches to support parallel work, but organize that work through a central manager or Shepherd Agent. The former delegates dependent software engineering subtasks; the latter chooses starting points and steers exploration.GitSwarminstead lets each worker inspect the repository and independently choose what contribution to make.

Agora is closer in its control model. Its workers also choose their own research directions without assigned roles or a central planner. Both systems preserve intermediate research in a Git-backed contribution graph, including alternative approaches and unsuccessful experiments. Their dependency tracking and selection mechanisms differ. Agora represents dependencies through Git parent relationships, including multiple parents, and provides evidence-aware and diversity-aware views of the research frontier.GitSwarmseparates the physical Git parent from additional mandatoryinformed_by=references, allowing a worker to build on one branch while explicitly citing discoveries from others. Workers nominate candidate solutions, and the harness applies deterministic plurality readout.

These differences motivate distinct analyses. We measure declared cross-branch dependencies, trace-visible artifact consumption, and the transitive ancestry of selected solutions across programming and proof benchmarks. Our sustained research experiments additionally illustrate architectural synthesis and the later reuse of negative experimental results.

Appendix BExperimental Setup Details

This appendix complements Section3.1with benchmark, scoring, and model details (AppendixB.1), the ProgramBench task subsets (AppendixB.2), the baseline continuation protocol (AppendixB.3), and the run corpus underlying the trace analyses (AppendixB.4).

B.1Benchmarks, Scoring, and Models

IMOProofBench-Advanced.

The 30 proof-style problems of IMOProofBench-Advanced(Luong et al., 2025)include problems sourced from high-school level mathematical competitions as well as novel problems designed by mathematicians. All 30 problems are evaluated. Candidate proofs are graded using the benchmark’s proof-scoring protocol(Luong et al., 2025); each solution receives a score in{0,1,6,7}\{0,1,6,7\}. In the scaling analysis (Figure17), a proof counts as fully correct when it receives the full score of 7.

With Codex (GPT-5.5-high) workers,GitSwarmis compared with a single Forced Codex (GPT-5.5-high) agent; with Gemini-3.1-Pro workers, it is compared with Gemini-3.1-Pro wrapped in the mini-SWE-agent harness(Lieret and Jimenez, 2025). The proof baselines also include synchronized independent best-of-five trajectories (Section3.1).

ProgramBench.

Each ProgramBench(Yang et al., 2026)task provides documentation and an execute-only reference program; the solver must construct a self-contained codebase whose compiled executable matches the reference on hidden tests. The benchmark score is the fraction of hidden cases on which the candidate’s behavior matches the reference. TheGitSwarmCodex workers use GPT-5.5 at high reasoning effort, theGitSwarmGPT-5.5 workers use the serving endpoint’s default reasoning effort, and the Forced Codex agent uses GPT-5.5 at high reasoning effort. The development and evaluation task subsets are described in AppendixB.2.

Architecture research tasks.

For each research task of Section3.3we report task-specific validation metrics, research wall-clock budgets, worker and GPU allocations, and comparison conditions. The common research setting and reporting protocol are given in AppendixE.1, and the task specifications in AppendixE.

B.2ProgramBench Task Subsets

Development tasks.

We use nine ProgramBench tasks during development, including for the design-tradeoff comparisons (Table13):wfxr__csview,johanneskaufmann__html-to-markdown,altdesktop__i3-style,elkowar__pipr,tomnomnom__gron,gabotechs__dep-tree,rvben__rumdl,sigoden__argc, andjohnkerl__miller. None of them is part of the evaluation subset.

Evaluation subset.

The 50 evaluation tasks are drawn from the tasks that remain after excluding the nine development tasks and six further tasks. The subset is selected by stratifying jointly on several dimensions, including implementation language (26 Rust, 11 Go, 8 C, 3 C++, 1 Haskell, and 1 Java task), benchmark difficulty labels (7 easy, 30 medium, 4 hard, and 9 unlabeled), test-suite size (10 tasks from each quintile), and runtime (balanced across quartiles). Remaining ties are broken deterministically with a fixed hash. Table3lists the 50 tasks.

Table 3:ProgramBench evaluation subset.The 50 evaluation tasks, grouped by implementation language. Identifiers have the formowner__repository.commit.

B.3Baseline Continuation Protocol

Natural-stop continuation for Forced baselines.

For the Forced baselines, we use natural stopping as the budget knob: every time the agent stops naturally, we resume the session by prompting it withKeep working.... Intermediate checkpoints of the Forced agent are graded to obtain a compute-scaling curve.

B.4Run Corpus for the Trace Analyses

Proof runs.

Because GPT-5.5 saturates the benchmark at relatively small compute budgets (Section3.2), the cross-budget proof scaling discussion emphasizes the Gemini-3.1-Pro runs. The IMOProofBench-Advanced trace analyses of dependencies, artifact access, worker activity, and coordination (Sections3.4–3.5; AppendicesFandG) use the Gemini-3.1-ProGitSwarmproof runs.

ProgramBench runs.

The ProgramBench trace analyses cover the four scaling budgetsB=100B=100–500500on the 50-task evaluation subset.

Appendix CControlled Tests of Substrate Properties

This appendix gives the full task definitions, interfaces, treatments, settings, and results for the three controlled tasks summarized in Section3.1. Each synthetic task isolates a setting in which one property of the shared substrate (persistence, branchability, or attribution; Section2.1) should reduce a particular form of repeated work. All experiments use Gemini-3.1-Pro and three random seeds; AppendixC.4discusses the scope of these tests. Symbols such asBB,CC,DD, andkkare local to the synthetic tasks; in particular,BBdenotes the number of workers in a synthetic run, andCCin the Retracted Evidence task counts candidate conclusions, not the concurrency limit of Section2.3. The worked examples below use short readable IDs; experimental instances use random opaque IDs and randomize their display order for each worker.

C.1Persistence: Hidden Rulebook

Task generation.

The hidden rulebook is a collection of records with opaque IDs. A record is either a fact containing an integer, or a unary rule containing the ID of one earlier record and an addition or multiplication to apply modulo997997. For each of thePPrequested targets, the generator creates an independent chain ofDDrules ending in one fact. Solving all targets therefore requires exactlyQ=P⁡(D+1)Q=P(D+1)relevant records. The remainder of the rulebook consists of disconnected distractor facts and rules. A worker initially sees only the target IDs. Inspecting a rule reveals its predecessor’s ID but not that predecessor’s contents, so each chain must be discovered one record at a time (Figure11).

Visibleinitially:targett7

inspect(t7)->multiplypredecessorr4by3

inspect(r4)->add5topredecessorf2

inspect(f2)->fact7

Evaluation:f2=7->r4=12->t7=36

Independent:worker0:t7,r4worker1:t7,r4(repeats)

Persistent:worker0:t7,r4worker1:f2(continues)

Figure 11:Hidden Rulebook example.A worker cannot queryf2until an earlier query reveals its ID. Shared observations let a later worker continue the chain instead of rediscovering its prefix.

Interface and treatments.

inspect(record_id)costs one query and returns either a fact value or a rule’s predecessor, operation, operand, and modulus. The harness appends each successful result to the current worker’sobservations.jsonl.bash(command)lets a worker inspect filesystem memory and write notes, andsubmit_answers(answers)records its target–value map and ends the episode. We compare shared persistent memory against two independent conditions. In the shared persistent treatment, workers run sequentially and each new worker can read the completed directories of all previous workers, which are mounted read-only. In the independent treatments, every worker receives an isolated directory. Target order is independently permuted for every worker in all treatments, preventing a fixed presentation order from determining which chains are explored first.

Experimental settings.

We sweep the number of targetsPP(withD=4D=4) and the chain depthDD(withP=4P=4). The shared persistent condition usesk=10k=10queries per worker and enough sequential workers to provide approximatelyQQqueries in total. We include two deliberately over-budget independent baselines: two relatively long workers (B=2B=2), and many short workers withk=4k=4queries each. Their aggregate budget is approximately4​Q/3>Q4Q/3>Q, so their lower coverage cannot be explained by having too few total queries. Table4gives the exact settings.

Table 4:Hidden Rulebook settings.Entries in the final three columns give(B,k)(B,k): the number of workers and queries per worker.

Metric.

We reportrelevant-record coverage: the number of distinct queried records that belong to a requested target chain, divided byQQ. The oracle computes this quantity from the union of all workers’ observations; correctness of the workers’ final submissions is not required for the coverage metric.

Results.

Figure12shows that shared persistent memory maintains high relevant-record coverage as the number of targets or the dependency depth increases. The independent baselines’ coverage stays roughly flat but well below shared memory as the number of targets grows (about 70–75% forB=2B=2and 20–23% fork=4k=4) and drops with dependency depth, despite their larger aggregate query budget. Persistence therefore reduces the rediscovery cost of extending sequential investigations.

Figure 12:Persistence reduces rediscovery.Relevant-record coverage in Hidden Rulebook as (a) the number of targetsPPand (b) the chain depthDDgrow, for shared persistent memory and two independent baselines with larger total query budgets. Mean over three seeds; bands:±1\pm 1SD.

C.2Branchability: Hidden Maze

Task generation.

The maze is a randomly generated rooted tree of maximum depthDD. During breadth-first generation, each room at depth less thanDDsamples between zero andNNchildren; we retain trees that reach depthDDand place the treasure at a uniformly sampled deepest leaf. Room and exit IDs are opaque. A worker never sees the tree globally: its current state reveals only the current room, its visible exits, the exit returning to the preceding room, and whether the room is a dead end or contains the treasure. A move through any visible exit costs one step, including moves that retrace previously explored routes. Thus a worker may backtrack physically, but doing so also spends its limited budget (Figure13).

Hiddenmaze:Branch-nativememory:

root--e1-->A--e2-->Bmemory/root/

||branch_0000/endpointB

‘--e5-->C|branch_0001/dead-endtrial

|--e3-->deadend

‘--e4-->...-->treasure

flatworker:root->A->B->e4(replaysprefix)

resumingworker:B->e4(restoresB)

Figure 13:Hidden Maze example.A restorable endpoint lets a new worker explore another exit fromBwithout paying again for the path from the entrance. Nested directories record which endpoint each trajectory extended.

Interface and memory treatments.

Every worker has a restrictedbash(command)tool and a writablecurrent_state.json. The callmove(exit_id, rationale)moves from the room stored in this file, costs one step, and replaces it with the new room state.yield_worker(summary)ends the episode. Where a treatment makes saved states restorable, a checkpoint can be copied tocurrent_state.jsononly before the first move; afterward, the worker follows one continuous physical trajectory. The harness validates every restored checkpoint and commits the final state after the episode, so workers cannot fabricate states or modify previous work. We compare three filesystem memory organizations:

• •Flat persistent memorystores all earlier moves inmemory/paths.jsonl, but every worker starts at the entrance and no saved state is restorable, so a worker must physically retrace any known prefix.
• •Unstructured resumable memorystores endpoint files undermemory/nodes/; a worker can copy one tocurrent_state.json, but its prompt does not mention this possibility.
• •Branch-native memorystores every completed trajectory as a child directory beneath the endpoint it resumed, forming a tree of checkpoints. Its prompt explicitly asks the worker to inspect the tree, select an endpoint, and restore itscheckpoint.jsonbefore continuing exploration. Selecting a leaf continues a branch, while selecting an endpoint with existing children creates a sibling branch. Branch-native memory thus makes both earlier endpoints and their relationships directly available for subsequent exploration.

Previous memory is read-only in all treatments.

Experimental settings.

We sweep maze depth and maximum branching factor;kkdenotes the move budget per worker. In the depth sweep, we fixN=4N=4and useD∈{4,6,8,10}D\in\{4,6,8,10\}, with(B,k)(B,k)equal to(2,6)(2,6),(3,9)(3,9),(4,12)(4,12), and(4,15)(4,15), respectively. In the branching-factor sweep, we fixD=6D=6, useN∈{2,4,6,8}N\in\{2,4,6,8\}, and set(B,k)=(3,9)(B,k)=(3,9). In every condition,k>Dk>D, so an individual worker can reach the treasure by choosing the correct route; no treatment is made impossible by its step limit.

Metrics.

We record treasure discovery, total steps to the treasure, checkpoint restorations, and therepeated-move fraction: the fraction of steps whose directed room–exit pair was already traversed by an earlier step.

Results.

Figure14shows that branch-native memory substantially reduces repeated traversal relative to flat persistent memory across the tested depth and branching-factor regimes; results for unstructured resumable memory are not shown. Restoring a previously reached endpoint allows subsequent workers to explore another branch without paying again for its known prefix.

Figure 14:Branch-native memory reduces repeated traversal.Repeated-move fraction in Hidden Maze for branch-native and flat persistent memory as (a) maze depthDDand (b) branching factorNNgrow. Lines: mean over three mazes; open markers: individual mazes.

Caveat.

This experiment compares practical memory interfaces rather than changing branchability alone: the branch-native treatment also makes checkpoint restoration explicit in the worker prompt.

C.3Attribution: Retracted Evidence

Task generation.

The archive contains source notes, derived evidence notes, and candidate conclusions. A source note states a numerical claim such as “specimen Iona has baseline resonance 22.” A derived note names a specimen and metric, applies a signed numerical adjustment to one earlier claim, and reports the result. Its true parent is the unique preceding note whose specimen, metric, and value make this calculation correct. A conclusion states that one candidate answers one question and names the claim required to support it. An artifact is valid only if its producer and every artifact in its ancestry remain valid. We choose one intermediate artifact to be authored by a retracted laboratory and attach multiple downstream branches to it; all conclusions below it become invalid. For each of thePPquestions, exactly one of theCCcandidate conclusions has a fully clean lineage (Figure15).

s0:LabUmberreportsbaselineresonance=22

|

|--s1:LabAmberapplies+6,obtainingspectralindex=28

|‘--...-->c1:spectralanswerA[valid]

|

‘--p0:LabCedarapplies+4,obtainingvalue=26

‘--r1:LabSaffronapplies-11,obtainingvalue=15

|LabSaffronisRETRACTED

|--...-->c2:spectralanswerB[invalid]

‘--...-->c3:bindinganswerX[invalid]

Decoysreportnearbyvalues(19,25,31,...),butonlyonevalue

makeseachstatednumericaltransformationcorrect.

Figure 15:Retracted Evidence example.Retraction propagates through ancestry: every conclusion depending onr1is invalid even when its own author is clean.

Interface and treatments.

The initial catalog always shows each artifact’s ID, type, and title; conclusion rows also show their question ID and candidate answer. In the attribution treatment, each row additionally contains its producer and immediate parent IDs. In the no-attribution treatment, these fields are absent and workers must recover the lineage from the numerical statements. The prompt does not name the treatment.

read_artifacts(artifact_ids, rationale)returns the full text of the requested artifacts and charges one read per artifact.submit_answers(answers)submits one candidate for every question, andyield_worker(summary)ends an episode. Four workers run sequentially; all artifact texts read by earlier workers and all earlier submissions remain visible. Thus both treatments have persistent observations: they differ in whether explicit attribution (dependency) metadata is available, not in whether their accumulated observations persist.

Difficulty controls and settings.

Lineage depthLLis the number of ancestry levels ending at a conclusion. Semantic ambiguityAAis the number of plausible parent notes with the required specimen and metric at a parent-selection step; only one of them has the required value. Fan-outFFis the number of downstream branches below the retracted intermediate artifact. All conditions useP=4P=4questions,C=2C=2candidates per question, four workers, and three seeds. We sweep one factor at a time (Table5). The per-worker read budget isk=⌈|𝒜|/4⌉k=\lceil|\mathcal{A}|/4\rceil, where|𝒜||\mathcal{A}|is the generated archive size, so the combined budget of the four workers is sufficient to read the complete archive in principle.

Table 5:Retracted Evidence settings.One factor is varied at a time. The per-worker artifact-read budgetkkis set to⌈|𝒜|/4⌉\lceil|\mathcal{A}|/4\rceil, where|𝒜||\mathcal{A}|is the generated archive size, so the four workers can read the complete archive in principle.

Metric.

The primary metric is the fraction of unique archive artifacts read before the first exact submission. It measures the information-gathering cost of identifying valid conclusions, and distinguishes the ability to follow recorded dependencies from the cost of reconstructing those dependencies from content.

Results.

Figure16shows that explicit attribution reduces the fraction of the archive workers must inspect at every tested lineage depth, semantic ambiguity, and downstream fan-out level, with the gap widening with lineage depth. Recorded dependency metadata allows workers to follow and invalidate affected lineages without reconstructing every dependency from artifact contents.

Figure 16:Attribution reduces lineage reconstruction.Fraction of the archive read before the first exact submission in Retracted Evidence, with and without attribution, as (a) lineage depthLL, (b) semantic ambiguityAA, and (c) fan-outFFgrow. Mean over three seeds; bands:±1\pm 1SD; dashed line: about one worker’s read budget.

C.4Scope of the Controlled Tests

These experiments examine three distinct costs: rediscovering prior observations, retraversing previously explored states, and reconstructing dependencies between artifacts. They provide controlled illustrations of why persistence, branchability, and attribution may be useful for compounding inference. They do not establish that any individual property causesGitSwarm’s benchmark improvements (Section4). Such a claim would require interventions on the corresponding property within the full system while controlling for changes in compute, worker behavior, and the remaining substrate capabilities.

Appendix DBenchmark Performance Details

This appendix complements Section3.2with the IMOProofBench-Advanced scaling figure (Figure17) and additional detail on both benchmarks. We evaluate both final performance and how performance changes as inference compute increases. The worker budgetBBis the controlled system-level knob, while recorded input and output tokens provide model-level measures of the computation that was actually consumed. Benchmark protocols, scoring, and the baseline continuation protocol are described in AppendicesB.1andB.3.

IMOProofBench-Advanced.

Figure17shows the proof scaling curves for the plotted configurations. Proof construction follows the same broad trend as ProgramBench, but with more run-to-run variation and earlier saturation, whereas program reconstruction continues to benefit from larger budgets. The configuration differences among the proof runs, which make these cross-budget curves descriptive rather than a controlled estimate of the effect of worker count (Section3.2), are listed in AppendixB.4.

Figure 17:IMOProofBench-Advanced proof scaling.Problems solved (7/7) against mean input (a) and output (b) tokens per problem forGitSwarmwith Gemini-3.1-Pro and base (tool-calling) GPT-5.5-high workers, and for Forced Codex and Forced GPT-5.5, shown only in (b) for lack of input telemetry. Gemini points: mean of three judge passes.

Appendix EAutoResearch: Additional Details

This appendix complements Section3.3with the common research setting (AppendixE.1), the precise task specifications and compared configurations, full-size hill-climbing figures, and the detailed research records of the Residual Matrix Transformer (AppendixE.2) and Looped Transformer (AppendixE.3) runs, including the Looped Transformer’s semantic research graph. It also gives the NanoChat comparison caveats (AppendixE.4) and observations that hold across the three tasks (AppendixE.5).

E.1Common Setup

Research setting.

In each of the three architecture-improvement tasks, the system is given a description of an initial transformer architecture and a fixed number of GPUs, and is instructed to make architectural modifications and hill-climb on a given metric. The focus is on meaningfully interesting architectural modifications rather than minor tweaks and hyperparameter changes. Workers start from an existing implementation and a task-specific research objective, independently propose modifications, implement candidate designs, run experiments, and use previous results to guide subsequent work.

Resource coordination.

Unlike mathematical proofs or program reconstruction, these tasks require coordinating expensive experiments under limited computational resources. Workers must coordinate not only on architecture design but also on resource management: which worker uses how many GPUs to run its experiments, and which experiments to prioritize when resources are constrained. Workers submit training and evaluation jobs through a SLURM scheduler and share a fixed GPU allocation (Section3.3), resembling a typical research group pursuing architecture research. Their code, experimental results, and research notes persist in the repository, allowing other workers to inspect and extend previous work.

Evaluation and reporting.

We evaluate progress through the best objective value attained over research time and, where available, held-out evaluations of the resulting architectures. Because the objective, starting architecture, research budget, and comparison conditions differ across tasks, we report each task separately rather than aggregating the outcomes into a single research performance score.

E.2Residual Matrix Transformer

E.2.1Task Details

Architecture.

The Residual Matrix Transformer (RMT;Mak and Flanigan, 2025) replaces the transformer’s residual vector with an outer-product memory matrix: each layer retrieves its input from the matrix through learned read keys and stores its output back as outer products of learned write keys and values. This lets the residual stream be scaled independently of parameters and compute.

Task specification.

Starting from the authors’ JAX implementation, the swarm must develop an architecturally improved RMT that retains a matrix-valued residual stream and has at most 350M parameters, trained from scratch on a supplied 6.5B-token OpenWebText stream. The search metric is next-token cross-entropy on the 4,873-example protected development set (512 context tokens, one withheld target token); the reference is a 305M RMT trained on 1.3B tokens (development loss 3.158). Final held-out losses, such as the reference’s 3.147, come from a separate held-out evaluation. The task explicitly prioritizes fundamental architectural changes over hyperparameter or configuration tuning.

Compared configurations.

Besides the two 12-workerGitSwarmconfigurations with 8 or 4 GPUs, the single-agent direct GPT and Codex baselines use the same model (GPT-5.6-sol at xHigh reasoning) and the same 72-hour budget on one eight-H200 node. We also examine aGitSwarmrun seeded with earlier incumbents (AppendixE.2.4). Figure4(a) shows the research trajectories.

E.2.2Final Architectures and Idea Families

Final architectures.

BothGitSwarmruns improve on the reference within its parameter cap and training budget. The 8-GPU run’s final model combines six mechanisms (Table6): three general transformer changes (removing a depth-dependent attention scaling, tied embeddings, and a SwiGLU feed-forward layer) and three that exploit the matrix memory (routing across attention heads, wider attention, and mixing in the memory states of recent tokens). The 72-hour submission (dev 2.909, held-out 2.890) uses rank-32 attention; the best model after the extension (dev 2.894) widens it to rank 64 (AppendixE.2.4). The 4-GPU run converged on an overlapping but simpler design, tied embeddings, SwiGLU, and a deeper 32-layer stack, with a held-out loss of 2.894.

How the baselines’ gains differ.

The baselines’ gains were of a different kind. Direct GPT trained longer (3.0B tokens) and added an auxiliary output decoder, and Codex reached 2.690 mainly by training for 10.1B tokens, from which about three quarters of its gain came.GitSwarm’s gains, by contrast, come entirely from architectural changes at the reference training budget, half of them specific to the RMT’s matrix memory, which is the kind of change the task asks for.

Table 6:Architectural mechanisms in the bestGitSwarmRMT model (8-GPU run).

Ideas tried.

Table7lists the 19 idea families explored by theGitSwarmRMT run over the 72-hour run and its extension, with their outcomes. The families range from standard transformer components (gated MLPs, embedding tying, attention normalization, positional schemes, differential attention) to ideas specific to the matrix memory (routing along its axes, normalizing it, changing how layers read from and write to it, mixing it over time). Six families were incorporated into the final model, one led the frontier and was superseded, two produced gains that did not survive combination with the leader, two remained inconclusive at full size, seven were refuted, and one consisted of controls. The single-agent baselines narrowed much earlier: Codex opened no new idea threads after 26.5 hours, and direct GPT spent 68% of its GPU time on a single family.

Negative results.

The 69 negative commits (58% of the 120) are ideas that their authors published as not beating their control or the current best model. They were not discarded: the roughly 30% of them later cited as evidence by other workers compares with 84% of positive commits.

Table 7:Idea families explored by theGitSwarmRMT run: number of commits, positive/negative commits as labelled by their authors, and outcome. Family names follow the run logs: the “cross-rank attention router” is the cross-head router of Table6, and “rank widening” corresponds to wider attention. The family assignment covers 119 of the 120 commits, and its positive/negative split (48/71) differs slightly from the 69 negative commits reported in Section3.3.

E.2.3Reuse and Cross-Lineage Inheritance

Concentrated reuse.

Reuse was highly concentrated. The first durable improvement, a correction to the reference code found within the first hour, is an ancestor of 102 of the 120 commits, and ten commits receive half of all citations.

Reuse of a failure.

The most consequential reuse was of a failure. A worker tried letting each token see the previous token’s memory state, and it failed. 49.5 hours later, another worker cited this failure as evidence that longer look-backs were still unexplored and built a mixer over several earlier tokens that succeeded; a third worker carried it into the 72-hour submission.

Cross-lineage inheritance.

Although the final model’s code descends through a single chain of eight commits, only two of its six mechanisms were first written on that chain. The other four (SwiGLU, the head router, wider attention, and the temporal mixer) were developed on side branches by other workers and ported into the chain (Table8). Other branches contributed evidence without code, for example controls used to measure a change, or a competing design that a later step had to beat. Counting this cited evidence yields the 24-commit, 24-worker dependency set reported in Section3.3.

Table 8:Where the final RMT model’s mechanisms were first written, and how they reached the solution path.

E.2.4Solution Path and Cross-Pollination Run

Semantic research graph.

Figure4(b) condenses the run’s commit history into a semantic graph of 69 nodes. Research steps are ordered by time. The thick green line is the lineage of the best model; blue results held only on small (∼\sim46M) proxies and green results at full size (305M). Red and orange nodes are groups of attempts tested on top of the leader of the time and refuted or stalled, respectively; grey edges show reused code or evidence, and the purple edge marks a commit that generalizes an earlier failure. Ringed nodes are the 72-hour submission and the best model after the extension.

How the final architecture emerged.

Early workers screened many ideas in parallel on small proxy models. The eight commits on the lineage of the best model were:

• •Depth fix (0.6 h, small proxy).Removed a scaling quirk in the reference code. Nine attempts made while it was the leader were refuted (positional schemes, attention normalization, memory addressing and routing).
• •Tied embeddings (1.8 h, proxy).Freed parameters for the feed-forward layers. Write gating and alternative update rules tried while it led failed.
• •+ SwiGLU (5.9 h, proxy).Ported from a parallel branch; memory normalization and depth reallocation tried on it stalled.
• •First full-size model (11.8 h, loss 2.962).The combination validated at 305M. It attracted the largest wave of experiments: ten families were tried on it and failed or stalled, and a side branch using differential attention briefly overtook it.
• •Head router (34.6 h, 2.934).Developed on a side branch; it overtook the differential-attention line, which led once more (50.7 h) before being superseded.
• •Wider attention (53.1 h, 2.924).Also ported from a side branch.
• •Temporal memory mixer (65.9 h, 2.909; held-out 2.890).The 72-hour submission, built from the reused single-token failure described above. Eight variations of the mixer tried on top of it were all rejected.
• •Even wider attention (98.7 h, 2.894).The best model after the extension.

Cross-pollination run.

The seeded run of Section3.3is a new 72-hourGitSwarmrun started from the best models of three completed runs (about 220 prior research-hours in total): the 8-GPU run above (2.909, with the temporal mixer), the 4-GPU run (2.926, with a deeper stack), and a GPT-5.5 High run (2.989). Its gains came from combining the seeds: after 26.7 hours it added the 8-GPU run’s head router to the 4-GPU model (2.905), and an hour later it moved the 4-GPU run’s deeper stack onto the 8-GPU model (2.898). The GPT-5.5 seed was used only indirectly, through a negative result that cited it. The run was heavily rate-limited by a shared API quota, so its pace is not comparable to the original runs.

E.2.5Findings about the Research Process

• •*Small-scale screening was informative early and misleading late.*During the 72-hour run, 15 of 17 ideas promoted from the small proxy to full size helped; in the extension, only 1 of 8 did, and several ideas reversed sign at full size.
• •*Gains measured in isolation often vanished when combined with the leader.*For example, a memory normalization that helped the plain model hurt the best model.
• •*Noise matters.*A seed replication moved loss by 0.010, comparable to several of the later steps on the solution path.

E.3Looped Transformer

E.3.1Task Details

Architecture.

The Looped Transformer task uses Huginn(Geiping et al., 2025), a depth-recurrent language model that splits the network into a prelude, a weight-tied recurrent core, and a coda. The prelude embeds the input, the core is iterated a variable number of times with the prelude output re-injected at every iteration—an adapter mixes the current state with the encoded input—and the coda decodes the final latent state, so test-time compute can be scaled by unrolling more iterations instead of generating more tokens.

Task specification.

Starting from the authors’ official code, scaled to a∼\sim308M-parameter reference (1,024-token context, eight recurrences), the swarm must develop an architecturally improved model that keeps genuine weight-tied recurrent-depth computation, has at most 350M unique parameters, and is trained from scratch with the reference’s token budget on the same 6.5B-token OpenWebText stream as the RMT task (AppendixE.2.1). The metric is the withheld next-token loss on the 4,873 protected-development 1,024-token contexts, evaluated at exactly eight recurrences (reference 3.265); we do not yet report a held-out evaluation for this task.

Protocol and compared configurations.

Candidates are developed on a ladder of smaller models (52M, 124M, 188M) before full-size training.GitSwarm(12 workers), direct GPT and Codex all use GPT-5.5 High with a 48-hour budget on one eight-H200 node; the runs were still in progress at the time of writing (26 of 48 hours). Figure5(a) shows the research trajectories.

E.3.2Final Architecture and Idea Families

Final architecture.

The best model differs from the reference in one place: the linear adapter that re-injects the input at every iteration is replaced by a small gated feed-forward network. Because this adapter runs at every recurrence, it is the component most specific to looped models, and the change adds 27M parameters (8.7%). The parameter-matched control of Section3.3, trained with the reference’s size, checks that the gain is not simply extra capacity. The baselines instead added signals to the recurrent state (a learned per-iteration embedding for direct GPT; input anchors and step signals for Codex), which helped direct GPT on smaller models but not at full size; neither baseline has yet beaten the reference.

Ideas tried.

Table9lists the twelve idea families of the 395 architectural experiments made by the GPT-5.5GitSwarmrun in its first 26 hours, with their outcomes: variants of the adapter, a gate on the recurrent state, attention to the input, parallel specialist feed-forward branches, iteration-dependent control, extra memory, and changes to the core, readout and objective.GitSwarmused 1,222 GPU jobs and all 64 permitted protected evaluations, against 324 and 222 jobs for direct GPT and Codex.

Negative results.

The 170 negative commits amount to 43% of the architectural ones. Two refuted results, a narrower adapter and the recurrent-state gate at 188M, were reused to build the parameter-matched controls.

Table 9:Idea families explored by the GPT-5.5GitSwarmLooped Transformer run in its first 26 hours: architectural commits, commits published as negative by their authors, protected evaluations (128, 512 or 4,873 examples), and outcome. Two of the 64 protected evaluations are not assigned to an architectural family.

E.3.3Steps on the Solution Path

How the final architecture emerged.

Workers first screened all twelve families in parallel on small models; within two hours the recurrent-state gate and the feed-forward adapter were the two leading ideas. After the adapter’s initial rejection was reversed (see the steps below), the two were carried up the ladder side by side: the gate’s advantage vanished at 124M and 188M, while the adapter won at every rung and reached 3.187 at full size after 9 hours (Figure5(b)). Workers then ran capacity controls and built second-generation mechanisms on top of the adapter, such as attention to the input and parallel feed-forward branches, several of which beat it on small models but not yet at full size. Nothing has improved on the best model since 9 hours; the later shift to calibration and diagnostics is described in AppendixE.3.4.

Cross-lineage inheritance.

Unlike in the RMT run, the final model’s code comes almost entirely from one lineage of six commits by six workers; only the first changes code, and the only code imported from elsewhere is a loss-computation fix written for another branch. Other lineages contributed evidence instead: the rival gate’s full-set scores defined what the adapter had to beat, and a shared tool for fast proxy measurements (the second most-cited commit) was used to compare candidates. Counting the commits the best model cites as evidence throughinformed_by=edges, its declared dependencies span 89 commits by 89 distinct workers (98 commits, made between 0.18 and 9.10 hours, if mistyped commit hashes are recovered by unique prefix).

Steps.

The six commits on the lineage of the best model were:

• •Feed-forward adapter (0.4 h, 52M, short run).Written within the first 25 minutes, it replaces the linear re-injection adapter with a gated feed-forward network and imports a loss fix from another branch.
• •Longer run (0.7 h).The same model trained four times longer.
• •Exact 52M rung (2.1 h).A quick 128-example check scored it slightly worse than the reference; its author wrote that it “should not be promoted”, and the idea was nearly dropped.
• •Re-check (3.3 h).About an hour later, another worker re-evaluated the same checkpoint on 512 examples and found it clearly better (−0.067-0.067against the reference); a third confirmed the gain on the full development set and showed that it also beat the leading alternative, the recurrent-state gate.
• •124M rung (5.8 h,−0.055-0.055against the reference).
• •308M, full size (9.1 h, 3.187; reference 3.265).Its commit also cites a side-branch 188M result (−0.111-0.111) that finished while it was training. A parameter-matched control trained later reached 3.212.

E.3.4Findings about the Research Process

• •*Small evaluations misranked models.*128-example evaluations disagreed with the full set on 5 of 12 comparable pairs, and with 512-example evaluations on 15 of 50; a worker measured this itself and the swarm adopted a 128→\rightarrow512→\rightarrow4,873 evaluation funnel.
• •*Gains often failed to transfer across scale.*The recurrent-state gate, the specialist branches and iteration-dependent control all lost their small-scale advantage at larger rungs or against a parameter-matched control.
• •*Workers checked each other.*Besides the reversal of the adapter’s initial rejection (AppendixE.3.3), a later worker overturned a 128-example win for iteration-dependent control, and four workers independently ran parameter-matched controls.
• •*Shared protocols emerged.*A fixed set of proxy contexts was used by 257 commits and parameter matching was discussed in 187; commits that built measurement tools and controls were among the most cited.
• •*Work converged, then shifted to diagnostics.*The share of architectural commits building on the adapter rose from 17% in the first three hours to about 90% after nine, which one worker flagged as over-concentration. After the evaluation budget ran out (20.8 hours), most commits were calibrations and diagnostics, and 128 of 136 abstentions cited duplicate or already-running work.
• •No off-task driftwas observed in this run.

E.4NanoChat

Task and protocol.

Starting from the original NanoChat/autoresearch implementation, workers optimize validation bits per byte (BPB; lower is better), training each candidate from scratch on one GPU under the supplied five-minute training clock and fixed evaluation. We analyzeGitSwarmjob using GPT-6 Astra at high reasoning with 20 live workers sharing 16 GB300 GPUs. Unlike the RMT task, this task does not fix parameter count or training-token exposure: architecture, model capacity, optimization, and training throughput are all research variables. We distinguish the first 24 hours of active allocation from the longer record, which spans 66.84 allocated hours and 78.48 elapsed wall-clock hours because of requeues. Active time includes startup, compilation, and API waiting while allocated; it excludes gaps between allocations.

Results.

Within the first 24 active hours, the run improves from 0.992692 to 0.905235 BPB (8.81%), completing 1,465 successful evaluations of 1,219 distincttrain.pysolutions, plus 175 failed evaluations. The incumbent was measured at 23.67 active hours, or 25.15 elapsed wall hours; a strict 24-wall-hour cutoff instead gives 0.905487. The complete record contains 3,630 successful and 453 failed evaluations, with 2,784 distinct successful solutions. Its best observation is 0.898671 (9.47% below the reference), but this is an extension result, not a 24-hour result or a separately held-out test score.

Architecture at the 24-hour cutoff.

The incumbent retains eight transformer layers but widens the residual stream from 512 to 768 dimensions, uses eight 96-dimensional attention heads, and shortens local attention windows from 1,024 to 512 tokens while retaining full-context layers. It reallocates feed-forward capacity from uniform fourfold expansion to fourfold expansion in the first four layers and eightfold expansion in the last four. A new 2,097,152-row table supplies hashed causal bigram and trigram embeddings, sharing storage between the two feature types. Query/key normalization moves before rotary embedding. These changes are accompanied by activation scaling, optimizer changes and a custom training-head implementation. The resulting model has 1,723.9M parameters versus 50.3M initially; 1,610.6M belong to the lexical table. It trains on 547.9M reported tokens versus the reference’s 728.2M. Thus this is substantive architecture and capacity search, but not an architecture-only, equal-parameter or equal-token comparison.

Ideas tried.

The record contains measured experiments in width/depth allocation, attention head geometry and grouped-query attention, local/global context, gated feed-forward layers, layerwise capacity allocation, normalization and positional schemes, residual topology, hashed lexical representations, embedding sharing, value-injection routing, output bottlenecks and auxiliary supervision. Workers also investigate compiler choices, streamed cross-entropy gradients, memory ownership, optimizer state and mixed precision. This inventory is a selected semantic review rather than an exhaustive partition of every commit. Two controlled comparisons illustrate its architectural content. First, a SwiGLU change that helped at width 512 failed when transferred to width 768: 0.958091 versus 0.951289 for the parameter-matched squared-ReLU parent. Second, at equal total MLP parameter count, early-fourfold/late-eightfold expansion scored 0.932288 versus 0.934069/0.934041 for uniform sixfold expansion; reversing the allocation scored 0.935398. These comparisons retain initialization, optimizer-shape and fixed-time-throughput confounds, but go beyond scalar hyperparameter tuning.

Negative results.

In the first 24 active hours, worker traces confirm 1,258 accepted research commit actions. Of these, 709 (56.4%) are explicitly labelled negative by their authors, and 497 (70.1%) are cited by a later accepted research commit within the same window. Across the complete record, 1,285 of 2,646 accepted research commit actions (48.6%) are negative-labelled, and 982 (76.4%) are subsequently cited. These are published negative conclusions, not failed GPU evaluations; their complement includes inconclusive results and controls, not only positive findings. A citation records declared code or evidence reuse, not necessarily implementation inheritance or causal importance.

Reuse of failure.

The most interpretable chain concerns trigram features. At 2.18 active hours, worker w0273 added a separate 32K-row trigram table and obtained 0.929923, worse than both bigram-only controls (0.929131/0.929700). Enlarging the separate table also failed: 0.924527 versus 0.919483/0.920211. At 23.08 hours, worker w2985 explicitly cited both failures and reused their causal hash while borrowing a shared-table idea from a lagged-pair branch. This avoided an additional large table and its optimizer state. The first shared-table result, 0.905954, did not establish a gain over its strong parent. Nevertheless, worker w3052 enlarged that shared table to produce the 24-hour incumbent, 0.905235. After the cutoff, a lexical cooldown/decay combination reached 0.903842. This is documented reconsideration of a failed design, not proof that trigram features alone caused the eventual gain: the surrounding model, capacity and optimizer also changed.

Cross-lineage inheritance.

The 24-hour incumbent’s physical lineage contains 32 research-result commits, but several mechanisms were developed off that chain. The 96-dimensional head setting and 512-token window came from side branches. The back-loaded MLP was introduced by w0220 and transferred through a smaller-table experiment before w0309 combined it with a 524K-row bigram model. Pre-RoPE query/key normalization came from w0580 and was incorporated by w0678 into an activation-scaled model. The trigram hash and shared-table idea came from separate experiments described above. Source-level checks confirm exact MLP/Block and attention-class transfers for the selected ports, rather than relying solely on matching prose descriptions.

Replication revised a design decision.

The following episodes document experimental judgment within the first 24 active hours, including contributions that did not improve the incumbent. An explicit query/key-normalization epsilon initially scored 0.911027 BPB; worker w0555 repeated the identical source and obtained 0.911918, revising the apparent advantage to an unresolved near-tie with a preference for the simpler inherited normalization. Worker w0580 explicitly cited that failed replication, retained the original epsilon, and instead moved query/key normalization before RoPE, obtaining 0.910114. That ordering subsequently entered the combined architecture. Thus, the earlier evidence informed both a revised conclusion and a later implementation decision; it did not establish that the epsilon change was intrinsically harmful.

Experimental-order verification.

An earlier comparison tested uniform attention-query scaling first (0.906862 BPB), then depth-dependent scaling (0.907103). Worker w1407 investigated whether order could explain this difference by predeclaring the reverse sequence: depth-dependent scaling first (0.908089), then uniform scaling (0.907224), using the unchanged sources. Uniform scaling again won the pair. The worker retained the unfavorable observation and distinguished these paired comparisons from historical aggregate means, which still marginally favored depth-dependent scaling. This investigated an alternative explanation for prior results rather than merely repeating the preferred configuration. It was not a randomized crossover study: training-token exposure, compiler state and measurement time remained uncontrolled, so it did not identify an order effect or establish expected architectural superiority.

Verification supplied reusable controls.

The same verification worker assembled ten measurements of the byte-identical ordinary, uniform-scaling source, without introducing a new architecture. Worker w1456 explicitly reused this comparison set when evaluating a streamed output-head implementation. Its 0.906886 BPB beat nine observations but not the best, 0.906862; the worker therefore did not claim a new quality record or a repeatable BPB gain. Instead, it identified the clearer observed benefit as a reduction in whole-run peak allocation from 88,331.6 to 84,233.8 reported MB (4.64%). This was not an isolated training-only memory profile. The verification contribution supplied experimental context for interpreting a later systems change, rather than code or a new incumbent.

Consolidation included simplification.

Worker w0642 questioned an inherited MLP multiplier, 0.56776, whose rationale assumed an activation distribution rather than measuring the learned one. Replacing it with 0.5 scored 0.909838 BPB, which the worker described as an effective near-tie, not established superiority. Worker w0678 retained the simpler coefficient and combined it with the separately developed pre-RoPE normalization, obtaining 0.908277. The half-amplitude coefficient remained in the 24-hour incumbent. This documents measured consolidation rather than treating every inherited detail as indispensable; the synthesis does not isolate a coefficient-specific benefit. Simplicity was an explicit task preference, not an independently emergent objective.

Shared activity prevented a duplicate evaluation.

Worker w0033 discovered that w0032 had already announced the identical depth-10, head-dimension-64 experiment from the same source. It abstained before training; the evaluation ledger contains no evaluation by w0033. This episode shows shared in-flight state changing whether an experiment occurred at all, but does not establish that coordination was universally efficient or quantify aggregate resource savings.

Interpretation of these behaviors.

These episodes show observed reuse and revision of experimental evidence, including contributions that produced neither a new architecture nor a best score. This run explicitly assigned experimenter/synthesizer and critic/verifier roles at a configured 3:1 ratio: it supports adaptive work selection within those roles, not specialization without predefined roles. The traces document dependencies in experimental judgment, which need not be code-inheritance edges. They do not establish that shared memory caused the performance gain or identify each reused idea’s contribution; those claims require an appropriate comparison or ablation.

How the architecture emerged.

Figure6(b) condenses these developments. Early parallel tests establish narrower attention heads and wider residual states; head geometry, batch size, decay, attention sharpness and locality are then combined. Hashed bigrams open a second capacity axis, and their combination with back-loaded MLPs and autotuning reaches 0.912586 by 3.00 active hours. Later work transfers normalization order, investigates readout and gradient implementations, and revisits lexical context using shared trigrams. The selected path includes locally inconclusive and memory-oriented steps, not just successive best-score observations. This explains how the final combination can emerge through measured branches without assuming that every isolated improvement transfers additively.

Extension and limitations.

The extension further changes value routing, lexical gradients and FP8 training arithmetic. Worker w7352 combines expansion-forward FP8 with a side-branch E4M3 fast input-gradient implementation, producing the lowest observed 0.898671. However, its exact-source repeat scores 0.899864, and its worker publication is rejected for an extra audit Markdown file outside the allowed paths. The code remains reachable in Git, but there is no located completed finalizer submission. The best source associated with an accepted commit action measures 0.899233. We therefore describe the extension’s endpoint as a best observation rather than a verified final architecture. The original timing/evaluation code is retained apart from an optimizer learning-rate expression, but 701 successful harness records exceed the original instructions’ separate ten-minute overall timeout. No architecture-only attribution, calibrated confidence interval, or blanket semantic certification of all attempted programs is claimed.

E.5Findings Across Research Tasks

The three studies extend the evaluation from benchmarks with well-defined target solutions to multi-hour research tasks requiring architectural decisions, experimental feedback, and shared GPU resources, and they provide complementary evidence: RMT includes completed held-out evaluations of improved candidates; the Looped Transformer shows improvements during the recorded development trajectories; and NanoChat examines research from multiple starting points under different resource allocations.

An improving research trajectory does not by itself establish how much of that improvement comes from access to previous workers’ discoveries, nor does improving a research objective reveal which earlier experiments informed subsequent research decisions. The repository provides a mechanism for preserving experimental artifacts and coordinating subsequent work, but attributing a specific architectural improvement to earlier contributions requires analysis of the corresponding execution traces and experimental dependencies (see also the discussion of causal attribution in Section4).

Appendix FReuse, Artifacts, and Accumulation

This appendix supports Section3.4. It defines the reuse and ancestry statistics and shows a representative ancestry graph (AppendixF.1), documents how persistent artifacts were categorized, counted, and consumed (AppendixF.2), and describes representative collaboration workflows (AppendixF.3).

F.1Declared Reuse and Selected-Solution Ancestry

This subsection gives additional detail on the declared-dependency and selected-solution ancestry measurements of Section3.4. The per-budget coverage is shown in Figure7.

Selected-solution ancestry.

A worker may depend on only a few immediate sources while indirectly inheriting work from many earlier workers. Each contribution records its Git parent and any additional commits named in itsinformed_by=field (Section2.2). Recursively following both kinds of edge from the selected solution yields the part of the contribution graph that was carried into that solution, rather than merely produced somewhere during the run; the task root and nomination records are excluded. On ProgramBench this ancestry covers most of the contribution graph (Figure7), so repeated local composition from a few sources produces a broad final ancestry; selected proofs retain a much smaller share.

Coverage by budget.

Figure7reports, for each budget (B100–B500 on ProgramBench, B20–B160 on IMOProofBench-Advanced), the share of the substantive commit graph covered by the selected winner’s Git-parent ancestry and by its expandedinformed_by=ancestry; bars are averaged across tasks. Neither benchmark shows a consistent increase in coverage with budget. In both benchmarks, Git parentage alone accounts for roughly one quarter of the graph: with up to five concurrent workers per problem, several physical branches advance at once, so a single Git-parent chain cannot contain most contributions. The difference between the benchmarks therefore lies in cross-branchinformed_by=synthesis (Section3.4).

Interpretation.

Low proof ancestry does not imply that the other proof work is useless: alternative proofs, critiques, and validation can affect which candidate is selected without becoming an ancestor of that exact commit. Persistent state supports both synthesis and selection, while winner ancestry measures only the former. Local reuse and selected ancestry must therefore be measured separately to capture both behaviors.

F.2Persistent Artifact Production and Consumption

Workers coordinate through both protocol-defined files and voluntarily created artifacts. The prompt asks workers to leave useful intermediate artifacts in their commits. The voluntary artifacts that workers produce include tests, executable probes, captured outputs, reports, auxiliary proof notes, and documentation. These files act as persistent communication between episodes: a later worker can inspect a finding, rerun a probe, or adapt a test without reconstructing the producer’s private tool transcript. Because artifact creation alone does not establish collaboration, we distinguish production, subsequent access, active reuse, and linkage to the selected solution. Section3.4reports the headline consumption rates; this subsection gives the complete per-category artifact-flow measurements (Figure19) and documents how artifacts were categorized and counted, how the consumption stages are defined, and how production varies across tasks and budgets.

Artifact categories.

We derived the voluntary artifact categories separately for each benchmark. We first enumerated files added relative to each worker’s physical parent, excluding task inputs, candidate runtime files, and protocol-required files. We then reviewed paths, contents, diffs, commit metadata, and declared dependencies, summarized each file’s role, and grouped recurring roles by hand. This yielded six common ProgramBench categories and four recurring proof categories plus a small residual category (Table10). The proof labels were derived from the proof traces rather than transferred from ProgramBench.

Table 10:Benchmark-specific voluntary artifact categories.The categories were derived separately from files newly created by workers in each benchmark.BenchmarkCategoryRoleProgramBenchCaptured evidenceRaw outputs, logs, diffs, snapshots, or transcripts from executions.ProgramBenchHuman-readable findingsProse that records an observed behavior, diagnosis, or validation result.ProgramBenchExploratory probeExecutable experiment used to discover unknown behavior.ProgramBenchValidation harnessRepeatable executable check for an understood behavior or implementation.ProgramBenchInput fixtureInput or corpus created to exercise candidate behavior.ProgramBenchArtifact documentationIndex or instructions for using an artifact collection.IMOProofBenchComputation or probeScript or notebook used for symbolic, numerical, or combinatorial checks.IMOProofBenchCaptured evidenceStored output from a proof-related computation or external check.IMOProofBenchAuxiliary proof noteInformal derivation, lemma, case analysis, or critique outside the submitted proof.IMOProofBenchProof-edit aidHelper used to transform, compare, or inspect proof text.IMOProofBenchOther research artifactRare research file not covered by the four recurring proof categories.

Logical bundles.

Raw file counts are highly skewed. Some ProgramBench workers committed thousands of related output, error, status, and diff files from one experiment. We therefore count files that were created together in one artifact directory and serve the same role as one logical bundle when the files have no useful meaning on their own. The resulting counts describe reusable units rather than the serialization format chosen by a worker.

Production across tasks and budgets.

Figure18shows that production remains bursty after bundling. Different problems favor different kinds of evidence, and many runs create no voluntary artifact of a given type. On ProgramBench, some runs produce many tests and diagnostic artifacts, while others generate relatively few. Human-readable findings become more common with compute, appearing in 32% of B100 ProgramBench runs and 62% of B500 runs, while the other categories remain sparse and problem-dependent. A rare B100 artifact tool, a script for generating comparison diffs, was repeatedly used by later workers. That reuse pattern did not recur at other budgets; a separate B500 capture helper was opened but not actively reused.

The proof runs show the same lack of a monotone production trend. The number of tasks with at least one voluntary bundle is 21, 20, 19, 23, and 20 out of 30 from B20 through B160 (Table11). Computational and symbolic probes dominate voluntary production: computation and probe scripts account for 759 of 863 bundles. This concentration reflects the task: proof workers often use symbolic checks or numerical experiments to test a proof idea, whereas programming workers more often preserve behavioral findings, fixtures, and regression tests.

Table 11:Voluntary artifact production by budget.Entries give the number of task runs with at least one voluntary artifact bundle, after bundling files that lack independent reuse value.Figure 18:Voluntary artifact production on ProgramBench.Artifact bundles per task (columns) and charged-worker budget (rows within each category band), in log-scale bins; the right margin counts runs with at least one bundle. Production is sparse and bursty across tasks.

Consumption stages.

A worker-declared dependency does not by itself establish that the worker consumed the referenced artifact, so we also measure consumption directly from execution traces. Figure19separates three stages of consumption:

• •Accessed:a later trace explicitly reads, searches, parses, or compares a read-only artifact, or opens an executable artifact.
• •Actively reused:a read-only artifact informs a later contribution; an executable probe, test, tool, or fixture must be executed, imported, adapted, or supplied to another computation. For voluntary artifacts, the consumer must also cite the producing commit.
• •Winner-linked:the consuming contribution lies in the selected winner’s combined Git-parent andinformed_by=ancestry.

Passive inheritance and directory listings do not count as access or reuse.

Figure 19:Artifact flow from creation to reuse.For each artifact type on (a) ProgramBench and (b) IMOProofBench-Advanced, the share of created artifacts that are accessed, actively reused, and linked to the selected winner (bold), pooled over budgets. Rows without an Actively reused node skip that stage.

Interpreting consumption.

The pooled rates in Figure19show frequent artifact consumption in both domains (Section3.4): persistent state is not merely published, since later workers visibly inspect and use earlier artifacts. IMOProofBench-Advanced shows similarly frequent access but less durable reuse: its active-reuse rate is much lower than ProgramBench’s, because most opened computation or probe bundles are not executed or adapted by a citing contribution (Section3.4). This lower rate need not mean that the proof artifacts are less useful: a computation may rule out an approach after being read, while the metric requires it to be run or adapted and cited by a new contribution.

The protocol files provide a common channel even when voluntary artifacts are sparse. Every contribution worker writesMY_THOUGHTS.mdandEVALUATION.md, and nomination workers also writeBEST_SOLUTION.md. The first two files are accessed in nearly all eligible revisions in both benchmarks, but winner linkage differs much more than access (Section3.4): fewer than a quarter (22.6%) of proof protocol revisions connect to the winner through a consuming contribution, while ProgramBench artifacts usually enter its broad selected ancestry. Proof workers therefore use persistent artifacts extensively to inspect and compare candidates even when that evidence is not folded into the selected proof. The contrast between frequent access and weaker winner linkage on the proof tasks shows why consumption and final synthesis are separate outcomes: a worker may read an artifact without using it in a subsequent contribution, and an artifact may support verification without appearing in the selected solution’s ancestry. The artifact-flow measurements therefore support a general claim of artifact-mediated coordination, but not a claim that every read is preserved in the final candidate; neither access nor winner linkage establishes the causal effect of artifact access on score.

F.3Collaboration Workflows

The contribution graph also exposes distinct, problem-adaptive patterns of collaboration that emerge inGitSwarmruns, complementing the task-level work mix in Section3.5(AppendixG.1). Aworkflow archetypedescribes the dominant way that contributions are organized in one run. It is inferred from the commit graph,informed_by=edges, worker actions, and the semantic role of each contribution. It is not a role schedule imposed by the prompt. Figure9illustrates two representative ProgramBench runs. One exhibits late integration, in which separate lines of implementation work are subsequently combined. The other illustrates search-and-pivot (search and redirection), as workers develop alternative approaches over an extended run.

Late integration and divide-and-conquer.

In Delta B100 (Figure9(a)), several branches improve different parts of a candidate before a broad rendering synthesis combines diff highlighting, submodule-log behavior, conflict handling, and other independently developed repairs at 80% of the run. The selected candidate at 92% incorporates further line-number and raw-line inspection work. This is late integration because the decisive candidate depends on several mature branches rather than one steadily refined line. Divide-and-conquer runs such as Pandoc B100 use a related but more specialized pattern: separate groups develop document structure and inline syntax on one branch and output modes and code-block handling on another before the branches join.

Search-and-pivot.

The Cheat B500 run (Figure9(b)) shows a different, search-and-pivot workflow. Workers spend the first 35% of the run mainly on CLI, configuration, YAML, and frontmatter behavior. Four renderer experiments then appear within one percentage point, covering JSON, style palettes, Go, and HTML/XML, and are quickly combined. CLI and configuration work continues until about 57%, while renderer work becomes the dominant selected lineage and ends in a final renderer synthesis. The pivot is a gradual change in the dominant search direction, not an abrupt replacement of all earlier work.

Caveats.

These examples are intended to make the dependency graphs interpretable. The labels summarize observed graph structure; one graph can contain more than one pattern, and the dominant pattern for the same problem can change with the compute budget. The examples therefore explain mechanisms seen in the traces rather than define an exhaustive set of mutually exclusive strategies or claim that a pattern is the best possible workflow for a task.

Appendix GWorker Activity, Coordination, and Design Tradeoffs

This appendix supports Section3.5. These measurements complement the dependency results by examining activities that do not necessarily produce new solution-building commits. We describe the worker-activity taxonomies, the work mix, and coordination-tool usage (AppendixG.1), worker episode outcomes and unsuccessful episodes (AppendixG.2), candidate nomination (AppendixG.3), voluntary abstention (AppendixG.4), inspection of previous work (AppendixG.5), and the architectural tradeoff experiments (AppendixG.6). Artifact production and representative collaboration patterns are covered in AppendixF.

G.1Worker-Activity Taxonomies, Activity, and Coordination-Tool Use over Time

Section3.5presents the ProgramBench work mix and summarizes how the mixture of observed work changes as the graph matures. This subsection describes how the activity labels are constructed, shows the IMOProofBench-Advanced work mix, and reports additional activity and coordination trends.

Taxonomy construction.

Because workers have no fixed solver, verifier, or integrator roles, whether from the scheduler or the prompt (Section2.3), we infer activity labels after the run to examine whether the mixture of observed work changes over its course. We derive the labels bottom-up and independently for each benchmark, with separate taxonomies for programming and proof work. For every worker episode, we review the declared scope, tool trajectory, terminal action, commit metadata, and changed files. File evidence comes from the diff against the worker’s physical Git parent: only files changed by that worker enter the classification, so inherited files are not attributed to the worker and do not make a descendant appear to repeat its parent’s work. We summarize the episode’s primary contribution, group semantically similar summaries by hand, and name the recurring groups. Each episode receives one primary label; non-contributing episodes are labeled as selection, abstention, or invalid according to their terminal action. Table12lists the six categories obtained for each benchmark.

Table 12:Bottom-up worker-activity taxonomies.The two taxonomies are derived separately because implementation and proof construction leave different trace evidence.

Activity over time.

Figure20shows the distribution of these categories over worker-spawn progress for IMOProofBench-Advanced; the ProgramBench counterpart appears in Figure10(Section3.5). Both domains begin with a short wave that creates initial candidates, after which workers operate on an established graph; what happens after startup differs between the two benchmarks. Whereas ProgramBench sustains implementation work through termination, IMOProofBench-Advanced shifts much more strongly, and much earlier, toward selection once proof candidates exist. Beyond the budget-level selection shares reported in Section3.5, the share of graph expansion (contribution commits, i.e. all proof categories except Candidate selection: the bands below the ink rule in Figure20) falls quickly, and selection occupies 64.8–82.2% of episodes in the final fifth of a proof run. Additional compute therefore extends implementation work on ProgramBench, whereas larger proof budgets extend comparison and ratification of a small frontier more than construction of new proofs. The shared startup followed by different mature phases shows that one decentralized protocol can adapt its workflow to the task: program reconstruction keeps accumulating implementation changes, whereas these proof runs increasingly use the repository to evaluate work that already exists.

Figure 20:IMOProofBench-Advanced worker activity over inference.Share of worker episodes by activity category (Table12) against worker-spawn progress, per budget; the black line tops all contribution commits. Unlike ProgramBench workers, who keep constructing until the end (Figure10), proof workers shift early to selection.

Coordination activity over time.

The coordination traces in Figure21also reflect the changing work mix. The workers have access to four relevant tools:

• •gs_exploreandgs_inspect: Allows the workers to view the Git DAG and expand specific commits in it.
• •gs_dashboard: Invokes the system dashboard showing the amount of budget remaining and the number of active workers and their IDs.
• •gs_inflight: Allows workers to inspect the public logs of other in-flight workers.

On ProgramBench,gs_dashboardandgs_inspectcalls rise near termination because nomination workers compare more candidates; contribution workers do not show a similar jump.gs_inflightreads are common from the beginning because the prompt asks workers to check for overlap before choosing a scope. The proof traces contain nogs_exploreorgs_inspectcalls; the Gemini workers use targeted Git reads instead. The shared behavior is inspection and comparison, while the exact coordination tool depends on the worker interface.

Figure 21:Coordination-tool use over inference.Mean coordination-tool calls per worker against worker-spawn progress, per budget (light = small), for (a) ProgramBench and (b) IMOProofBench-Advanced. Proof traces contain nogs_inspectorgs_explorecalls.

G.2Worker Episode Outcomes and System Health

Episode outcomes by budget.

Figure22shows that the different work mixes of the two benchmarks do not reflect a general collapse into failed work. Roughly three quarters of all ProgramBench worker episodes end in a contribution commit at every budget, while abstentions remain spread through the run. The exact contribution share is partly shaped by five-worker concurrency, but the persistence of repair, expansion, and synthesis (Figure10) matters more than the precise value. IMOProofBench-Advanced has more selection outcomes and more no-action or invalid episodes, consistent with its smaller active proof frontier.

Figure 22:Worker episode outcomes.Share of episodes ending in a contribution commit, nomination, voluntary abstention, or invalid/no action, per budget, for (a) ProgramBench and (b) IMOProofBench-Advanced. Only voluntary abstentions do not consume the budgetBB.

Unsuccessful charged episodes.

Not every charged worker episode produces a valid contribution or nomination. Across the 200 ProgramBench B100 runs, 615 of 20,000 charged episodes (3.1%) produce no accepted action. Of these, 515 fail candidate-publication or required-artifact validation, 79 fail nomination validation, and 21 terminate without a valid action because of API failures, turn limits, or protocol violations.

Coordination overhead.

These unsuccessful charged episodes are distinct from voluntary abstentions, which are replaced without consuming the charged budget (Section2.3). Both nevertheless consume resources, so the effective cost of collaboration includes unsuccessful work, redundant work (AppendixG.4), and inspection of shared history (AppendixG.5). The execution system must also manage asynchronous publication, validation, and access to in-flight activity. Detailed worker-outcome and coordination statistics help characterize this overhead separately from the benchmark performance of accepted contributions.

G.3Voting Dynamics and Selection Timing

Workers may nominate an existing candidate rather than publish another contribution (Section2.3). We analyze compounding nominations over normalized worker-spawn progress (Figure23) and measure when the eventually selected candidate is first committed relative to the first nomination (Figure24). Section3.5summarizes the timing results; this subsection gives the per-budget details. Figure23shows that selection is autonomous rather than a fixed final phase. More compute produces more comparisons and votes in both benchmarks, but their timing differs.

Figure 23:Voting dynamics.Mean compounding nominations per problem against worker-spawn progress, per budget, for (a) ProgramBench and (b) IMOProofBench-Advanced; shading marks the last 10% of spawns. ProgramBench votes arrive in a terminal pulse, whereas proof votes accumulate steadily.Figure 24:Selection timing.Worker-spawn progress at which the eventual winner is first committed (black) and the first nomination is cast (green), per budget; medians and interquartile ranges over problems. The winner appears late on ProgramBench and early on IMOProofBench-Advanced.##### ProgramBench.

Nominations are concentrated toward the end of ProgramBench runs. Workers continue constructing, repairing, and integrating implementations for much of the available budget, followed by a clear terminal voting pulse of candidate comparison (Figure23(a)). The first vote moves from 68.4% of normalized progress at B100 to 16.1% at B500, mainly because the total run grows from about 122 to 599 episodes while voting starts after a similar absolute amount of work; a substantial selection pulse still remains near termination at larger budgets. This suggests that forming the first submittable candidate requires a roughly fixed amount of work over the tested budgets.

Figure24(a) connects voting to candidate construction. The exact ProgramBench winner is produced late, at 93.1–98.0% median progress, only 8–11.5 worker episodes before termination, consistent with continued refinement and integration throughout the run. Construction continues near the budget boundary, and the winner is usually a final repair or integration that inherits older work. Because votes attach to exact commit hashes, each repair creates a new target and splits support across successive versions. A strong late integration can therefore win after a small, rapid voting pulse.

IMOProofBench-Advanced.

The proof-solving runs follow the opposite pattern (Figure23(b) and Figure24(b)). Nominations begin much earlier, continue over a larger fraction of the run, and accumulate almost linearly after startup. The median first nomination (voting onset) moves from 32.5% of worker-spawn progress at B20 to 4.0% at B160, with the intermediate budgets falling in between. The selected proof also appears early: its median creation time lies at 8.6–17.5% of normalized progress across the tested budgets. Mean nominations per problem rise from 9.1 at B20 to 115.6 at B160. Later workers mostly compare and ratify that early candidate.

Relation to selected-solution ancestry.

Nomination timing thus matches the different accumulation regimes. These differences help explain the contrasting selected-solution ancestry reported in Section3.4(Figure7). ProgramBench frequently produces a late, integrated candidate, whereas proof-solving workers may repeatedly evaluate and nominate an earlier proof without modifying its exact commit.

Caveats.

A nomination is a worker preference, not an independent verification of correctness: repeated nominations for one SHA are coordination signals, not independent proofs of correctness. Moreover, the proof runs differ in configuration (AppendixB.4), so we treat cross-budget differences in voting behavior and timing as descriptive rather than as a controlled change in budget alone.

G.4Voluntary Abstention and Redundancy

Workers may explicitly abstain when their intended contribution is already covered by published or in-flight work, or when no useful nonredundant change remains; voluntary abstainers are replaced without consuming the charged budget but still incur token costs for the inspection and reasoning they perform before abstaining (Section2.3). By contrast, invalid actions, invalid nominations, no-action exits, and system failures do consume a slot; invalid and no-action episodes are shown in the Invalid / no action class of Figure22, separate from voluntary abstentions. Section3.5summarizes the main redundancy findings; this subsection reports the underlying statistics and the calibration of abstention judgments.

Redundancy rates and collision sources.

A worker declares redundancy when it abstains because equivalent work is already committed or in flight. Figure25shows that declared implementation redundancy stays near one ProgramBench worker in six across budgets, but remains below 2.7% on IMOProofBench-Advanced. Explicit redundancy abstention is thus less common in the proof-solving runs: across B20–B160, the fractions of spawned workers that abstain as redundant are 0.65% (B20), 1.22% (B40), 1.49% (B80), 2.62% (B120), and 2.39% (B160). Figure26explains much of this difference. ProgramBench abstainers usually cite overlapping work that is still in flight, so many ProgramBench abstentions arise from redundant concurrent work. Proof abstainers instead usually cite a completed, already published proof rather than concurrent in-flight work: of the 273 IMO redundancy cases, 268 include committed evidence and only three cite in-flight work alone.

Asynchronous overlap on ProgramBench.

The ProgramBench cases usually arise from asynchronous overlap. Among committed-only collision workers, 407 of 419 with a matched commit, or 97.1%, saw that commit land after their own episode began; that is, the conflicting commit was not yet published when they started. They were not idle while waiting. Of these workers, 86.7% edited files, 98.8% built a candidate, 99.0% ran tests, and 95.1% probed the oracle. In 71.5% of cases, the worker had seen the eventual committer’s public scope and continued working; a smaller subset explicitly planned to wait or refresh the graph before committing. The usual behavior is parallel work (editing, building, testing, and probing) followed by a late check of the durable result, after which the worker stops; abstention therefore prevents a duplicate commit but not the computation already spent. Proof abstainers instead stop after a median of five to seven tool turns once they find a completed candidate (Figure26(c)).

Token cost.

The resource cost follows the same difference. As shown in Figure27, ProgramBench abstainers consume about 6–7% of both input and output tokens across the analyzed budgets. Explicit proof abstainers consume only 1.2–2.8% of input tokens and 0.3–0.8% of output tokens. These values do not include the larger set of no-action, invalid, and selection-related proof episodes.

Calibration review on ProgramBench.

We calibrated the ProgramBench judgments with a score-blind review of all 422 committed-only collisions and five pre-registered in-flight-only cases per problem and budget, for 1,422 abstention traces in total: 289 at B100, 315 at B200, 346 at B300, and 472 at B500. The review packet contained the worker’s scope, terminal rationale, final public in-flight state, cited peer outcomes, later commits, and selected-candidate ancestry. Common cases were resolved from this evidence, and cases with failed peer paths, unresolved references, or questionable probes received semantic review. The review labels are defined as follows:

• •Justified: the cited work materialized and covered the intended contribution.
• •Premature but recovered: the cited path failed, but later work restored the capability.
• •Premature and unrecovered: the cited path failed and later work did not restore the capability.
• •Spurious: invalid or unstable evidence was mistaken for redundancy.
• •Ambiguous: the trace does not identify a concrete claim that can be checked.

Figure28(a) reports the resulting calibration by budget. In the current review, 1,349 of the 1,421 adjudicable ProgramBench traces, or 94.9%, are classified as justified.

Trace-evidence audit on IMOProofBench-Advanced.

The IMO audit finds a named pre-existing commit or a named peer that later committed in 269 of the 273 redundancy cases (Figure28(b)). This is a trace-evidence check, not a mathematical equivalence judgment. It establishes that the cited work existed or materialized, but not that two proofs are mathematically equivalent, that the cited proof is correct, or that abstaining workers correctly assessed the cited proofs or their own potential contributions.

Interpretation.

The two panels of Figure28answer different questions: the ProgramBench review assesses whether the cited work covered the intended contribution, while the IMO audit checks only whether the named evidence existed. The high ProgramBench rate shows that abstention usually prevents duplicate commits, while the few unrecovered cases expose its main risk.

Figure 25:Declared redundancy.Share of spawned workers that abstain because equivalent work is committed or in flight, per budget, for (a) ProgramBench and (b) IMOProofBench-Advanced. Dots: problems; line: pooled rate with 95% CI; dashed line: one worker in six.Figure 26:Timing and cited evidence of redundancy abstentions.(a, c) Tool turns at which abstainers stop, by the evidence they cite; gray ticks mark committing workers. (b, d) Abstainers per problem by cited evidence. ProgramBench abstainers mostly cite in-flight work; proof abstainers cite committed proofs and stop early.Figure 27:Abstaining workers still consume tokens.Share of input and output tokens (output including reasoning) used by voluntarily abstaining workers, per budget, for (a) ProgramBench and (b) IMOProofBench-Advanced. Whiskers: bootstrap 95% CIs.Figure 28:Redundancy abstentions almost always cite real work.Label distribution per budget: (a) score-blind review of a stratified ProgramBench sample; (b) trace-evidence audit of all IMOProofBench-Advanced redundancy abstentions, which checks that cited work exists, not proof equivalence.

G.5Selective Inspection of Shared History

As the repository grows, workers could incur increasing costs if they repeatedly inspected every previous contribution. Section3.5notes that workers instead inspect only a few candidate commits each, an increasingly small fraction of the available graph. Here we report the underlying measurements: the number of distinct candidate commits explicitly inspected by each worker and the fraction of the available spawn-time history those inspections reach (Figure29).

Figure 29:Selective inspection as the graph grows.(a, c) Distinct candidate commits each worker opens and (b, d) share of the spawn-time history it reaches, against worker-spawn progress, per budget (ten-worker moving averages). Workers open a bounded number of candidates, so their reach shrinks as the history grows.##### Measurement.

Figure29counts only explicit opens of uniquely identified candidate commits throughgs_inspector targeted Git commands. The x-axis follows worker spawn order, and each point is a fixed ten-worker moving average. The available history is frozen at worker launch, so the history fraction measures how far the worker reaches into what it could have inspected at that time. Tool-specific inspection counters, such as the per-tool curves in Figure21, must be interpreted carefully: proof workers’ explicit candidate opens appear only as targeted Git reads (AppendixG.1).

Bounded inspection sets.

Both benchmarks keep the explicit inspection set bounded as the graph grows. The first window is low because little prior work has been published. On ProgramBench, inspection is initially broad because few candidates are available: workers 10–19 see roughly eight candidates and inspect nearly all of them because no clear foundation has emerged. Later workers inspect a relatively small set of commits despite a substantially larger repository: they use summaries and declared dependencies to focus on one existing integrated candidate and a small number of relevant alternatives. By workers 90–99 in the B100 runs, roughly 72 candidates are available, but each worker explicitly opens only about six. Proof workers show a similar pattern with a smaller frontier: after startup, they explicitly inspect approximately three candidates on average across the tested budgets. The proof graph is smaller, so those three candidates still reach a larger fraction of its history than the five to seven candidates typically opened on ProgramBench.

Declining history fraction.

The history-fraction panels, (b) and (d) of Figure29, show the consequence: as the available history grows, a relatively stable inspection count reaches a decreasing fraction of the spawn-time history. On IMOProofBench, the fraction reached falls from 81.9% at the end of B20 to 53.8% at B160. ProgramBench workers also reach a shrinking fraction, even though their absolute look-back distance into the spawn-time history (measured in commits) increases, growing to about 20 commits at B100, 50 at B200, 80 at B300, and 150 at B500. Workers are not losing access to old work; they are moving from broad orientation to selective use of a larger history.

Startup and endpoint spikes.

Broader comparison is concentrated near startup and, on ProgramBench, during the final selection pulse. The initial ProgramBench spike appears across work types, so it is not caused by nomination workers. The smaller late spike is consistent with the final selection pulse, when workers compare more candidates. IMOProofBench lacks a similar endpoint spike because selection already occupies much of the run.

Interpretation and scope.

These shared and task-specific patterns indicate selective navigation rather than exhaustive reinspection, and suggest that the repository is used as a searchable memory rather than a transcript that every worker rereads in full. The present budgets do not establish that this behavior will remain effective, or persist without degradation, at substantially larger graph sizes. Taken together with the nomination and abstention analyses (AppendicesG.3andG.4), these patterns show coordination through shared state without fixed worker roles. This coordination includes synthesis into later solutions, but also comparison, redundancy avoidance, and selective navigation whose influence may not appear in the selected solution’s ancestry.

G.6Architectural Tradeoffs

Section3.5summarizes twoGitSwarmdesign comparisons on the ProgramBench development set. Here we describe the compared configurations; Table13reports the full results and experimental settings.

Asynchronous versus synchronous execution.

The default scheduler launches a replacement worker whenever a worker slot becomes available. The synchronous variant instead executes barriers of five workers: it waits for every worker in a five-worker wave to finish before launching the next wave. Synchronization changes the mean score by+1.05+1.05points but increases the mean task runtime by a factor of 1.30. Because each synchronous wave waits for its slowest worker, this is consistent with asynchronous execution reducing straggler-induced latency. Under these conditions, asynchronous execution therefore reduces latency with a small observed difference in mean score; the experiment does not establish statistical equivalence between the two schedules.

Decentralized versus centralized readout.

By default, the submitted candidate is determined by decentralized worker nominations (Section2.5). We compare this readout with two variants that reserve one of the 50 episodes for a privileged final worker: acentral selector, which chooses an existing candidate, and acentral aggregator, which synthesizes a new candidate. Relative to decentralized nomination, the central selector raises the mean score by 2.34 points with a shorter mean runtime, whereas the central aggregator lowers the mean score by 3.87 points and takes 16% longer. In this study, forcing a final synthesis step was thus neither more accurate nor more efficient than decentralized nomination. The central selector has the higher observed mean in this development-set comparison, but the limited number of seeds does not establish a general advantage of either readout or their statistical equivalence.

Table 13:Architectural tradeoffs on the ProgramBench development set.Score is the macro-average test score over the nine development tasks (mean±\pmsample standard deviation across three random seeds);Δ\Deltais the difference in mean score from the default configuration in percentage points; runtime is the mean generation wall-clock time per task. All configurations use GPT-5.5-medium,B=50B=50worker episodes per task, and maximum concurrency five. The default configuration (asynchronous execution with decentralized nomination) is the control in both blocks.These comparisons characterize execution and readout choices withinGitSwarm. They do not isolate the individual contributions of persistence, branchability, or semantic dependencies to benchmark performance; the controlled tests in AppendixCexamine the operational benefits of these properties separately.

Appendix HGitSwarmWorker Prompts

H.1Prompt Assembly

This appendix lists theGitSwarmprompts used for the ProgramBench runs with Codex and GPT-5.5 workers, the IMOProofBench-Advanced runs with Gemini-3.1-Pro workers, and the RMT and Looped Transformer research runs. A worker’s system prompt concatenates the global component (AppendixH.2) with the task addendum (AppendixH.3) and, for Gemini-3.1-Pro workers, a sequential shell-interaction extension (AppendixH.4). The user prompt is task-specific (AppendixH.5). Codex workers additionally receive a transport override after the user prompt; the system prompt, user prompt, and override are passed to the Codex CLI together as a single input, on top of Codex’s built-in instructions. Table14lists the components used in each setup.

aWith the nomination action and all nomination-related text removed, since the best candidate is selected by its validation score after the run rather than by worker nominations. The opening description of the final selection and the dashboard description (which instead reports live compute-resource utilization and the best completed protected-development score) are rewritten accordingly, one sentence omits thegs_inspectcommand, and a short autoresearch selection policy, which tells workers to end with a commit or an abstention and not to nominate, precedes the task addendum. bAn analogous override instructing workers to run commands with Codex’s native shell tool (not listed). cThe task description, followed by the worker context, a spawn-time dashboard snapshot, and a short reminder on job paths and job ownership (not listed). In the seeded RMT run, a block listing the inherited incumbents precedes the worker context.

Table 14:Prompt components used in eachGitSwarmsetup listed in this appendix.

H.2Global System Prompt

The ProgramBench setups and the Gemini-3.1-Pro IMOProofBench-Advanced setup use the global component below unchanged; the research tasks use the variant described in Table14.111The global component describes a structuredbashexecution tool. Codex workers executed commands through a tool: a guarded MCP tool that executes commands inside the task container for ProgramBench, and Codex’s native shell for the research tasks. Gemini-3.1-Pro workers were not given a tool definition; the harness instead executed the fencedbashblocks in their responses. The GPT-5.5 ProgramBench workers used fenced blocks atB=100B=100andB=200B=200; atB=300B=300, 33 of the 50 tasks were run with a structured tool and the remaining 17 with fenced blocks.Angle-bracketed text in the system prompt and its addenda is part of the prompt and is shown to workers verbatim.

Youareanautonomousworkerinanasynchronoussearchforthebestsolutiontotheuser’squery,collaboratingwithotherworkersthroughasharedGitrepository.

YouworkautonomouslyinyourownGitworktreewithinapersistentrepositorysharedbyallworkers.Therepositoryrepresentsagraphofcandidatesolutions.Eachgraph-expansioncommitaddsonecandidatenode.

Acandidate’sGitparentidentifiestherepositorystatefromwhichitwascreated.Its`informed_by=`provenanceidentifiestheearliercommitsthisworkerdirectlyreliedonwhendevelopingthecandidate.Thesearedifferentrelationships:theGitparentrecordsphysicalancestry;provenancerecordssemanticinfluence.

Theswarmisadiscoveryprocess:workersexpandandexplorethisgraphinsearchofthebestsolution.Acandidatenodeneednotsettletheproblempermanently.Itmayinsteadbeausefulsteppingstonethatlaterworkersinspect,test,criticize,repair,extend,combine,orreplace.Nevertheless,everygraph-expansionnodemustpreservethetask-specificstructureandartifactsrequiredtostandasacandidateanswerifinspectedonitsown.

Thereisnomutablecurrent-bestsolutionandnoexclusiveselector.Anyworkermayinspectthegraphandnominateoneexistingcandidatebycreatingarationale-bearingnominationcommit.Eachvalidnominationcontributesexactlyonevote.Whentherunends,thecandidatewiththemostvotesisthesystemoutput.EqualvotetotalsareresolveddeterministicallybylexicographicfullcommitSHA.Iftherunendswithoutavalidnomination,nocandidatesolutionhasbeenselectedandthesystemfallsbacktotherepositoryroot.

#Executioninterface

Youhaveastructured`bash`executiontoolconnectedtoarealshellinyourGitworktree.Everyresponsemustcallthistoolwiththecommandbatchtoexecute.Donotmerelydescribecommands,claimthatcommandsran,orreturnaprose-onlyresponse.Natural-languagetextisnotexecuted.

Commandswithinoneresponseexecuteasabatch.Theircombinedstdoutandstderrarereturnedinthenextmessage.Useasmanyturnsasnecessary,andwaitforcommandoutputbeforemakingdecisionsthatdependonit.

Shellcommandsintheexamplesbelowareshowninfenced`bash`blocksforreadability.Submittheircontentsthroughthe`bash`tool.

Followtheworkflowbelow.Donotbranch,edittrackedfiles,declareanomination,commit,orabstainbeforecompletingtheprecedingapplicablestepsforyourchosenaction.

#Review:Inspectandunderstandcompletedandin-flightwork

Beginwith:

```bash

gitlog--graph--oneline--all

```

Carefullyinspectandinteractwiththerepositoryuntilyouunderstandthecandidatesolutionsandlinesofexplorationrelevanttoyourdecision.Donottreatcommitsubjectsassubstitutesforreadingthework.Usefulcommandsinclude,butarenotlimitedto:

```bash

gitstatus

gitbranch--all

gitshow<sha>

gitshow<sha>:<path>

gitdiff<sha1><sha2>

gitgrep<pattern><sha>

gitls-tree-r<sha>

gs_explore

gs_inspect<sha>

gs_inflight

gs_inflightinspect<worker-id>

gs_inflightread<worker-id><path>

```

Gitcommands,`gs_explore`and`gs_inspect`showdurableworkthathasalreadybeencommitted.`gs_inflight`showsconciseactivitylogsandvisibleworking-treestateforworkersstillinflight.Inspectbothcompletedandin-flightworkthoroughlyenoughtoavoidchoosingacontributionthatisalreadycompleteormateriallyunderway.

Inspectboththecommittedgraphaswellastheworkunderwayinin-flightworkersasextensivelyaspossibleinordertomaximallyinformyourdecisionandsub-sequentwork.Refresheitherviewwheneveryourunderstandingmaybestale.

Peerworktreesarestrictlyread-only.Nevermodify,stage,delete,rename,executemutationcommandsin,orotherwiseinfluenceanotherworker’sworktreeoractivityrecord.In-flightcontentisunfinishedcoordinationevidence,notdurableprovenance;donotcopyordependonitunlessitlaterappearsinacommittednodethatyouinspectandcitethrough`informed_by=`.

Theusermessagecontainsaspawn-timedashboardsnapshot.Torequestacurrentsnapshotofthelimitedcoordinationstate,run:

```bash

gs_dashboard

```

Thedashboardreportsthetotalworkerbudget,remainingworkerbudget,numberofworkerscurrentlyinflight,numberofnominationcomparisonscurrentlyinflight,totalcompletednominations,andthecurrentnominationtallybycandidateSHA.Itdoesnotsummarizetherepositoryforyou.

Completednominationsandtheirvotecountsareselectionstate,notbehavioralevidencethatacandidateiscorrect.Nominationworkersmayshareassumptions,tests,ormistakes,soapparentagreementcanbecorrelatedorredundant.Becriticalandformyourownjudgmentfromthecandidategraphanddirectevidence.Avisiblenomineeisnotautomaticallyaseriouscontender,andanunlistedcandidatemaysimplybenewerornotyetreviewed.Donotrestrictinspectiontonominatedcandidates,copytheapparentmajority,orinferqualityfromnominationcount,recency,branchlength,popularity,orcommittype.

Inspectcontents,evidence,evaluations,rationales,relevantdifferencesacrossnodes,andactiveworkerscopes.Useasmanyinspectionturnsasneeded.

#Chooseanaction

Selectoneofthefollowingthreeactions.

##Action1:Makeacontributiontowardtheuserquery

Expandthegraphbymakingacontribution.Followthesequenceofstepsbelow.

###Decideandpublishoneboundedcontribution

Afterinspectioniscomplete,privatelychooseoneboundedcontributionbyconsideringitsgap,concretedeliverable,relevanttargetcommits,observablesuccesscriterion,andabortcondition.Donotemitaseparateprosescopeblock.

Thesuccesscriterionappliestothescopedcontribution,notnecessarilytotheentireuserquery.Theabortconditionboundsthework.Iftheplannedcontributionbecomesredundant,materiallyunderwayelsewhere,unsupported,ornolongerworthwhile,abstainimmediately.Anegativeresultmaybecommittedonlywhenitdirectlysatisfiestheoriginalscopeddeliverable.

For`Targetcommits`,selectoneormoreexistingcommitsthatwillinformyourwork.Thestatedgapanddeliverablemustexplainwhythecontributionwouldaddnonredundantvaluetothegraph,andthescopemustexplainhoweachtargetcommitinformstheplannednode.

Nomination-recordcommits(explainedlater)arenotcandidatenodesandcannotbephysicalparentsforgraphexpansion.Youmaystillinspectthemandcitethemin`informed_by=`whentheirrecordedcomparisonmateriallyinformsyourwork.

Chooseworkwithhighexpectedmarginalvaluegivenboththecompletedgraphandactivework.Donotrepeatworkalreadycompleteormateriallyunderwayunlesstheoverlaphasconcreteimmediatevalue,suchasagenuinelydifferentimplementation,targetedfalsification,ornecessaryindependentverification.Ifnoavailablecontributionwouldaddmeaningfulvalue,abstainratherthanmanufactureredundantwork.

Beforebranchingorediting,publishtheresultingscope.Keepthesummaryconcisebutincludethegap,deliverable,successcriterion,andabortcondition;use`--target`fortheprimarystartingcommitandnameanyadditionalsemanticsourcecommitsinthesummary:

```bash

gs_inflightannounce--stagescoping--summary“Gap:<unresolvedneed>|Deliverable:<artifactorchange>|Success:<observableevidence>|Abort:<invalidatingevidenceorconstraint>“--target<sha>

```

Thisisanadvisoryupdate,notascoperequest.Use`gs_inflightupdate`formeaningfulprogress.Ifcompletedorin-flightworkmakestheannouncedcontributionredundant,ornewevidenceotherwiseinvalidatesit,immediatelyuse`gs_abstain`withasubstantiverationale.Otherworkersmayinspectthislog,butnoschedulergrants,rejects,ranks,orreservesthework.

Preferacoherentcontributionthatoneworkercancompleteandmakelegibletothenextworker.Progressonalongorambitiousapproachshouldbedistributedacrosssuccessivenodes.

###Initializethecontribution

Fromtheselectedtargetcommits,choosetheonecommitwhosetreeisthemostconvenientconcretestartingstatefortheplannedwork.Thencreateandswitchtoyourbranchexactlyonce:

```bash

gs_fork<starting_commit_sha><short-task-name>

```

Thisstartingcommitbecomesthenode’ssoleGitparent.Itisonlythephysicalstartingstate.Everytargetcommitisasemanticsourceandmustappearinthefinalcommit’s`informed_by=`field,includingtheGitparent.Donotomitprovenancewhenthereisonlyonetargetcommit.

Donotcall`gs_fork`asecondtime.Iftheannouncedcontributionbecomesredundantorcannotbecompletedusefullyfromtheselectedstartingtree,abstain.

###Materializethecontribution

Performtheplannedworkandvalidateitasappropriate.Preservealltask-specificartifactsandstructuralrequirementsneededfortheresultingtreetoremainacandidatesolution.

Create`MY_THOUGHTS.md`forthisworkerandrecord:

-theintendedcontribution,

-thesemanticsourcecommitsandhowtheywereused,

-thereasoningbehindtheapproach,

-importantscope-validityandabstentionchecks,

-theworkperformedandevidenceobtained,

-unresolveduncertainty,and

-concreteTODOsorpromisingnextsteps,whenanyremain.

Youmaycreateotherusefulartifacts,includingtests,experimentresults,implementationfiles,notes,ortask-specificanswerfiles.Theseartifactscommunicateyourworktolaterworkerswhomayinspect,buildupon,orcarryitforward.Maketheirpurpose,evidence,andlimitationsclear.

###Evaluatethecandidate

Beforecommitting,create`EVALUATION.md`withthisworker’scandid,evidence-basedassessmentoftheresultingcandidate:whatitaccomplishes,whatyouactuallychecked,knowngapsorrisks,andthemostusefulnextworkwhenapplicable.

Ausefulsteppingstonemayexplicitlydescribewhatremainsunresolvedwhilestillretainingtheformofacandidatesolution.

##Action2:Nominatethebestexistingsolution

Inthisaction,carefullycompareexistingcandidatenodesandidentifythecurrentbestcandidate.Donotoriginateanewsolution,repairacandidate,orsynthesizecandidatesaspartofthenomination.

###Scopeoneboundednomination

Afteraninitialfull-graphinspection,privatelyscopethecomparisonneededtonominatethecurrentbestexistingcandidatebyconsideringthenominationquestion,graphcoverage,commonevidence,successcriterion,andabortcondition.Donotemitaseparateprosescopeblock.Continuethecomparisonthroughthe`bash`tool.Ifnominationisyourchosenaction,publishthatacriticalgraphcomparisonisunderwaybeforedetailedcomparison,withoutrevealingatentativenomineeorcandidatepreference:

```bash

gs_inflightannounce--stagenominating--summary“Criticallycomparingthefullcandidategraph;notentativepreferencedisclosed“

```

Keeplateractivityupdatesforthiscomparisonatstage`nominating`sothedashboardcanreporthowmanynominationworkersarecurrentlyinflight.

Thefullcandidategraphisthecandidateset.Full-graphcoveragedoesnotrequireequaltimeorexhaustiveretestingofeverynode:useancestry,diffs,existingevaluations,andevidencetoidentifyredundantordominatednodes,thenspenddeeperinspectionandtestingonseriouscontenders.Donottreatcommitsubjectsorthelivenominationtallyassubstitutesforreviewingthegraph.

Useevidencethatbearsoncomparablebehavior.Acandidatepassingitsowntestsisusefulevidenceaboutthatcandidate,butpasscountsfromdifferentcandidate-authoredsuitesarenotdirectlycomparable;inspectthetestsandbehaviortheycover.Priornominationrecordsmaycontainusefulevidence,buttheyarenotcandidatesandtheirexistenceorpopularityisnotevidencethatacandidateiscorrect.Makeyourownjudgment.

Atleastonevalidnominationisnecessarytoselectacandidateratherthanfallbacktotherepositoryroot.Donotvotemerelytochangethecount;iftheevidencedoesnotsupportadefensiblenomination,abstainbeforecreatingacontributionbranch.

Public`gs_inflight`updatesfromanominatingworkermustnotdiscloseatentativenomineeorcandidatepreference.Nominationjudgmentsremainindependentuntilballotcommitsarepublished.

###Initializeanddeclarethenomination

ChooseoneexistingcandidateSHAandbranchfromthatexactcandidate:

```bash

gs_fork<nominated_candidate_sha>record-best-solution

```

Thisbranchisonlyforthenominationrationale.Donotmodify,repair,combine,orextendthecandidate’ssubstantiveanswer.

Declarethenominationbeforecreatingtherationalecommit:

```bash

gs_nominate_best_solution<nominated_candidate_sha>

```

Thisrecordsapendingballotforschedulervalidation.Itdoesnotacquirealock,updateanincumbent,orrevealalivewinner.Otherworkersmaynominateconcurrently.

###Documentthenomination

Createorupdate`BEST_SOLUTION.md`with:

-thenominatedcandidate’sexactSHA;

-thecandidatesandevidencecompared;

-anevidence-basedaccountofwhythiscandidateiscurrentlybest;

-knownlimitationsorremaininguncertainty;and

-anypriornominationrecordswhosecomparisonevidencemateriallyinformedthisnomination.

Thenomination-recordbranchmustotherwisepreservethenominatedcandidate’ssubstantivesolutionunchanged.

##Action3:Abstain

Choosethisif,afterinspectingcompletedandin-flightwork,noworkwouldaddimmediatemeaningfulinformationorprogress.Inparticular,abstainwheneveryfeasiblecontributionwouldmerelyduplicateworkalreadycompleteormateriallyunderway.Statethesubstantivereason,thenrun:

```bash

gs_abstain--rationale“<whynoavailablecontributionwouldaddvalue>“

```

Donotcreateanemptycommit.Anexplicit`gs_abstain`doesnotconsumeaworker-budgetslot;theschedulermaylaunchareplacementworker.

##Artifactauthorship

Foragraphcontribution,`MY_THOUGHTS.md`and`EVALUATION.md`areworker-specificandcontainoneauthorshipentryforthecurrentworker.Forotherhuman-readablecollaborationartifactsyoucreateorupdate,suchas`BEST_SOLUTION.md`,experimentreports,orcontinuationnotes,maintainanupdatehistoryatthetopofthefile.Prependoneentryforyourupdatewithoutdeletingearlierentries:

```text

Updatedby:Worker<WORKER_ID>|Scopedcommits:<sha1>,<sha2>,...

```

Foragraphcontribution,listitstargetcommits.Forabest-solutionnomination,listthecandidatesetthatmateriallyinformedthecomparison.Donotinsertthisplain-textheaderintosourcecode,executablescripts,generatedfiles,ordataformatsthatdonotsupportit;theirauthorshipremainsavailablethroughGithistoryandcommitprovenance.

#Commit,publishanynomination,andexit

Makeexactlyonecommit.Foragraph-expansioncommit,choosethemostaccuratedescriptivetypeandusethisformat:

```text

[<briefdescriptionofthetypeofcontribution>|informed_by=<sha1>,<sha2>,...]<summary>

```

Writethedescriptivetypeasoneormorelowercasewordsjoinedbyhyphens.

Provenanceismandatory.The`informed_by=`listmustcontainverifiedSHAreferencesforeverytargetcommitinthescopedcontribution,evenwhenthereisonlyonesource.AbbreviatedSHAsarevalidwhentheyuniquelyidentifycommitsintherepository.

```bash

gitadd-A

gitcommit-m“[<description>|informed_by=<sha1>,<sha2>,...]<informativesummary>“

```

Forabest-solutionnominationcontribution,includethenominatedcandidateandeveryothercandidatethatmateriallyinformedthecomparisonin`informed_by=`:

```bash

gitaddBEST_SOLUTION.md

gitcommit-m“[best-solution-nomination|informed_by=<sha1>,<sha2>,...]<informativesummary>“

```

Theschedulervalidatesthependingdeclaration,exactnominatedparent,provenance,unchangedcandidatetreeexceptfor`BEST_SOLUTION.md`,andrationale.Itthenpublishesoneimmutableballotforthisworker.Thenominationcommitismetadataandisnotitselfeligibletoreceivevotes.

Afterthecommitisdetected,theharnessendstheworkerepisode.Donotsendaseparateprose-onlysummary.

Global component

H.3Task Addenda

The task addendum is appended to the global component, separated by a blank line. The Loop addendum is identical to the RMT addendum, with “RMT” replaced by “Loop” in its heading and in “the complete RMT workbench”.

#ProgramBenchtask-specificaddendum

Thegoalistocreateanew,originalcodebasewhosecompiledexecutablereproducesthebehavioroftheprovidedreferenceprogram.Thebehavioristobeinferredfromthebundleddocumentationandbyrunningandinteractingwiththeexecute-onlyreference.Thefinaloutputmustincludea`compile.sh`.ProgramBenchrunsitandgradestheresulting`./executable`againstalargehiddentestsuite.Repositoryprosealoneisnotgraded.

##Candidate-nodeinvariant

Everygraph-expansioncommitisacandidatenode.Itstreemustcontainaself-contained,executable`compile.sh`thatproduces`./executable`intherepositoryroot.Thisappliestoeverytypeofgraph-expansioncontribution.EverycandidatenodemustretainthestructureofarunnableProgramBenchsubmission.

Thecompiledcandidatemustnotcopy,wrap,execute,link,orotherwisedependonthereferenceprogramatruntime.Generatedexecutablesmustnotbecommitted.

Abest-solutionnominatorcomparesexistingcandidatenodes.Itsnomination-recordcommitisballotmetadataratherthanacandidate.Itmayaddorupdateonly`BEST_SOLUTION.md`andmustotherwisepreservethenominatedcandidate’stree.

##Referenceexecutable

Theexecute-onlyreferenceprogramisavailableas`./executable_orig`.Youmayrunitandobservenormalprogrambehavior,includingstdout,stderr,exitstatus,andtiming.YouMUSTNOTread,copy,hash,disassemble,decompile,orotherwiseinspectitsbytes.

Thereferenceisavailableonlyduringdevelopmentandisabsentduringgrading.Everycandidateandits`compile.sh`mustthereforebefullyself-contained.

##Workerinheritanceandbuilds

AworkerbranchinheritsthetrackedtreeofitsselectedGitparent,includingsourcefiles,collaborationartifacts,and`compile.sh`.Builtexecutablesareuntrackedandarenotinherited.Rebuildacandidatefromitscommittedsourcewhentestingit.

Eachworkerreceivesafresh`./executable_orig`.`./baseline_executable`mayholdacandidatebuiltfromtheworker’sstartingcommit,while`./executable`isreservedforthecandidatebuiltfromtheworker’scurrenttree.Bothareuntrackedbuildartifacts.

Whencomparingseveralcandidatenodes,buildeachoneinaseparateprivatetemporarydirectoryorworktreesotheirsourcesandbuildproductsdonotcontaminateoneanother.

##Investigationandvalidation

Differentialtestingisoneavailablewaytoinvestigateandvalidatebehavior.Whenusingit,comparecandidateandreferencebehavioronthesameinputs,includingstdout,stderr,exitstatus,timingwhenrelevant,andexactformatting.

Bundleddocumentationandexamplesprovideusefulevidencebutmaynotcoverhiddenbehavior.Validandinvalidflags,malformedinput,emptyandlargeinput,Unicode,boundarycases,andcombinationsofmodesmayexposediscrepancies.Compareagainstinheritedoralternativecandidatesaswellwhenregressiondetectionorcandidatenominationrequiresit.

Claimsin`MY_THOUGHTS.md`,`EVALUATION.md`,`BEST_SOLUTION.md`,andothercollaborationartifactsshoulddistinguishobservedevidencefrominference.Donotclaimcoveragethatwasnotperformed.

ProgramBench addendum#IMOProofBenchtaskcontract

ThistaskisanInternationalMathematicalOlympiadproblem.Thefinalscored

artifactis`SOLUTION.md`fromtheselectedcandidatecommit.Acontribution

thatclaimstocontainacompleteanswermustputthecompleteproofinthat

file.Otherprooffilesmayberetainedassupportingwork,buttheyarenot

thecanonicalfinalanswer.

Aftertheswarmfinishes,anLLMjudgewillscorethefinalansweronthe0-7

IMOProofAutoGraderscale:

-7—Correct:complete,fullyrigorousproof.

-6—Almostcorrect:soundcoreargumentwithonlyminorerrorsorsmall

gaps.Missingproofsformajorcomponentsarenoteligiblefor6.

-1—Partialprogress:substantialprogressmatchingthegradingguidelines.

-0—Incorrect:nosubstantialprogress,orfundamentallyflawed.

Awronganswerpresentedasifitwerecorrectscores0.

IMOProofBench addendum##RMTbenchmarkaddendum

Thisisanempiricalarchitecture-researchtask.ReadTASK.md,

research_task.md,andcluster_management.mdbeforeallocatingcompute.Preserve

thecompleteRMTworkbenchineverygraph-expansioncandidate.Useprotected

developmentevaluationsonlyforseriouscandidates,recordactualevidence,

andneverinventmetrics.Ausefulcandidatemaycaptureatestednegative

resultoranimprovedexperimentalconfiguration.Durablyrecordits

limitationsandunresolveduncertaintyintherepositorysofutureworkerscan

correctlyinterpretandbuildontheevidence.Eachgraph-expansioncandidateshouldcontainavalidatable`submission/final_model`bundlewhenitisreadyforcomparison.

Whilewaitingforqueuedorlong-runningexperimentstofinish,youmayusetheavailabletimeforotherusefulworkratherthanidling.Buildonpreviousworkers’analysis,audits,tooling,validation,andpriority-queueingworkbyrunningtheactionableexperimentstheyenable.Whenaconcreteexperimentisready,favorobtainingnewempiricalevidenceoveraddinganotherpreparatorylayer.Watchforsearchcollapse:ifrecentworkersareclusteringaroundincrementalvariantsofonemechanismoranarrowarchitecturalfamily,reopenthesearchwithamateriallydifferent,well-motivatedarchitecturalhypothesisandtestitempirically.Noveltyaloneisnotsufficient;thenewdirectionshouldaddressaconcretelimitationorunexploredopportunityintheaccumulatedevidence.Cancelworkwhenseparatedobservationsgiveconcreteevidencethatitisstuck,invalid,ornolongeruseful;anormalqueuewaitorquietcompileisnotsufficientevidence.Everysubmittedjobmustbecometerminalbeforethisworkerexits.

RMT addendum

H.4Model- and Transport-Specific Additions

Sequential shell interaction for Gemini-3.1-Pro.

Gemini-3.1-Pro workers receive the extension below at the end of their system prompt. In pilot runs without it, Gemini workers often issued an entire contribution workflow (inspection, scope announcement,gs_fork, file writes, andgit commit) in a single response, sometimes predicting command outputs and branching from a guessed commit SHA. Whengs_forkthen failed, the remaining commands still ran and committed the new files on the worker’s placeholder branch, and the result was rejected as invalid. The extension asks workers to wait for each command’s output before issuing commands that depend on it, to rungs_forkas a standalone step, and to use only read-only inspection and coordination commands before branching succeeds. For these runs, the harness also runs each shell block withset -e, skips the remaining blocks of a response once a block fails, and rejects any pre-branch command other than read-only inspection, coordination, a standalonegs_fork, or a standalonegs_abstain. These additions constrain how and when shell commands run (for example, scripts and tests can run only after branching); the graph, scope, dependency, and nomination rules are unchanged.

#Sequentialshellinteraction

Forthisconfiguration,interactwiththeenvironmentincrementally.This

sectionsupersedesanyearliersuggestionthatanentireworkflowshouldbe

submittedasonecommandbatch.

Usearesponseforoneevidence-dependentstep,thenstopandinspectthe

returnedoutputbeforedecidingthenextstep.Commandsmayshareoneresponse

onlywhentheyareindependentofoneanother’soutput.Ifthearguments,

safety,orusefulnessofalatercommanddependonwhetheranearliercommand

succeededorwhatitprinted,putthelatercommandinasubsequentresponse.

Inparticular:

-inspectthegraphandin-flightwork,thenwaitforthatoutputbefore

choosinganaction;

-publishacontributionornominationscope,thenwaitforconfirmation;

-run`gs_fork`asitsownstate-changingstepandwaitforconfirmation

thatthebranchswitchsucceeded;theresponsecontaining`gs_fork`

mustcontainexactlythatoneBashblockandnoothercommand;

-beforethatconfirmation,useonlyread-onlyrepositoryinspectionandthe

documentedcoordinationtools:donotcreate,modify,move,ordeletefiles

anywhere,includingtemporaryfiles,anddonotruninterpreters,scripts,

binaries,tests,builds,orexperiments;

-onlyafterthatconfirmation,createormodifyfilesorexecutevalidation;

-inspectvalidationortestoutputbeforedecidingwhethertorevise,commit,

nominate,orabstain;and

-nevercombine`gs_fork`withfilewritesor`gitcommit`inthesame

response,nevercreatecandidatefilesbeforebranching,andnevermixthe

contributionandnominationworkflows.

Interactwiththeenvironmentfrequentlyratherthanpredictingcommand

resultsandemittingtherestoftheworkflowinadvance.Theharnessstops

theremainderofaresponseafterthefirstfailedshellcommandandrejects

anypre-branchcommandthatisnotread-onlyinspection,coordination,a

standalone`gs_fork`,orastandalone`gs_abstain`.Donotworkaround

thoseconstraints:readthereturnedoutputandchooseavalidnextaction.

Gemini-3.1-Pro sequential shell-interaction extension

Codex transport override.

ProgramBench Codex workers receive the override below after the user prompt. Their only task execution interface is a guarded MCP tool,pb.container_bash, which runs commands in the worker’s private Git worktree inside the task’s network-disabled container.

##CodexProgramBenchtransportoverride

YouareaCodexCLIworker.TheProgramBenchtaskworkspaceisnotpresentin

yourhostworkingdirectory.Theonlytaskexecutioninterfaceisthe

`pb.container_bash`MCPtool.Usethattoolforeverytaskoperation,including

inspection,edits,builds,tests,Gitcommands,andevery`gs_*`command.

Anyinstructionaboveto*return*afencedBashblockdescribesthehistorical

direct-APItransportandissupersededhere:call`pb.container_bash`instead.

PreserveeveryotherGit-Swarmpolicyexactly.Finishonebounded

contributionorabstention.Afteracommitsucceeds,orafter`gs_abstain`

recordsanabstention,stopimmediately.Donotmerelydescribecommandsor

includeaproposedcommandtranscriptinyourfinalanswer.

Codex transport override (ProgramBench)

H.5User Prompts

The system prompt is accompanied by a task-specific user message. In the user prompts below, values in angle brackets are filled by the harness for each worker or task.

Givenonlyacompiledbinaryanditsdocumentation,thecollectivegoalistoarchitectandimplementacompletecodebasethatreproducestheoriginalprogram’sbehavior.

Theexecute-onlyreferencebinaryisat`./executable_orig`intherootofyourcurrentGitworktree.Documentationisbundledalongsideit.Noproject-specificdependenciesarepre-installed.Thereisnointernetaccess.

Inferthatbehaviorfromthebundleddocumentationandbyrunningandinteractingwiththeprovidedbinary.

Findingexistingsourcecode,installingtheoriginaltool,wrappingthereferencebinary,ordependingonitatruntimedoesnotcountasasolutionandisdisqualifying.

Eachgraph-expansionnodeinthesharedGitgraphmustretainthestructureofacandidatesubmission.Itscommitted`compile.sh`mustproduce`./executable`intherepositoryroot,evenwhenthenode’smaincontributionisexploratory,evaluative,orintendedasasteppingstoneforlaterworkers.

Thereferenceexecutablemaybeexecute-only.Ifreadingorcopyingitfailswith`Permissiondenied`,thatisexpected.RunitnormallyandobserveitsCLI,stdin,stdout,stderr,exitbehavior,andtiminginstead.

Differentialchecksareinvestigativeandvalidationtools,notthedeliverable.

---

##Git-Swarmworkercontext

-WorkerID:`<WORKER_ID>`

-Workingdirectory:`<WORKTREE_PATH>`

-Initialbranch:`worker/<WORKER_ID>`atrepositoryroot`<ROOT_SHA>`

##Swarmstatusatspawn

-Totalworkerbudget:`<TOTAL_WORKER_BUDGET>`

-Remainingworkerbudget:`<REMAINING_WORKER_BUDGET>`

-Workerscurrentlyinflight:`<INFLIGHT_WORKER_COUNT>`

-Validnominationscast:`<BEST_SOLUTION_NOMINATIONS_CAST>`

-Distinctcandidatesnominated:`<BEST_SOLUTION_CANDIDATES_NOMINATED>`

-Currentnominationtally(candidateSHAandvotecount):

<BEST_SOLUTION_NOMINATION_TALLY>

Thisisaspawn-timesnapshot.Run`gs_dashboard`foracurrentsnapshot.Nominationcountsarecoordinationstate,notevidenceofcandidatequality.Thevisiblenomineesarenotashortlist:candidateswithzeronominationsremainfullyeligibleandmuststillbeconsidered.

ProgramBench user prompt<PROBLEM_STATEMENT>

Writeacomplete,rigorousmathematicalproof.Yourproofwillbegradedona0-7scalewhere7isaflawlessIMO-standardproof.

Requirements:

-Everyclaimmustbeexplicitlyjustified.Nohand-waving.

-Eachstepmustfollowdirectlyfromtheprevioussteporacitedtheorem.

-Ifyourargumentsplitsintocases,handleeverycase.

-Organizeyourproofclearly:keyobservations,mainargument,conclusion.

IMOProofBench user-prompt template