waytoRSIRecursive self-improvement, examined
Back to latest

Dream-RSI: Turning Past Searches into Tests of Search Strategy

Recorded attempts let policies test different continuations without repeating discovery. The Lasso results show why fewer search calls and faster solver execution must be read separately.

A discovery agent can keep refining one candidate or open another branch. Evaluating that choice online can require an entire costly rollout before the strategy's value becomes clear. Dream-RSI makes completed searches reusable: another policy can be tested by revealing saved attempts in a different sequence, without generating and evaluating those attempts again. One online search can therefore support many low-cost policy evaluations. Motivation and replay mechanism, §2

The distinction that matters is between the recorded search held by the replay system and the observations available to the policy. The system has the saved outcomes; the policy must still make decisions before those outcomes are revealed. This account uses arXiv v2, revised on October 6, 2026. Replay rules, §3 Version history

One tree, two continuations

During online discovery, the root represents the initial workspace. Each attempt resumes its parent's saved workspace, inherits accumulated observations and becomes a node retaining generation history, its own filesystem snapshot, observations and an evaluator score. Replay later exposes those records incrementally while leaving the recorded tree unchanged. Discovery-tree construction, §3

Consider the illustrative tree below: root→A1→A2 and root→B1→B2, with A1 created before B1. Replay begins with root alone. Selecting root once reveals A1. The figure pauses at this common starting state: both policies have seen only root and A1, and can choose either root or the current leaf A1.

  • P selects A1. A non-root selection follows that node's unique recorded child, so the replay reveals A2. P now observes A1 and A2; B1 and B2 remain hidden.
  • Q selects root again. Root opens its earliest-created child that is still unrevealed, so the replay reveals B1. Q now observes A1 and B1; A2 and B2 remain hidden.

Q cannot ask root to choose any branch or skip to B2. B2 belongs to B1's recorded continuation. The dashed placeholders show the reader the structure of this example; they do not give either policy advance access to those observations or scores. Decision interface and deterministic replay transitions, §3

Both policies start with only root and A1 revealed. P selects A1 and reveals A2; Q selects root again and reveals B1 in historical creation order. P cannot see B1 or B2 observations, while Q cannot see A2 or B2 observations. Each history represents two discovery calls.

waytoRSI editorial mechanism illustration, not primary experimental evidence or an actual experimental trace. A1, A2, B1 and B2 are illustrative labels. No measured scores are supplied, and the figure does not rank P and Q.

Each illustrated history contains two revealed attempt records: the shared first record A1, then either A2 or B1. It therefore represents two discovery calls, with no call counted for root. Replay does not execute those discovery or evaluation requests again. The equal count makes the difference concrete: continuing a branch and opening another branch can expose different evidence at the same represented search effort.

The freedom is in how deeply to continue, when to open a branch, which attempts to group in parallel and when to stop. The saved paths constrain every choice. An exhausted continuation returns an empty result; replay cannot supply an outcome that the original search never recorded. Replay scope and call accounting, §3

The replay objective evaluates attained quality against represented discovery-call count across budget preferences. It also penalizes completed sequential rounds per call, favoring parallel execution. Reusing an outcome avoids executing it again, but the represented call still counts in this quality–cost comparison. Replay objective, §3

A fixed policy-development agent inspects replay trajectories and scores, then rewrites executable exploration-policy code. The discovery agent, models, evaluator and execution interfaces stay fixed. Candidate versions are evaluated across the accumulated historical trees, and the selected version returns to online discovery. Its completed new tree joins the history pool for the next round of replay. Policy revision and deployment loop, §3

Keeping the incumbent among the candidates gives a precise safeguard: on the identical fixed pool H_t, the selected policy's mean replay score cannot be lower than the incumbent's. This does not guarantee non-decreasing scores when the pool changes, or monotonically better future online searches. Online discovery is stochastic and can produce different outcomes from the same workspace; replay follows the outcomes already saved. Online transitions and selection guarantee, §3

