← blog How to benchmark RSI

How to benchmark RSI

How much of realistic LLM training do today's benchmark environments cover?

Recursive self-improvement (RSI) could have major consequences for AI development, yet its definition, its possible forms and its measurement remain open questions. Recent reports from Anthropic, OpenAI and Z.ai describe AI systems taking on parts of model research and infrastructure engineering, which makes these questions increasingly practical. Whatever definition settles, the ability to train and improve AI models is a core capability worth evaluating. For RSI that runs through model training, this capability is necessary but not sufficient. One way to evaluate progress toward RSI is to ask an AI system to develop and train a model end to end and deliver it ready for real-world use. At production scale, such an evaluation would be expensive in both compute and time. We therefore examine whether existing coding-agent benchmarks provide practical tests of the capabilities this process requires, and which capabilities their environments leave untested.

Meanwhile, coding benchmarks such as SWE-Bench Pro, Terminal-Bench, DeepSWE and ProgramBench assess progress in coding agents, and executable task environments of the same kind also support agent training. How well these environments represent the work of developing production LLMs is therefore an important question. This post audits selected tasks and documented environments from ten benchmark suites against eighteen documented model-development pipelines; the task inventory and the method and sources are given below. We identify relatively few tasks involving LLM infrastructure in the general-purpose benchmarks examined. The specialized benchmarks provide substantial training and inference coverage, but the audited tasks largely test individual components or bounded experiments, leaving gaps in coordinated, end-to-end workflows, particularly distributed agentic RL and recovery from failures.

01

Where public benchmark environments land

Of the 537 public tasks in ten benchmark suites, 97 touch the LLM life cycle at all. They appear here as 74 entries, since task families count once, placed on the surface production pipelines run: five life-cycle stages by seven infrastructure layers, 35 cells in all. The bars score how much of that surface each benchmark's verifiers reach, weighted by how deeply; hover a mark for its cell.

hover a mark for the cell · select a name for the benchmark
real LLM workload executed · 1 bounded unit or artifact tests · ½ related or simulated · ¼ untouchedbar = weighted score · marks = which cells
Task-level view: every audited task by stage and benchmark

Every audited task is a dot at the stage its verifier reaches; a task that touches two stages appears twice. Color is evidence depth; family entries count once; supplemental benchmarks were not task-audited and appear as rings.

Audited task entries by stage and benchmarkhover a dot · select for detail
Table view
02

The life cycle, as production pipelines run it

A filled mark means public code or a released recipe exists for that stage; a ring means a report only. Hover a mark for the source's own vocabulary; select a row to read its stage names in order. Continued pretraining and long-context extension share the pretraining objective, so they sit inside that column; older reports are hidden behind the toggle.

Documented life cycles
Stage names differ (OLMo says midtraining, Llama 3 says annealing, MiMo-V2.6 says agent-centric mid-training), but the shape is shared: a corpus, one long run with continuation phases, rounds of SFT, preference, RL and increasingly on-policy distillation, and a serving system that also produces RL rollouts. Only Llama 3, LLM360 and MiMo-V2.6 publish failure statistics.
Table view

Where the public code lives

Frameworks that implement each stage. Every stage has open code, including on-policy distillation; what is thin is any account of operating that code across nodes and through failures. Select a chip for detail.

03

Stages × infrastructure layers

A cell counts the distinct task entries whose verifier reaches that stage and layer, colored by the strongest evidence; family entries count once. Filter by benchmark, then select a cell for the conditions an evaluator would still have to test and the evidence behind the count.

04

Sources, verification tags and method

Show sources, tags and method

Companion pages: the RL loop · post-training recipes · agentic RL infrastructure · notes · data bundle · built from source snapshots of 5, 21, 22 and 23 September 2026.

Every claim on this page carries one of these tags. spot-checked was re-read on the primary page in this workspace; note 2026-09-21 and prior note come from the workspace's pinned companion notes; agent-reported comes from a delegated sweep and should be re-read before it is quoted in a paper.

  • Benchmark versions and commits are pinned; Terminal-Bench 2.1 and 4.0 share no tasks.
  • CPU simulation, real-GPU execution and multi-node verification are kept separate.
  • A missing repository match is never turned into a universal absence claim; this is a curated audit, not a census.

Scale's RSI Bench (2026) is a different project from the RSI-Exam audited here.