Skip to content

Build Independently confirmed2 publishers 2 min read Published

Replaying a logged search tree cut a Dream-RSI task from 550 attempts to 317

Google and DeepMind's method records a live search, replays thousands of exploration policies against the stored results, and sends only the winner into the next run. No weights are retrained.

The Engineer · Build desk

Send a correction

Illustration accompanying Replaying a logged search tree cut a Dream-RSI task from 550 attempts to 317
Generated illustration

What happened

  • Google and Deepmind researchers introduced Dream-RSI, which reuses the data from a completed search to test alternative exploration strategies inside the space the agent has already explored.
  • After each live search the agent uses the recorded results to test better strategies and applies the improved version to its next run, leaving the model that generates solutions untouched.
  • On a statistics task with Gemini 3.1 Pro, average runtime fell from 3,587 to 2,931 milliseconds and the number of attempts dropped from 550 to 317.
  • The researchers report that a competing system, SimpleTES, needed 51,200 runs on that task against Dream-RSI's 317 attempts.
  • On two GPU kernel tasks, Dream-RSI matched the baseline's performance while cutting the number of runs by a factor of up to 2.43.

Why it matters

  • What it costs cost The discount is proportional to what one candidate costs to generate and score, so a search whose evaluator runs in milliseconds of CPU has little to reclaim by replaying it.
  • Who has to decide decision Anyone adopting this funds trace storage and a stable attempt-plus-result schema first; the log is the input to everything else in the loop.
  • What's now possible capability Exploration improvements can now ship and revert at the search layer, with no fine-tuning run and no second set of weights to keep custody of.
  • What it limits constraint Selection depends on the replay estimate agreeing with live outcomes, which makes the offline scorer a component that can quietly pick the wrong policy.

The saving comes from one substitution. A live search pays a model call and an evaluation for every candidate it considers. A replay pays for neither, because the candidate and its score are already in the log [6]. Replay tests different decisions within the recorded search tree, and the system does not invent new solutions while it runs [7].

Calling that dreaming is generous. The researchers use the word, and the agent plays through thousands of variations before selecting one for the live search [8]. It is a replay buffer with a tree index.

Data comes from the live run itself. The agent records its attempts and their results as it searches, and that record is what the replay executes against [5].

Eight tasks across three areas, with Gemini 3.1 Pro and Gemini 3.7 Flash [10]. Every comparison used a baseline with the same starting conditions and a fixed search strategy [11]. By the researchers' own account of the alternatives, a fixed strategy cannot learn from experience, so the agent may repeatedly hit the same dead ends [3]. The deltas are therefore measured against the weaker of the two exploration options they describe, and a team whose search already adapts mid-run should expect less.

Two figures moved by different amounts on the statistics task. Runtime came down 656 milliseconds, about 18 percent [19]. The attempt count came down by 233, about 42 percent [20]. If search budget is the binding constraint, plan around 42 percent; if the produced program's runtime is, plan around 18. The program the system wrote ran faster than sklearn and glmnet on all six test datasets [12].

SimpleTES supplies the largest multiple in the writeup, roughly 162 to one [21]. The-decoder's account counts runs for SimpleTES and attempts for Dream-RSI.

On GPU kernels, two further tasks delivered up to 2.09 times the performance inside the same budget [15], and math optimization work showed comparable or better results at much lower computational cost [16]. In a follow-up the researchers tried the other obvious use of a search history, condensing it into instructions telling the agent where to search [18]. The-decoder headed that section "Explicit instructions can limit exploration", and its text breaks off mid-sentence before giving the result for the one GPU task [22].

What to watch

  • Figures for Gemini 3.7 Flash; the reported runtime and attempt numbers are for Gemini 3.1 Pro.
  • A task where evaluation, not generation, is the expensive half, since replay reuses stored scores.
  • Whether runtime-scored tasks replay cleanly when a stored timing is re-measured on different hardware.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence55
