Researchers at Google, Google DeepMind and elsewhere have released "Dream-RSI," a method that replays an AI agent's search history to improve how it conducts its next search. In a preprint dated September 14, 2026, they report that, compared with a fixed search strategy using the same Gemini 3.1 Pro, it cut the number of calls needed to find a statistical computation program by about 42.4% and also shortened the average runtime of the finished programs. The method looks back on past attempts like a "dream," but what it updates is not the model's weights. It updates the code that decides where to keep searching and when to stop. The meaning of the result becomes clearer when you separate the breakdown behind the averages from the range of history that can be replayed.
Turning past searches into a testing ground for strategies
Dream-RSI places a mechanism that allocates search effort on top of a coding agent. It decides which candidate to refine, how many different directions to try in parallel, and when to finish. This "search strategy" is expressed as executable code and rewritten repeatedly.
The cycle of generating candidate programs, running and evaluating them, and refining promising ones is also seen in AlphaEvolve, which Google DeepMind announced in May 2025. But comparing search strategies themselves requires running a long search for each one and waiting for results. On top of the computation for finding solutions, the computation for testing "how to search" also balloons.
What Dream-RSI reuses is the record left over from that process. It keeps a tree showing which candidate each one was derived from, and it also stores the code, the state of the working environment and the evaluation results. After a search strategy is changed, the tree is traversed again in a different order or with a different degree of parallelism. Decisions to cut a search off partway can be tested too. Because the results are already recorded, there is no need to regenerate candidates or run the evaluator each time a replay is done.
Next, an agent that revises the strategy rewrites the code using the replay results as clues, and the strategy that performed best on the accumulated history is put into the next real search. The history obtained there widens the range available for the next replay. Improving how computation is used while keeping the solution-generating model and the evaluator fixed is what this research means by recursive self-improvement. It was not announced as a product update to AlphaEvolve.
Reading the breakdown of the 18% average speedup
The research team examined search efficiency and the speed of the finished code using programs that compute the regularization path for Lasso, a statistical method. Lasso is used, for example, to select useful variables from among many explanatory variables. The search used 17 synthetic problems, and the resulting programs were evaluated on six datasets separate from those used in the search.
The main control is "Recursive Fixed Exploration," which does not update the search strategy. The model, evaluator, initial state and per-round resource constraints are matched, and both begin from the same hand-designed strategy. For Lasso, five rounds were run. With Gemini 3.1 Pro, the fixed search made 550 cumulative calls versus 317 for Dream-RSI, a reduction of about 42.4%.
The average runtime of the finished programs fell about 18%, from 3,587.1 ms to 2,931.0 ms. However, comparing by dataset using Figure 3(a) of the paper shows the effect is not uniform.
| Evaluation dataset | Program from fixed search | Program from Dream-RSI |
|---|---|---|
| Gisette | 1,861.8ms | 2,841.0ms |
| RCV1 | 19,550.1ms | 14,616.0ms |
| DNA | 41.5ms | 49.9ms |
| Leukemia | 26.1ms | 30.2ms |
| Colon | 14.5ms | 16.4ms |
| Duke Breast | 28.4ms | 32.5ms |
| Average | 3,587.1ms | 2,931.0ms |
Source: Dream-RSI paper v1, Figure 3(a). All figures use Gemini 3.1 Pro, evaluated on the same six datasets after five rounds of search, and are author-reported values. Lower is faster. They are not the results of independent replication.
With Gemini 3.1 Pro, average runtime fell by about 18.3%, but only RCV1 among the six datasets got faster individually; the other five saw longer runtimes.
The average reduction can be calculated by converting (3,587.1 − 2,931.0) ÷ 3,587.1 to a percentage. The reduction on RCV1 outweighs the increases on the other five, pulling the average down. The benefit one can expect from this result therefore varies with the makeup of the data being used. The average alone does not justify concluding that every Lasso workload will run faster.
With Gemini 3.7 Flash, calls fell from 3,200 to 1,879, and average runtime also decreased from 2,516.7 ms to 2,350.6 ms. Here, the method beat the fixed search on five of six datasets. The research team explains that the program obtained with Pro suited large matrices like RCV1, while the one obtained with Flash suited a broader range of problems of different sizes.
The eye-catching "about 162x" figure, meanwhile, is a comparison dividing 51,200 calls by a different discovery system, SimpleTES, by Dream-RSI's 317. The model on the SimpleTES side is GPT-OSS-120B, so the conditions differ from an experiment that changes only the search strategy with the same model. Nor can the ratio of search-agent call counts be translated into a ratio of cost or elapsed time.
Improvement on GPUs; mixed results in mathematics
In experiments generating processing code for GPUs, four KernelBench tasks were evaluated using Gemini 3.1 Pro. After confirming numerical correctness, the reciprocal of runtime was used as the performance metric. The comparison target was the same fixed search.
| GPU task | Difference from fixed search reported in the paper |
|---|---|
| VGG16 | About 2.43x fewer generations to reach equivalent performance |
| LayerNorm | About 1.79x fewer generations to reach equivalent performance |
| ConvDiv | About 2.09x the performance of the finished code at a comparable search budget |
| ConvMax | About 1.44x the performance of the finished code at a comparable search budget |
Source: Dream-RSI paper, Figure 4 and Section 4.3. The first two compare the number of generations required; the latter two compare the execution performance of the finished code.
The results show both an effect of reaching the same performance in fewer attempts and an effect of obtaining faster code with a similar trial budget. However, these four results cannot be used as a speedup rate for GPU processing in general.
On three mathematics tasks, outcomes were mixed. It beat the fixed search on the sum-difference problem and matched the best value among the paper's comparison targets on circle packing. On the autocorrelation task, where smaller values are better, Dream-RSI scored 1.456375 versus 1.456001 for the fixed search, so it fell short of the fixed search. Updating the search strategy does not necessarily give an advantage on every objective function.
An experiment comparing ways of using history is also intriguing. On ConvDiv, when past searches were summarized and instructions such as "explore this direction next" were added, both the fixed search and Dream-RSI performed worse than without such instructions. The authors point out that overly strong steering may narrow the breadth of exploration. This applies to this task and this way of giving instructions; it is not evidence that agent memory or instructions in general are useless.
What the "dream" guarantees extends only to the recorded world
During replay, Dream-RSI cannot produce results that do not exist in the history. Within a branch, results are retrieved in the order of parent-child relationships recorded in the past. When a new branch is opened, recorded candidates are referenced in sequence. Compared with a world model that predicts unknown situations, it can evaluate without guessing results, but it cannot measure the value of places not yet tried.
The scoring of strategies also involves design choices. In Section 3 of the paper, the quality of the best solution obtained is combined with a term that penalizes the number of trials and a term that rewards parallel execution. The mechanism that decides what to rate highly is fixed, and the search strategy is improved according to that criterion.
Because the current strategy is included among the candidates, the average replay score of the selected strategy does not get worse on the same history. But in a new search, the model's generated outputs can change. Non-degradation on past history is not a guarantee of performance in the next search. This constraint is why a step of repeating real searches to widen the history is necessary.
Cost, too, must be considered separately for replay and real search. Evaluation that reads out records can skip calls that regenerate solution candidates. Even so, the model processing that rewrites the strategy code, and the storing and replaying of history, consume computing resources. The cumulative call count that the paper uses as its search-cost metric alone does not settle the reduction in total cost including such processing.
As of September 21, 2026, the authors' public repository says the full code and reproduction scripts are being prepared. The paper's appendix includes the implementation of the discovered Lasso program, but that needs to be distinguished from a release that reproduces the entire pipeline from search through strategy updates.
To decide whether to adopt it, one needs to measure not only whether it improves results on one's own workloads but also the total cost including strategy revision. If those conditions are confirmed, the search records of a model already in use can serve as material for reducing future trials.