Researchers at Google, Google DeepMind, the University of Maryland, and the University of Virginia posted Dream-RSI, a paper on arXiv, with code on GitHub and a project site. The idea underneath it is genuinely elegant. When an agent burns thousands of calls hunting for a faster algorithm, the tree of everything it tried — each attempt, its parent, its workspace snapshot, its score — isn't just a log. It's a free simulator of the part of the search space that was actually visited. Run a different search strategy inside that recorded tree, reveal the outcomes already stored along whichever branches it picks, and you learn how that strategy would have done without calling the coding agent or executing a line of code. The authors call this "dreaming," after the Dreamer line of model-based RL, and they use it to improve the search strategy itself, round after round.
The mechanism is clever and the GPU-kernel evidence for it is solid. The framing around it, and one of the two headline numbers, need more care than the paper gives them.
What actually self-improves here is a scheduler
Worth pinning down before anything else, because "recursive self-improvement" is in the title and that term has been doing heavy lifting all month. Dream-RSI's loop modifies exactly one artifact: the code of an exploration policy — a small program that looks at the current discovery tree each round and decides which leaves to continue from, how many attempts to launch in parallel, whether to open a fresh branch from the root, and when to stop. The paper draws the boundary itself, in one sentence: "Only the exploration-policy code changes; the underlying models, evaluator, and execution interfaces remain fixed."
That is a much narrower claim than Meta's AIRA₃ announcement made, and narrower even than Z.ai's Infra Agent essay covered here this morning. The narrowness is a virtue — a scheduling program that rewrites itself is a well-defined object you can measure. But it does mean the self-improving component is a search scheduler, and the paper's title, abstract, and conclusion all reach for the broader term without a sentence anywhere acknowledging the gap. After OpenAI spent a whole report distinguishing an "automated research intern" from full RSI, a paper that applies the unqualified label to a batch-scheduling script is a small data point in how fast the term is cheapening.
The replay simulator has a ceiling built into its definition
The mechanics are worth spelling out, because they bound what dreaming can ever teach. In replay, when the policy selects a node, the simulator returns that node's recorded child — deterministically, no new generation. Selecting the root reveals the earliest recorded branch not yet opened. When a node has no recorded continuation, it returns nothing. The paper is explicit: "no outcomes beyond the recorded tree are generated."
So an alternative policy inside a replay world can do exactly four things differently: traverse a different subset of branches, traverse them in a different order, group them into different parallel batches, and stop at a different point. Every node it ever sees was generated by the old policy. Dreaming can therefore discover that you should have stopped at attempt 50 instead of 110, or that three branches were worth batching together — it can never tell you what a branch nobody opened would have produced. That makes this an efficiency loop, structurally, not a capability loop: it learns to spend less on the search space it already has, not to reach a search space it doesn't. The paper never says otherwise, but it never frames the limit either, and the difference matters for anyone reading the RSI label literally.
There's a second, subtler consequence. The replay objective the policy is optimized against is defined as best-score-achieved minus a penalty on the number of attempts, plus a bonus for attempts-per-round. Cost reduction is written into the training signal — so "Dream-RSI reduces discovery cost" is partly a report that the optimizer optimized its objective, which is a weaker claim than it sounds.
The improvement guarantee is in-sample, and the correlation that matters is never reported
Dream-RSI's one formal guarantee is that the next round's policy scores no worse than the current one, because the current policy is included in the candidate set that gets selected from. True — but the selection happens on average replay score over the fixed history, and the candidate policies were written by an LLM development agent that saw the replay trajectories and scores from those same worlds. That is selection on the training set. There are no held-out replay worlds, no train/test split across trees, and no reported check on whether a policy that wins in replay actually wins online.
That last omission is the important one. The paper's entire premise is that replay score is a cheap proxy for online outcome. The single number that would validate the premise — the correlation between a policy's replay score and its subsequent online performance, which every round of every experiment generates for free — appears nowhere. The empirical results argue the proxy works end-to-end; they don't isolate whether it works as a proxy.
Also absent: values for any of the method's hyperparameters. The number of policy revisions per round, the two objective coefficients, and both round limits are named symbolically and never given numbers. And the cost accounting excludes the dreaming phase entirely — "discovery cost" counts discovery-agent calls only, so the policy-development agent's LLM calls, which the fixed-exploration baseline doesn't make at all, are outside every reported budget. Replay executes no code, but writing and evaluating candidate policies is not free, and Figure 2's "thousands of candidate policies" sits awkwardly against a method section describing a sequential loop where each revision waits on feedback from the last.
The Lasso headline is an averaging artifact — on one of the two backbones
This is the result the paper leads with, and it needs unpacking. The task is discovering a fast Lasso regularization-path solver; the scoreboard is wall-clock runtime on six held-out datasets, lower better. Against its own controlled baseline (Recursive Fixed Exploration — same agent, same evaluator, same starting policy, policy frozen across rounds), Dream-RSI with Gemini 3.1 Pro reports 2931.0 ms average versus 3587.1 ms, using 317 discovery-agent calls instead of 550.
Read the six columns instead of the average, and that run inverts. Dream-RSI's Pro solver is slower than the fixed-exploration solver on five of the six held-out datasets — Gisette 2841.0 vs 1861.8, DNA 49.9 vs 41.5, Leukemia 30.2 vs 26.1, Colon 16.4 vs 14.5, Duke Breast 32.5 vs 28.4. It wins on exactly one: RCV1, 14616.0 vs 19550.1. RCV1 alone is about 91% of the baseline's summed runtime, so the arithmetic mean over six numbers spanning four orders of magnitude is, in practice, the RCV1 column wearing a disguise. The paper notices the pattern and describes the Pro solver as "particularly well suited to large-scale matrices such as RCV1" — without connecting that observation to the average built on top of it.
The aggregation choice isn't arbitrary either, which is what makes this worth flagging rather than nitpicking. The benchmark's own search score, defined in the paper's appendix, is a geometric mean over timing instances — the standard fix for exactly this problem, and the rule the system optimizes against during discovery. Apply that same rule to the six downstream columns and the Pro comparison flips: roughly 179 for Dream-RSI against 159 for fixed exploration, about 13% worse. The headline survives only under the arithmetic mean the paper switches to for the downstream table.
The Gemini 3.7 Flash run is a different story and deserves separating out. There Dream-RSI is faster on five of six datasets, and it wins under both aggregations — 2350.6 vs 2516.7 arithmetic, and roughly 118 vs 128 geometric, with 1879 calls against 3200. That's a real result. It's also the one the paper mentions second.
"162× fewer calls" compares two different systems
The other number in the abstract is a reduction of "up to 162×" in agent calls against SimpleTES. That comparison is 317 Gemini-3.1-Pro calls through the Gemini CLI against 51,200 GPT-OSS-120B generations: different model, different harness, and — importantly — different unit, since one call to an agentic coding CLI wraps many model calls internally. Whatever 162× measures, it isn't the exploration policy. The controlled number for that is 1.7×, against the paper's own frozen-policy baseline, and it's reported clearly. The 162× belongs in the abstract only as a statement about frontier agents versus small open models, which is not what it's presented as.
One oddity in the same table: SimpleTES appears twice, same model, same 51,200-generation budget, with averages of 3804.8 and 8318.4 — a factor of 2.2 apart. The second row is marked with a dagger that the paper never defines. The natural reading is the authors' own re-run on their hardware, which would make it the apples-to-apples baseline; if so, it's the row that should be compared against, and the difference between the two is larger than most of the gaps under discussion.
The math tasks are the weakest section, and the kernel tasks are the strongest
Across three mathematical discovery problems, the results are: Sum–Difference 1.145427 against 1.144047 for its own fixed baseline, a 0.12% improvement; circle packing at 2.635983, identical to the four-decimal figure reported by AlphaEvolveV2, ShinkaEvolve, TTS-Discovery, and SimpleTES, which is a saturated benchmark rather than a win; and autocorrelation at 1.456375, where lower is better and its own fixed-exploration baseline scored 1.456001 — a loss. The paper's summary, "matches or surpasses strong baselines," is accurate, with the "or" carrying most of the weight. The honest framing of this section is that Dream-RSI reaches parity using fewer than 1,000 generations where SimpleTES used 51,200, which is a cost result, not a quality one.
GPU kernel engineering is where the case actually lands. On four KernelBench tasks against the same controlled baseline, Dream-RSI reaches comparable performance with 2.43× fewer generations on VGG16 and 1.79× fewer on LayerNorm, and at matched budgets delivers 2.09× and 1.44× higher performance on ConvDiv and ConvMax. Those are margins large enough to survive a lot of skepticism, on the domain where the search space is least saturated. Four tasks and one backbone is thin, but it's the part of the paper doing the real work.
The most interesting finding is the one that failed
Buried in the analysis section is a negative result worth more attention than the paper gives it. The authors tried the obvious alternative use of history: abstract past trajectories into high-level directional insights and inject them into the prompt as semantic guidance. Applied to both Dream-RSI and the fixed baseline, that guidance consistently underperformed the unguided version of each. Their explanation is that in long-horizon discovery with many parallel threads, strong semantic priors about promising directions over-constrain the space and suppress diversity.
That cuts directly against where a lot of agent-memory work is heading — distilling experience into insights, skills, and reusable lessons that get replayed into context. It's a single controlled comparison on a single task, so it isn't settled. But "history is more useful as an environment to test strategies against than as advice to follow" is a sharper claim than anything else in the paper, and it's the part most likely to matter outside this system.
The behavioral trace is the other thing worth keeping. Over nine rounds on ConvDiv, round-best performance climbs from 0.427 to 1.898, and the policy's spending pattern isn't monotone: it first cuts evaluated attempts from 110 down to 50 while returns are still coming easily, then pushes effort back up into the 80–92 range when progress plateaus, with gains resuming after. An anneal-then-re-expand schedule that nobody wrote down, falling out of a loop optimizing an explicit cost-adjusted objective, is a nice concrete demonstration of the core idea even where the aggregate benchmark numbers are contestable.
None of this makes Dream-RSI a weak paper. Discovery history as a replayable environment rather than static context is a real contribution, it's the same trick Schema used to backtest game programs against recorded history at zero action cost, and the kernel results support it. What the paper is missing is the part where it argues against itself: there's no limitations section, no reported check that replay score predicts online performance, no acknowledgment that the flagship average is carried by one column, and a title that claims considerably more territory than a self-rewriting batch scheduler occupies. For a lab that has been careful about this vocabulary elsewhere — and with AlphaEvolve sitting in the same building as the obvious comparison — those are omissions worth naming rather than a reason to dismiss the work.