Adoption12
Hype gap+20
Incentives68
Confidence58
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Researchers at Google and Deepmind have developed a method that helps AI agents tackle difficult search tasks more efficiently, using past search runs to test new strategies without repeating costly computations; the method is called Dream-RSI.

    Reported SupportedView cited source
  2. [2]

    Dream-RSI changes how the agent searches, not the underlying AI model.

    Reported SupportedView cited source
  3. [3]

    In existing approaches, a fixed search strategy cannot learn from experience, so the agent may repeatedly hit the same dead ends; adapting the strategy during a search avoids that rigidity but takes many attempts to find out whether a strategy works, and testing countless alternatives would mean repeating long, expensive runs.

    Reported SupportedView cited source
  4. [4]

    The researchers propose reusing data from a completed search to test alternative strategies within the space the agent has already explored.

    Reported SupportedView cited source
  5. [5]

    The agent records its attempts and their results as it searches, providing the data needed to replay those decisions later.

    Reported SupportedView cited source
  6. [6]

    Because those results already exist, the agent does not need to generate or evaluate solutions again during replay, avoiding the expensive computations a live run would require.

    Reported SupportedView cited source
  7. [7]

    The system does not invent entirely new solutions during replay; it tests different decisions within the recorded search tree.

    Reported SupportedView cited source
  8. [8]

    The researchers call the replay process "dreaming"; the agent plays through thousands of variations and selects the best one before putting it to work in a live search.

    Reported SupportedView cited source
  9. [9]

    The process repeats in a loop: after each search the agent uses the recorded results to test better strategies, then applies the improved version to its next live run; only the search strategy changes, and the model generating the solutions remains untouched.

    Reported SupportedView cited source
  10. [10]

    The researchers tested Dream-RSI with Gemini 3.1 Pro and Gemini 3.7 Flash on eight tasks across three areas.

    Reported SupportedView cited source
  11. [11]

    Each comparison used a baseline with the same starting conditions but a fixed search strategy.

    Reported SupportedView cited source
  12. [12]

    One task asked the system to write the fastest possible program for a statistical calculation commonly used in genomics and finance; Dream-RSI's program ran faster than the established libraries sklearn and glmnet on all six test datasets.

    Reported SupportedView cited source
  13. [13]

    With Gemini 3.1 Pro, average runtime fell from 3,587 to 2,931 milliseconds, while the number of attempts dropped from 550 to 317.

    Reported SupportedView cited source
  14. [14]

    On two GPU tasks, Dream-RSI matched performance while cutting the number of runs by a factor of up to 2.43.

    Reported SupportedView cited source
  15. [15]

    On two other GPU tasks, Dream-RSI delivered up to 2.09 times the performance within the same budget.

    Reported SupportedView cited source
  16. [16]

    The same pattern held for math optimization tasks and efforts to write efficient GPU kernels, with comparable or better results at much lower computational cost.

    Reported SupportedView cited source
  17. [17]

    Dream-RSI also outperformed a competing system called SimpleTES, which needed 51,200 runs, compared with Dream-RSI's 317 attempts.

    Reported SupportedView cited source
  18. [18]

    In a follow-up analysis the researchers tested another way to use search histories: instead of replaying them to test strategies, they condensed them into instructions telling the agent where to search.

    Reported SupportedView cited source
  19. [19]

    The runtime improvement on the statistics task was 656 milliseconds, about 18 percent of the baseline.

    Derived Supported
  20. [20]

    The attempt count on the statistics task fell by 233, about 42 percent of the baseline.

    Derived Supported
  21. [21]

    SimpleTES used about 162 times as many runs as Dream-RSI used attempts on the same task.

    Derived Supported
  22. [22]

    The-decoder's section on the follow-up analysis is headed "Explicit instructions can limit exploration", and the published text breaks off mid-sentence at "On one GPU task, the version with".

    Reported ContestedView cited source

Sources

2 independent publishers whose own reporting we read for this story.

  1. arxiv.org

    1 article · September 19, 2026

    Dream-RSI: Recursive Self-Improvement through Evolving Worlds
  2. the-decoder.com

    1 article · September 19, 2026

    Google Deepmind's Dream-RSI helps AI agents improve by “dreaming” about past attempts

Topics and entities

Topics