The supported RSI claim is repeated revision of exploration-policy code under fixed models and evaluators. This mechanism and the Lasso results below do not establish general recursive improvement of AI capabilities.

Fewer search calls, with gains that depend on the workload

The Lasso experiment searches for numerically correct regularization-path solvers on 17 synthetic instances. Six held-out downstream datasets evaluate the resulting programs. These roles are distinct: the synthetic instances supply the search tasks, historical trees supply replay feedback for policy selection, and the held-out datasets measure downstream solver performance. Lasso protocol, §4.3 Policy selection, §3

Both Dream-RSI and Recursive Fixed Exploration run for five rounds with the same discovery agents, evaluators, initialization, per-round budget limits and starting policy. They behave identically in round one. From round two onward, Dream-RSI revises its policy through replay while the baseline keeps its policy fixed. The Gemini-3.1-Pro results are: Controlled setup, §4 Figure 4 and results, §4.3

Gemini-3.1-Pro, five rounds Recursive Fixed Exploration Dream-RSI
Cumulative discovery-agent calls 550 317
Final solver mean runtime, six held-out datasets 3587.1 ms 2931.0 ms
Final solver runtime, RCV1 19550.1 ms 14616.0 ms
Final solver runtime, Gisette 1861.8 ms 2841.0 ms

The first row measures search effort. The other rows measure how long the discovered program takes to run, not how long it took to discover that program.

The paper itself explains the distribution: RCV1 drives the lower Pro mean, while the Dream-RSI solver is slower on all five other held-out datasets. RCV1's absolute saving outweighs those five increases in the arithmetic mean. For a later deployment decision, choosing a program solely by the average across these six evaluation datasets would select the slower one for Gisette. That conditional implication follows from the reported table; it does not describe the search or replay-selection procedure. The authors' task-level analysis, §4.3

The roughly 162-fold comparison is 51200/317: SimpleTES's reported 51200 generations with gpt-oss-120b divided by Dream-RSI's 317 discovery-agent calls with Gemini-3.1-Pro. Relative to the controlled 550/317 comparison, the numerator and comparison system change; the denominator remains 317. Different backbones prevent attributing the whole ratio to replay. Neither this ratio nor the controlled 317-versus-550 count establishes an equivalent reduction in total tokens, spending or end-to-end discovery time. Final solver runtime remains a separate quantity. Compute definition, §4 SimpleTES comparison, §4.3

The next evidence belongs to online discovery

The reported experiment already includes six held-out downstream datasets. Further evidence should show whether revised policies sustain lower discovery effort and useful gains task by task as they generate fresh online outcomes beyond their replay history. That would test the step from selecting on saved experience to conducting another search.

Public reproducibility is the other outstanding step. In the official repository snapshot retrieved on October 23, 2026, the full codebase and reproduction scripts are both marked “Being prepared.” This article presents author-reported results and provides no independent replication results. Releasing the full codebase and reproduction scripts would make the comparison between revised and fixed exploration easier to reproduce. Dated release plan Online discovery loop

Go to the source

  1. Dream-RSI paper v2
    Citation & version

    https://arxiv.org/html/2609.14858v2 | L81-L237

  2. Dream-RSI version history
    Citation & version

    https://arxiv.org/abs/2609.14858 | L8-L28

  3. Dream-RSI official release status, retrieved 2026-10-23
    Citation & version

    https://github.com/zhengkid/Dream-RSI | L200-L242

Back to the top
Updated Oct 24, 2026

Keep reading

Strategies & meta-improvement

Why DGM keeps agents that score worse

A still-editable child can become a useful parent despite a score dip. DGM's controls, benchmark protocols and a logging bypass explain how to interpret that contribution.

Topics in this article

Recursive self-improvement Search policy

Figure detail

Scroll to explore the full figure. Press Esc or Close to return to your place.