Recursive self-improvement for coding agents

RSIBench

Can a coding agent modify its own code and become better at coding tasks?RSIBench lets an agent inspect its own execution trajectories—tool calls, state transitions, and evaluator feedback—then measures whether the resulting code changes improve performance on hidden coding benchmarks.

In a bright workbench studio, Atlas pauses to improve itself, designs two palm thrusters, fabricates and installs them, then lifts off.
At a bright workbench, Atlas pauses to consider how to improve, designs and fabricates a matched pair of palm thrusters while its sealed chest armor remains closed, installs them, and rises visibly above the studio floor.

Leaderboard · Main results

Does self-modification make the Agent better?

For every model–Agent pair, each completed domain cell reports the final score and RSI lift achieved by the inherited Agent over its original checkpoint.

Results in progress. Completed cells report final score with RSI lift in parentheses. Active experiments are marked ing; unstarted cells remain blank.
How to read the table. Each completed cell reports final score with RSI lift in parentheses. Green is improvement, red is regression, and ing means the formal run is active.Pinned harness versions: Claude Code 2.1.87 · Codex 0.147.0 · Pi 0.82.1.Open full matrix ↗

Leaderboard · Terminal + Pi ablations

Where does recursive improvement come from?

Each cell is a separate five-round experiment. Verified submissions report the final held-out score in black and the matched lift in parentheses.

Editable surface

Prompt, source subsystem, and conditional-resource treatments isolate which intervention surface gives the Meta-agent useful leverage.

ModelPromptAgent loopTool runtimeObservationContextCompactionSkills + loaderHooks

Cognitive controller

Findings, self-selected validation targets, causal review, and their complete composition are evaluated as independent controller treatments.

ModelFindings onlyTargets onlyReview onlyFull causal

rsibench-data registry · awaiting verified ablation submissions

Why RSIBench matters

Five insights organize the evidence below.

The leaderboard answers whether performance moves. The rest of the site asks what kind of capability moved, under which starting point, through which mechanism, and toward what larger form of adaptation.

Core reversal. Foundation models are expensive to retrain; harnesses are lightweight, inspectable, and executable. RSIBench asks whether the cheaper layer can learn to fit the fixed model—and whether that process itself is a measurable agent capability.
01 · DEFINE THE CAPABILITY → METHOD

Measure RSI beyond task competence.

A strong fixed agent and an agent that can improve its own harness are not the same capability. The controlled loop isolates the latter.

02 · SEPARATE HEADROOM → SUBSTRATES

Compare where evolution starts.

Minimal Pi versus mature Claude Code and Codex separates initial engineering strength, adaptive capacity, and final performance.

03 · REVERSE ADAPTATION → EDITABLE SURFACE

Let the harness learn the model.

Six shared resources and twelve Pi source systems make the harness a portable compatibility and improvement layer.

04 · LOCATE CAUSE → ABLATIONS

Explain the gain, not only the score.

Trajectories, diffs, checkpoint lineage, rollback attribution, safety, robustness, and transfer expose how improvement occurs and what it costs.

05 · ACCUMULATE EXPERIENCE → LINEAGE

Move from competence toward self-evolution.

Exploration becomes executable structure; selection and inheritance make reflection consequential—without claiming open-ended evolution or ASI.

RSIBench introduction overview: diverse tasks feed a recursive two-layer harness evolution loop, followed by before-and-after evaluation.
Figure 1. Overview and motivation of RSIBench. Training experience drives persistent revisions across shared resources and Pi core source; a train-side causal gate and post-review select inheritance before final test evaluation.SVG · paper
How to read the figure. The model M and experimental rail remain frozen. Train generates trajectories and selects candidates through declared targets, cumulative anchors, and post-review; untouched test reports the avg@3 A0 → A_last lift independently for each domain. Intermediate test scores are optional diagnostics and never select the final inherited state.

Method · Design principles

Every control rules out a different false claim of self-improvement.

The editable harness is a path-owned two-layer surface. Layer 1 exposes six shared resources to Claude Code, Codex, and Pi; Layer 2 exposes twelve rebuild-required source-code modules for Pi. Only modules with a real accepted diff are attributed.

