cs.LGOct 19, 2026
SaveNested Shared-Operator Recursion on ARC-AGI-1: An Empirical Study of HRM, TRM and URM
Organizations: University of Padova Padova, Italy · Universidad Politécnica de Madrid Madrid, Spain · Escuela Técnica Superior de Ingenieros de Telecomunicación Universidad Politécnica de Madrid Av. Complutense, 30 28040 Madrid, Spain · University of Rome “La Sapienza” Via Eudossiana 18 00184 Rome, Italy ·
Abstract
Recursive reasoning models refine persistent internal states by repeatedly applying learned operators. We investigate whether adding a persistent intermediate state that integrates repeated updates of a faster state through the same operator improves predictive performance relative to each model family's baseline at matched parameter counts. We define this organisation operationally and implement it within three architectures: the Hierarchical Reasoning Model (HRM), Tiny Recursive Model (TRM) and Universal Reasoning Model (URM). Using the official codebases on ARC-AGI-1, we compare each baseline with its parameter-matched nested variant. We evaluate held-out queries from tasks whose demonstrations were available during training. The experiments use a single-GPU budget far below the published training protocols. Under the tested conditions, nested variants show no consistent advantage in token accuracy, predictive loss or exact solving, which remains near zero for all configurations. The results therefore leave the hypothesis open. We specify a confirmatory comparison, with an informative baseline, multiple seeds, controls that isolate nesting and predefined criteria, to determine whether this organisation merits further development.
Figures & tables
Figure 1: Update schedules for baseline and nested configurations. Boxes denote state updates; horizontal arrows indicate execution order, not all connections between states. Blue boxes within each family share an operator; purple denotes HRM’s separate upper operator. Downward arrows mark direct input injection. (a) HRM : one H cycle contains two lower-operator applications in the baseline and twelve in the variant, organised as two lower macro-steps of six. Green brackets show differentiable applications in the final H cycle: the last L followed by H in the baseline; the last two lower-operator applications (L and M), followed by H, in C1; and all six applications of the final lower macro-step, followed by H, in C2. Input enters L updates directly, but not M or H. (b) TRM : seven shared-core applications per macro-cycle, repeated over three cycles, give 21 applications per segment. Direct input enters six updates in the baseline and four in the variant. Green brackets refer to the final cycle; the preceding two run without gradient tracking. H denotes the candidate-solution update. (c) URM : one group of six core applications is shown for each configuration. Each ACT segment executes two such groups in sequence; the first runs without gradient tracking, and all six applications in the second are differentiable.
| Configurations | Global batch size | Training budget | Available seeds | Optimiser updates |
| HRM baseline and HRM-F C2 | 48 | 61 epochs | 0, 1 | 4,886 (seed 0); 4,890 (seed 1) |
| HRM-F C1 | 48 | 61 epochs | 0 | 4,886 |
| TRM baseline and TRM-F | 32 | 50,000 optimisation steps | 0 | 50,000 |
| URM baseline and URM-F | 48 | 60 epochs | 0 | 4,807 |
| URM baseline and URM-F, extended budget | 48 | 120 epochs, trained from scratch | 0 | 9,614 |
Table 1: Training configurations and budgets for the official-codebase comparisons. For HRM and URM, an epoch denotes one shuffled traversal of the dataset groups, with one puzzle sampled per group and examples drawn from that puzzle to fill batches, rather than a full pass over all stored augmented sequences. Incomplete final batches are discarded at the end of each loader iteration, which may span multiple epochs. Optimiser updates correspond to the steps of the evaluated checkpoints.
| Evaluation | Exact-correctness criterion | Aggregation |
|---|---|---|
| Augmented-sequence exact accuracy | All valid labelled positions in a sequence are correct. | Mean over evaluated augmented sequences. |
| HRM original-task score at | Every test query of a task has its expected output among its first selected candidates. | Fraction of the 400 tasks entirely solved; solved queries are also counted globally over the 419 test queries. Assessed for baseline and C2 at seed 0. |
| TRM/URM ARC/pass@ | A query’s expected output is among its first selected candidates. | Fraction of solved queries within each task, averaged equally across the 400 tasks. |
Table 2: Exact-correctness criteria and aggregation units. These measures are not interchangeable: a global count of solved queries is not equivalent to the per-task mean used by ARC/pass@ , and neither equals the fraction of entirely solved tasks. denotes the number of distinct ranked candidates; first-candidate scores correspond to .
| Configuration | Seed | Training budget | Token accuracy (%) | LM loss |
| HRM baseline | 0 | 61 epochs | 60.60 | 1.447 |
| HRM-F C1 | 0 | 61 epochs | 40.70 | 1.982 |
| HRM-F C2 | 0 | 61 epochs | 60.33 | 1.558 |
| HRM baseline | 1 | 61 epochs | 58.06 | 1.583 |
| HRM-F C2 | 1 | 61 epochs | 42.39 | 1.933 |
| TRM baseline | 0 | 50,000 optimisation steps | 59.86 | 1.420 |
Table 3: Official-codebase results under the adopted training budgets. Parameter counts were matched within each family. Core-application counts and gradient propagation are specified separately in the methodology. Metrics are compared within families; the table does not establish a ranking across architectures. Differences reported below are calculated before rounding. Token accuracy is averaged per sequence over valid labelled positions, including grid delimiters where present. LM loss denotes predictive stablemax cross-entropy, averaged over non-ignored target positions within each sequence and then across valid sequences, using outputs from the final recurrent segment of evaluation and excluding auxiliary halting and continuation losses.
Figure 2: Token accuracy for the official-codebase comparisons on ARC-AGI-1 (Table 3). Blue denotes baseline configurations and orange denotes nested variants. (a) HRM : baseline, C1 and C2 at seed 0; baseline and C2 at seed 1. Circles denote seed 0 and diamonds denote seed 1; the dashed vertical line separates the seeds. C1 and C2 share the same forward-update schedule but differ in gradient propagation. (b) TRM : baseline and nested variant at seed 0. (c) URM : baseline and nested variant at 60 and 120 training epochs, seed 0. Vertical-axis ranges differ across panels. Token accuracy measures partial predictive correctness and is distinct from exact solving.
| Configuration | Augmented-sequence exact accuracy (%) | ARC/pass@1 (%) | ARC/pass@2 (%) | ARC/pass@5 (%) | ARC/pass@10 (%) | ARC/pass@100 (%) | ARC/pass@1000 (%) |
|---|---|---|---|---|---|---|---|
| TRM baseline | 0.01374 | 0 | 0 | 0.125 | 0.125 | 0.875 | 0.875 |
| TRM-F | 0.00052 | 0 | 0 | 0 | 0 | 0.125 | 0.125 |
Table 4: Exact prediction metrics for the official TRM comparison at 50,000 training steps, seed 0. Augmented-sequence exact accuracy requires every valid labelled position to be correct. Augmented-sequence exact accuracy is given in percent of 385,815 evaluated sequences (53 and 2 exact sequences, respectively). ARC/pass@ measures the mean per-task fraction of original queries solved by one of the first selected candidates; it does not represent the percentage of entirely solved tasks.
| Configuration | Training budget | Augmented-sequence exact accuracy (%) | ARC/pass@1 (%) | ARC/pass@2 (%) | ARC/pass@100 (%) | ARC/pass@1000 (%) |
|---|---|---|---|---|---|---|
| URM baseline | 60 epochs | 0.00259 | 0 | 0.125 | 0.125 | 0.750 |
| URM-F | 60 epochs | 0.01607 | 0.125 | 0.125 | 0.125 | 0.125 |
| URM baseline | 120 epochs | 0.01089 | 0 | 0 | 1.125 | 1.250 |
| URM-F | 120 epochs | 0.00855 | 0 | 0 | 0.625 | 0.625 |
Table 5: Exact prediction metrics for the official-codebase URM comparisons, seed 0. Augmented-sequence exact accuracy requires every valid labelled position to be correct and is expressed as a percentage of 385,814 evaluated sequences. At 60 epochs, the baseline and URM-F correctly predict 10 and 62 augmented sequences, respectively. ARC/pass@ is the mean per-task fraction of original queries solved by at least one of the first ranked candidates, expressed as a percentage; it is distinct from the percentage of entirely solved tasks. The 60- and 120-epoch results correspond to checkpoint steps 4807 and 9614, respectively.