Dream-RSI: Google's Recursive Self-Improvement Paper Cuts Search Calls Without Changing Model Weights

Dream-RSI is a framework from Google, Google DeepMind and two universities that improves how a coding agent explores, not the model itself. On a Lasso solver task, the paper reports 317 discovery-agent calls against 550 for its fixed-exploration baseline, and an average downstream runtime of 2931.0 ms against 3587.1 ms. The preprint, arXiv 2609.14858, was posted on 14 September 2026, and its code was still unreleased as of 16 September 2026.

What problem does Dream-RSI solve?

Dream-RSI targets the exploration policy: the rule that decides which attempts a coding agent continues, how many run in parallel, and when it stops. The authors argue that fixed exploration rules cannot adapt as search spaces grow, and that tuning those rules online is slow. A candidate policy only earns feedback after a lengthy run, which makes trial and error costly.

The paper names two bottlenecks. The first is cost: a policy's quality shows up only after many rounds of proposing and scoring candidates. The second is breadth: the set of possible policies is large, and many of them may need trying. The paper's introduction presents these as the reason meta-level improvement has been expensive.

How does the replay simulator work?

Dream-RSI runs three stages in a loop. It explores online, saves the result as a tree, and then scores new policies against that saved tree without launching new discovery runs.

1. Online exploration. A live search run starts from the policy in force, and each attempt with its result goes into a log.
2. Simulator construction. Each finished tree joins a pool that the system keeps growing.
3. Dreaming-based policy improvement. Each candidate is scored by replay, and the top scorer goes live in the following round.

In replay, selecting a node reveals whatever the original run stored beneath it, so the system never produces a new candidate. The paper grades each replay on three things: the top solution it reaches, a penalty per attempt it reveals, and a reward for running attempts in batches. The selection step always keeps the incumbent policy in the running, so the winner matches or beats it on the recorded history, according to the authors.

Do the model's weights change?

No. The loop edits one artifact, the code that sets the search strategy. The discovery model, the scorer and the execution layer are kept as they were.

Site analysis: "recursive self-improvement" in this paper refers to the policy loop, not to the model improving its own parameters. Readers comparing it with work that updates weights should keep that distinction in mind.

What are the Lasso results?

On the Lasso regularization path task, Dream-RSI reached lower average downstream runtime than the fixed-exploration baseline while using fewer discovery-agent calls, for both Gemini models the paper tested. The figures below are the authors' own, from Section 4.1 of the paper.

Discovery ran on 17 synthetic instances. The authors then tested the solvers on six datasets they had not seen during discovery, drawn from biology and other fields. They also report that their solvers beat sklearn and glmnet on every one of those six held-out sets.

How many fewer calls does Dream-RSI use than SimpleTES?

The paper reports up to 162 times fewer discovery-agent calls than SimpleTES on the Lasso task. Against the paper's own fixed-exploration baseline, the reduction is 1.7 times.

The two systems use different base models and budgets, so the 162x figure measures call counts, not equal-cost accuracy. The 1.7x comparison is cleaner, since both arms keep the discovery agent, scorer, starting point and budget identical, according to the authors.

What do the math and kernel results show?

On three mathematical tasks, Dream-RSI gains over fixed exploration are small, and it trails SimpleTES on one task. On four GPU kernel tasks, the authors report that two tasks need fewer generations to reach the same level, and two score higher at a similar budget.

The authors concede that SimpleTES posts the strongest autocorrelation score, and that it got there with 51,200 generations. Dream-RSI's own run stayed below 1,000. For the kernel tasks, the paper compares against Recursive Fixed Exploration under matched conditions:

Can you reproduce Dream-RSI yet?

Not from the released code yet. The official repository links the paper PDF and project page, and lists the rest of the release as in preparation.

The experiments run Gemini models through the Gemini CLI, so reproducing the numbers also needs access to those models. The paper points to its implementation of the discovered solver in Appendix C.

What's still unclear?

• Read status. This article covers the v1 arXiv abstract page and the v1 HTML text through Section 4. The full PDF, Sections 5 to 7 and the appendix contents were not read, and no claims are drawn from them.
• Task count. The body text counts eight discovery tasks in three domains. The v1 abstract page, by contrast, gives nine tasks in four domains. This article follows the body text.
• Version. This article covers v1 only; a later version may differ from the text discussed here.
• Noise. The result tables show one value per configuration, with no error bars. The autocorrelation gap between Dream-RSI and fixed exploration is 0.000374, which is too small to read without repeated runs.
• Autocorrelation. SimpleTES scores better here, with far more generations.
• Replay limits. Outcomes that the original run never recorded are unavailable to replay. Site analysis: a policy that would open branches the original run never explored cannot be scored.
• Guarantee scope. The selection guarantee holds on the recorded history. Site analysis: the policy is chosen on the same history it is scored on, so the guarantee speaks to past runs, not to new search spaces.
• Model scope. The discovery agents reported in the paper are Gemini models only.
• Weakest point (site analysis). The headline 162x depends on comparing Gemini runs against a different base model and budget. The strongest evidence is the 1.7x comparison, on one task family, from single runs.