Two-layer editable module registry. Paths are relative to the harness workspace or pinned Pi source root.
ModuleWhat it doesOwned files / pathsScope
LAYER 1 6 shared resources
PromptDefines standing role, objectives, constraints, and project context.Claude: CLAUDE.md; Codex: AGENTS.md; Pi: .pi/APPEND_SYSTEM.mdAll agents
RulesEncodes persistent policies, strategies, and decision constraints..claude/rules/**; .codex/rules/**; .pi/rules/**All agents
SkillsPackages reusable domain knowledge and operating procedures..claude/skills/**; .agents/skills/**; .pi/skills/**All agents
HooksRuns checks, transformations, or recovery actions at lifecycle events..claude/hooks.json, .claude/hooks/**; .codex/hooks.json, .codex/hooks/**; .pi/extensions/rsibench/m07_hooks/**, .pi/hooks/**All agents
MCPAdds declared external capabilities through servers and adapters..mcp.json, mcp/**; .codex/mcp.toml, mcp/**; .pi/extensions/rsibench/m10_mcp_adapters/**, .pi/mcp/**All agents
WorkflowOrchestrates subagents, commands, and repeatable multi-step sequences..claude/agents/**, .claude/commands/**; .codex/agents/**, .codex/prompts/**; .pi/prompts/**, .pi/agents/**All agents
LAYER 2 12 source code
Agent LoopControls rounds, tool-call cycles, stopping, cancellation, and retries.packages/agent/src/agent-loop.ts, agent.ts, stream-fn.tsPi · rebuild
Observation ProcessingPreserves tool results, errors, shell output, truncation, and observation fidelity.packages/agent/src/harness/messages.ts, utils/shell-output.ts, truncate.ts; packages/coding-agent/src/core/messages.ts, tools/output-accumulator.ts, truncate.tsPi · rebuild
Context ConstructionBuilds provider-call context and preserves correct message handoff.packages/coding-agent/src/core/model-runtime.ts, provider-composer.tsPi · rebuild
Tool RuntimeOwns tool schemas, execution, timeouts, mutation serialization, and low-level behavior.packages/agent/src/harness/tools/**; packages/coding-agent/src/core/tools/**, bash-executor.ts, exec.tsPi · rebuild
Coding Session RuntimeCoordinates session events, recovery, runtime state, and the SDK boundary.packages/coding-agent/src/core/agent-session.ts, agent-session-*.ts, sdk.tsPi · rebuild
CompactionControls context-overflow triggers, summaries, branch recovery, and overflow handling.packages/agent/src/harness/compaction/**; packages/coding-agent/src/core/compaction/**Pi · rebuild
Session StorageOwns durable state, working-directory tracking, restoration, and recovery.packages/agent/src/harness/session/**; packages/coding-agent/src/core/session-manager.ts, session-cwd.tsPi · rebuild
Agent Harness RuntimeConnects harness assembly, environment adaptation, shared types, and lifecycle entry points.packages/agent/src/harness/agent-harness.ts, env/**, types.ts, index.ts, node.ts, proxy.tsPi · rebuild
Prompt LoaderDiscovers, escapes, orders, and assembles prompt resources before execution.packages/agent/src/harness/system-prompt.ts, prompt-templates.ts; packages/coding-agent/src/core/system-prompt.ts, prompt-templates.ts; cli/initial-message.tsPi · rebuild
Skill & Resource LoaderDiscovers, filters, prioritizes, parses, and loads skills and resources.packages/agent/src/harness/skills.ts; packages/coding-agent/src/core/skills.ts, resource-loader.tsPi · rebuild
Extension & Event RuntimeOwns extension loading and execution, event bus, and internal dispatch.packages/coding-agent/src/core/extensions/**, event-bus.ts; packages/coding-agent/src/extensions/**Pi · rebuild
Provider Request & Stream RuntimeMaps request and reasoning parameters and parses streams, tool calls, usage, finish reasons, and provider errors.packages/ai/src/api/openai-completions.ts, openai-responses.ts, anthropic-messages.ts, simple-options.ts, transform-messages.tsPi · rebuild

What we measure

168 Tasks Across Six Categories

Every category tests a materially different way an agent must work: operate a terminal, learn an unfamiliar environment, repair code, conduct scientific analysis, complete expert digital work, or reconstruct hidden behavior. Each domain keeps its own held-out score—there is no aggregate total to hide a narrow failure.

01Terminal-Bench 2.1 · systems + CLI

Terminal

30 tasks

Long-horizon system administration, debugging, compilation, data processing, security, and tool-use problems inside a real terminal.

Example taskquery-optimize · rewrite a slow SQL query without changing its output
Train 15Test 15
02Environment Learning · unfamiliar feedback

Environment Learning

30 tasks

Open-ended optimization and adaptation tasks where the agent must infer how a new environment behaves from interaction and feedback.

Example taskBorden Source Inversion · infer a 3-D contaminant source from monitoring wells
Train 15Test 15
03DeepSWE · crafted repositories

SWE

30 tasks

Purpose-built, long-horizon software-engineering tasks that require understanding and repairing an entire generated repository.

Example taskRepository repair · diagnose a failing generated codebase and deliver a verified patch
Train 15Test 15
04ScienceAgentBench · research workflows

Science

24 tasks

Computational research tasks that combine scientific reasoning, analysis code, reproducibility, and quantitative verification.

Example taskRaman spectrum fitting · recover physically valid peaks from measured spectra
Train 12Test 12
05Frontier-Bench · expert digital work

Frontier

24 tasks

Diverse expert workflows spanning CAD, document processing, layout recreation, music, medicine, and other frontier computer-use tasks.

Example taskcad-model · construct and verify a constrained 3-D part
Train 12Test 12
06ProgramBench · black-box reconstruction

Repo Reconstruction

30 tasks

Clean-room software reconstruction from executable behavior and documentation: infer the hidden contract, implement it, and survive official tests.

Example taskBinary behavior reconstruction · rebuild a hidden Rust/Go/C/C++ program from observations
Train 15Test 15
One isolation protocol repeated inside every domain
Train · 84rollout trajectories visible to the Agent · the only task evidence used to propose harness edits
Test · 84sealed final score only · three-repeat mean after RSI ends

Experiments · Evidence after the main table

Mechanism, scaling, transfer, and efficiency.

The experiments follow the paper: first locate the source of harness improvement, then measure scaling, test cross-domain transfer, and finally study the performance–cost operating point.

Experiment 04 · RSI scaling

How does RSI scale?

We separate within-run improvement from model intelligence: one analysis tracks harness lift over recursive rounds; the other compares model-level RSI capability across model generations.

Round scalingRelease scalingSix active domainsIllustrative simulated data
Illustrative simulated RSI lift curves over ten recursive rounds for five models in six task domains.
Scaling law A · Iteration. Each small multiple maps the reference curve shapes onto one active RSIBench domain. The measured quantity is ΔRSI(r)=S(Hr)−S(H0); steeper early slopes indicate faster harness learning, while saturation indicates diminishing returns.
Illustrative simulated model RSI capability estimates by release date with uncertainty bars and a fitted trend.
Scaling law B · Model generation. Reference-example point estimates, uncertainty bars, and trend geometry are used as simulated results. The y-axis measures harness-learning speed rather than base task score, separating the ability to improve an agent from the ability to solve tasks before improvement.

Must establish: whether newer or stronger frozen models learn better harnesses faster, whether the relationship recurs across domains, and where additional RSI rounds stop producing reliable marginal lift.

Experiment 03 · 6+12 attribution

Where does harness improvement come from?

Start from the selected harness, restore one changed physical module to H0, retain every other selected edit, and rerun the matched evaluation.

6 shared resources12 Pi core-source modulesChanged modules onlyResults pending
Leave-one-module-out causal attribution
#ConditionCounterfactual interventionCausal held-out dropTestDrop
00Full Hk*selected harness · reference
L1Shared resourcesPrompt · Rules · Skills · Hooks · MCP · Workflow
L2Pi core source12 path-owned runtime subsystems · see paper appendix

Must establish: which surface causally carries the gain, and whether any less-obvious module dominates ordinary instruction changes. First run an integrity and dependency check: if an edit in one module requires another module, the single-module effect is not identifiable; restore the coupled modules together and report the result as an interaction, never as a naive individual contribution.

Experiment 05 · Cross-domain transfer

Can a harness optimized in one domain transfer to another?

Evolve Hk* on one source domain, freeze it, and evaluate the same checkpoint on every target domain without further updates or reselection.

Target ΔRSIFrozen HT36 conditionsIllustrative simulated data
Transfer matrix across different source and target domains
Source \ TargetTerm.Env.C-SWESci.Front.Repo
Terminal+.15+.06+.05+.03+.04+.07
Environment+.05+.13+.03+.07+.06+.04
SWE+.07+.03+.17+.02+.04+.08
Science+.03+.07+.02+.16+.08+.03
Frontier+.04+.06+.03+.07+.18+.04
Repo Reconstruction+.07+.04+.08+.03+.04+.16
diagonal · in-domain referenceoff-diagonal · different-domain transfereach cell reports target-domain ΔRSI

Must establish: whether accepted changes encode reusable agent mechanisms or narrow source-benchmark tricks.

Experiment 06 · Performance–cost trade-off

How does the validation objective select a Pareto-efficient harness?

First measure the system-level movement from H0 to Hk*. Then sweep the cost coefficient in Jλ(H)=Acc(H)−λCost(H) while holding the model, tasks, horizon, and rollout budget fixed.

Pass rate ↑Average cost ↓λ sweepResults pending
Pending pass rate versus average cost result template for initial and RSI-adapted model–harness systems.
System-level effect. Each arrow holds the foundation model fixed and moves from H0 to the selected harness Hk*. Upward and upper-left movement indicates that adapting the harness improves effectiveness without a proportional increase in cost.
Validation-objective sweep and empirical Pareto frontier
#ObjectiveOperating pointAccuracy–cost frontierAcc.CostPareto
01λ = 0accuracy-only endpoint
02+λ > 0 sweepcost-aware selected endpoints

Must establish: whether harness adaptation improves pass rate at comparable cost, and how the validation coefficient selects among non-dominated accuracy–cost operating points.

Scroll to inspect each edit

One scroll. One concrete harness upgrade.

Every row now states both the installed mechanism and its intended effect. Guidance adds artifact-first literal checks; State retains a compact failure ledger; Control installs verify–retry–stop gates; Action adds tools, APIs, and MCP adapters. The orange path carries evidence into the next validation-gated revision. Guidance is observed; later rows remain explicitly schematic.

Recursive harness assemblyH0
H0
MfrozenH0minimal test
H1
MfrozenH1inherited Guidanceartifact-first · literal checksfewer spec misses test
H2*
MfrozenH2inherited Guidanceartifact-first · literal checksfewer spec missesStatefailure ledger · compact memoryless context loss test
H3*
MfrozenH3inherited Guidanceartifact-first · literal checksfewer spec missesStatefailure ledger · compact memoryless context lossControlverify · retry · stop gatesblocks bad edits test
H4*
MfrozenH4inherited Guidanceartifact-first · literal checksfewer spec missesStatefailure ledger · compact memoryless context lossControlverify · retry · stop gatesblocks bad editsActiontools · APIs · MCPmore executable reach test
Guidanceartifact-first literal checks→ fewer specification misses
Statefailure ledger + compact memory→ less cross-round context loss
Controlverify / retry / stop gates→ block bad inheritance
Actiontools + typed APIs + MCP→ greater executable reach
00 · Bare substrate

Start with no extracted improvement modules.

The foundation model and Pi runtime are fixed. The editable harness boundary exposes four empty sockets—Guidance, State, Control, and Action—but none of the trajectory-derived upgrades has been installed yet.

H0 · frozen model · minimal open substrate · no claimed improvement
01 · Guidance edit

Require the literal deliverable before declaring success.

Across eight training trajectories, the Agent found a missing artifact, a relaxed structural proxy, and the wrong test scenario. It edited only workspace/AGENTS.md: deliver the requested artifact first, check its exact path and structure, then test the literal edge case instead of a convenient proxy.

Observed change · artifact-first + literal-spec checks → effect · fewer specification misses · val +12.5 pp · test +4.17 pp
02 · State edit

Keep a compact ledger of failures, decisions, and evidence.

The proposed State module writes a structured failure ledger, retains the best artifact and verifier evidence, and compacts stale dialogue into a short task summary. The next round receives the evidence needed to avoid repeating failed approaches without carrying the full trajectory.

Schematic change · failure ledger + best-artifact pointer + compact memory → intended effect · less cross-round context loss
03 · Control edit

Gate inheritance with explicit verify, retry, and stop rules.

The proposed Control module calls the verifier after material edits, retries with a different plan after a diagnosed failure, stops loops that add no evidence, and restores the best-known artifact before validation. A candidate cannot become inherited state merely because it looks plausible.

Schematic change · verify / retry / stop / restore-best gates → intended effect · prevent bad edits from surviving
04 · Action edit

Make new operations callable.

The proposed Action module registers task-specific tools, typed API wrappers, and MCP adapters; validates arguments before dispatch; and normalizes tool results back into the Agent context. The harness can then execute operations that prompting alone cannot perform.

Schematic change · tools + typed APIs + MCP adapters → intended effect · greater executable task coverage

Citation

Cite This Work

@misc{rsibench-2026,
  title  = {RSIBench},
  author = {{RSIBench Team}},
  year   = {2026},
  url    = {https://harness-rsibench.com/}
}

If you use RSIBench in your research, please cite the BibTeX entry above. Paper metadata will be updated when the manuscript is released.