RSI-Anything: the world model ranks, the policy learns, and they rarely meet

Six days ago I took apart JEPA-Anything, the Gen-Verse paper that offers one recipe for building world models across cells, fluids, robots and weather. This week the same group shipped the sequel. RSI-Anything (arXiv 2610.13912, code at Gen-Verse/RSI-Anything) takes those world models and puts them inside a recursive self-improvement loop. Ling Yang's launch post leads with four numbers:

• code repair success 26.3% → 31.2%, "with the coder fixed";
• a GUI agent using 39.4% fewer actions, with higher completion;
• lab-planning scores 21.80% → 46.01% over five policy versions;
• mean best reaction yield 96.15% against 82.16% for Bayesian optimization, on the same 40-experiment budget.

A co-author's post calls it "one RSI model that works across coding, GUI, planning, or even Science tasks." One reply under the launch post asked the question I had too: "does the recursive bit get tested anywhere? looks mostly like separate demos."

I expected the honest answer to be "partly". The paper's own discussion half-admits it. What I did not expect was how little of the loop the headline numbers use once you read the task code. In the GUI result the world model is loaded and never asked. In chemistry nothing is updated at all. The framework is a reasonable piece of protocol design, and one experiment in the repository is a model of how to evaluate this kind of system. The four numbers in the post are something else.

expand

The loop the paper describes

Start with why anyone would want a world model here. A self-improvement loop learns from feedback, and real feedback costs something: a test-suite run, a browser episode, a reaction in a flow reactor. If you can predict what an action will do before you pay for it, you can spend the budget on the candidates most likely to be good, and you can use the predictions themselves as cheap training signal. The motivation is sound.

The paper then names the problem that makes it hard, and this is the most useful idea in it. The policy and the world model are coupled. Fine-tune the policy and it starts proposing actions the world model has never seen, so the predictor's accuracy on the old data says little about its accuracy on the new candidates. Retrain the world model and it reorders the candidates, which changes what experience the policy learns from. Improving either one alone "does not guarantee better joint performance."

The paper's answer is a protocol over the pair. At update cycle $k$ the system is a policy configuration $\theta_k$ (weights, or a persistent agent workflow) and a predictor $\phi_{d,k}$ for domain $d$. One cycle runs six operations:

1. Propose. The policy offers a candidate set $\mathcal{K}_t$ for the current state.
2. Predict. The world model encodes the state, predicts the latent next state for each candidate, $\hat z_{t+1} = F_{\phi}(z_t, a_t, c_d)$, and a readout turns it into an outcome prediction.
3. Select. Candidates are ranked by predicted utility minus an optional uncertainty penalty, $R_d(\hat\tau) = \sum_j w_{d,j} r_{\tau,j} - \lambda_d U(\mathbf{u}_\tau)$, and the best one that fits the feedback budget is executed.
4. Evaluate. The executed candidate yields a real observation. It is stored next to the prediction that chose it, tagged with the model version that made the prediction.
5. Update. The policy is updated from feedback (demonstrations, preferences or workflow search). The world model is retrained only if a reliability check on its own version's predictions says unreliable, there is enough data, and the budget covers it. An insufficient verdict, which is what you get when feedback covers too few candidates, does not trigger anything.
6. Retain. Each changed component must pass its own check against the current version, and then the assembled pair must beat the current pair under matched conditions. Fail the pair check and both components roll back.

Two details in that list are better than most self-improvement papers bother with. The reliability estimate only counts predictions made by the current model version, so an old model's errors do not get averaged into the new one's score. And the pair check exists because the failure it guards against is real: a better predictor can still be wrong on exactly the candidates a new policy proposes. The paper also tags every piece of evidence by fidelity, from rule checks (E0) and learned predictions (E1) through simulators (E2) to real measurements (E3), so imagined rollouts are never silently mixed with measured outcomes.

expand

So far, a protocol. Whether it is recursive self-improvement depends on whether a run goes round the loop more than once with both components changing and both gates firing. The widget below walks the loop for each benchmark, coloured by what the released code does for the number that was reported. Green means the code does that step. Amber means it does a weaker, offline or undocumented version. Red means the step is absent from the headline run.

If you click through all four domains you will see the pattern this article is about. Every domain predicts and selects. Only the GUI experiment updates both components and gates the pair, and in that experiment the gate itself switched the world model off for the numbers that were reported.

"One RSI model" is four separate systems

Before the claims, a correction to the co-author's framing. There is no single model. Each domain has its own policy, its own world model and its own selection rule, sharing a vocabulary and a JEPA-Anything core library. It is the same pattern I found in JEPA-Anything, which is "one recipe, many weights", and it is fine, but it is not what "one RSI model" says.

The shared rsi package in the repository is a stage runner: 666 lines that launch each task's own scripts, record state and resume. Its docs say so plainly: "Scientific training and action-selection operations remain in the task implementations." I searched the whole repository for the reliability trigger and the pair-compatibility check from equations 10 to 18. Neither exists as shared code. The GUI task has a promotion gate of its own, which I come back to below; the other tasks have none.

Four numbers, checked

Here are the four launch numbers next to the comparison that decides what each one means. The sections after it go through them one at a time.

Code repair: a better ranker, retrained offline

This is the cleanest experiment in the paper, and it shows the strongest result.

The coder is ReasonFlux-Coder-7B from the same group's earlier CURE work, and it never changes. In each of up to three rounds it writes four revisions of a buggy program. The world model, W1, is a 3B Qwen2.5-Coder with a LoRA and a JEPA-Anything OPF head. For every pair of revision and public test it predicts the probability of five execution classes, plus a whole-suite pass probability. The selection rule is written down in the reproduction guide: score each revision by P(full-suite pass) + 0.25 × predicted pass fraction, and let it replace the current program only if it scores strictly higher. The executed revision gets public-test feedback; hidden tests are judged once at the end. The paper calls this "world-model-guided selection"; in practice it is a learned verifier in the AlphaCode sense, ranking a fixed sampler's outputs.

expand

The numbers hold up as stated. A fixed world model lifts hidden-test success from 26.3% for a capacity-matched static verifier to 29.2% (175 of 600), at essentially the same 3.71 online test calls per task. Ranking accuracy goes from 66.5% to 72.8% and the five-class Brier score from 0.488 to 0.358, so the gain comes from better prediction, which is what you would want to see. The paper reports a paired interval for that step: +2.83 points, 95% interval +0.17 to +5.50, clustered by task. It clears zero, but only just.

The second step, to 31.2%, is where "self-improvement" is supposed to come in, so I looked hard at what it is. The paper says "execution feedback informed program repair and revised the predictor used for subsequent candidate selection." The code does something more ordinary. W1 is trained through four stages in a fixed order, initial (32,920 rows), semantic (7,872), expanded (41,088) and incumbent (22,192), all built from recorded execution transitions on training problems. Then the final checkpoint is frozen and evaluated. The reproduction guide is explicit: "Evaluation performs no optimizer updates." Nothing learns while the 600 evaluation episodes run. The "adaptive" world model is a world model trained on more and better-targeted data.

Retraining offline is a legitimate design, so I checked the obvious leak instead. I downloaded the training bundle (236 MB) and compared problem IDs: the training stages cover 2,200 distinct problems, the development set 300, and none of them is one of the 200 evaluation tasks. A reply under the launch post asked whether 31.2% was scored on the tasks the loop learned from. It was not.

Three things still weaken the step from 29.2% to 31.2%.

The first is size. Two points on 600 task-seed runs is about 12 tasks. The paper gives no interval for this comparison. If its spread is like the one it does report, about ±2.7 points, the interval probably includes zero.

The second is variance. The released checkpoint's own validation record (config/validation.json) re-runs the evaluation and gets 188 of 600, with 69, 62 and 57 successes on the three seeds, or 34.5%, 31.0% and 28.5%: a six-point spread between seeds, three times the gain being claimed. Small aside: 188/600 is 31.33%, while the paper's 31.2% corresponds to 187. One task. It does not matter, but it does mean the checkpoint on Hugging Face is not quite the run in the paper.

The third is how the checkpoint was chosen. The manifest of the released world model says "automatic_promotion": false, and its provenance paths read historical_jepa_200_optimization_20261006/…/expanded_fits_round2/… and same_200_retest_expanded_round3/independent_complete_audit.json. The same manifest says "final200_labels_used": false, and I have no reason to doubt that no hidden labels went into training. But a directory called "same 200 retest, round 3" says candidate world models were re-tested on the evaluation tasks more than once during development. If those retests influenced which checkpoint shipped, then some of the two points is selection on the test set. I cannot tell from the release whether they did. What I can say is that the paper's retention gate, a predeclared check that decides automatically, is not what produced this checkpoint.

The transfer benchmarks add one more wrinkle. On APPS Introductory and LiveCodeBench v6 the world-model selector reaches 46.37% and 33.05%, ahead of random (44.07%, 31.18%) and the static verifier (44.00%, 30.74%). Those runs use a different checkpoint, transfer_final, not the CodeContests one. And on both benchmarks the static verifier is worse than picking at random, which makes it a weak baseline to beat. The comparison that would settle it, against a plain trained outcome classifier of the same size without the JEPA machinery, is not in the paper.

GUI agent: the world model is loaded and never asked

This is the only experiment that runs the full loop, with both components updating and a gate on the pair. It is also the one where the headline number does not use the world model.

The task is MiniWoB++ click-checkboxes: read an instruction such as "Select DKkQH and click Submit", tick the right boxes in a real Chromium page, and submit, within eight actions and 120 seconds. The policy is ReasonFlux-Coder-7B (a coding model, repurposed) with a LoRA. It ranks the legal clicks and Submit, and the top four, with Submit always included, are the candidates. The world model is an OPF JEPA on a Qwen2.5-Coder-3B encoder that predicts each action's next state, discounted return and probability that a submit succeeds.

Each update collects 100 fresh browser episodes, fine-tunes the policy on the actions from its own strictly successful episodes (at most 256 new actions plus an equal amount of replay, one epoch), and retrains the world model on the real transitions plus expert continuations. Then the new pair is compared with the old pair on 50 development instances, and promoted only if success rises by at least 4 points at no more than 1.2× the cost. This is the paper's pair check, written as actual code (rsi.py, line 53):

promoted = newdev['success_rate'] - olddev['success_rate'] >= protocol['promotion_gain'] \
    and newdev['effective_seconds'] <= olddev['effective_seconds'] * protocol['promotion_cost_ratio']

expand

The reported line goes 51% → 79% → 99% on the same 100 test instances, and mean actions fall from 5.30 to 3.21, which is the 39.4% in the post. Now look at how an action is chosen. Before each update a development sweep picks a mixing weight alpha between the policy's own ranking and the world model's value. The selection function (experiment.py, lines 17 to 20) starts like this:

def select(proposal, forecasts, controller):
    alpha = controller.get('alpha', 0.)
    policy = [math.log(max(proposal['probabilities'][i], 1e-12)) for i in proposal['candidate_ids']]
    if alpha == 0: return 0, {'scores': policy, 'alpha': 0., 'world_used': False}

The repository's own results page says "the reported runs select alpha=0, which follows policy ranking", and "all original selected alphas were zero." So the 51, 79 and 99 are the policy acting on its own. The world model was loaded, its forecasts were computed and then ignored.

The repository did the experiment that proves it, and I want to give it credit for that, because it is exactly the evaluation a self-improvement paper should run. For each update it evaluates all four combinations of old and new policy with old and new world model, under both controllers. Under the reported controller, swapping the world model changes nothing in any cell: old policy is 51% with either world, new policy is 79% with either. The repository's paired test for "selected world update" is 0.00 points, interval [0.00, 0.00]. Every point of the headline comes from the policy fine-tune.

Switch the ledger above to "world-model ranking" and the story changes. Ranked by the world model, the same old policy goes from 49% with the old world to 95% with the updated one. On a separate 630-instance confirmation cohort, three independently trained OPF world models go from 43.81% to 97.04% when updated, +53.23 points, 95% interval 50.26 to 56.30: a large, well-measured effect, and the paper's real evidence that feedback-driven world-model adaptation works. It is in the figure as the dashed grey line. It is not the number in the launch post.

Why did the gate pick the policy anyway? The hybrid weights it tried were 0.25 and 1.0, a hybrid was enabled only if it gained at least 4 points at no more than 4× the cost of the policy alone, and world-model scoring is expensive: about 0.8 equivalent seconds per episode against 0.13 to 0.14 for the updated policy. Pure world-model ranking was always reported but was never a candidate for the controller. The loop worked as designed, and the design concluded that its world model was not worth running. An honest outcome, and it should have been the headline.

A few more things to read alongside the 39.4%:

• Most of the fewer actions are repeated clicks going away: 237 in total at baseline, 2 after one update, 0 after two. The intermediate version took the fewest actions of all (2.93) but submitted wrong answers in 21 episodes, which is why the post compares baseline to final.
• A scripted rule controller in the same repository scores 100% at 2.87 actions. The task is fully solvable by a few lines of code, so 99% at 3.21 is the learner approaching that rule, not pushing a frontier.
• World-model training uses expert continuations; the task README calls the whole thing "expert-assisted GUI policy adaptation". The policy fine-tune itself uses only the agent's own successful episodes.
• The RSI sequence is one policy training seed on 100 test instances. The policy-only gains have paired intervals, +28 points [18, 38] and +20 points [13, 28], so they are real for this task.
• After an update, a plain JEPA (98%) and a supervised critic (95%) do as well as the OPF world models (95%, 95%, 96%), so the factorisation from JEPA-Anything is not what makes the world model work here. Those two control arms are single runs.

OSWorld gets one panel and two relative numbers: +18.4% over the initial agent and +5.5% over RLAnything. The paper never gives absolute success rates, the repository has no OSWorld code, and I could not check either number. They are at least consistent with each other: 1.184 / 1.123 is about 1.054, which rounds to the reported 5.5% given unrounded inputs.

Lab planning: five versions, one process, nothing to rerun

expand

LabHorizon Level 2 asks for a laboratory protocol as a sequence of Python calls to a supplied action library, scored by sequence similarity and parameter accuracy. The paper reports five versions of a 4B policy: 21.80%, 38.03%, 41.99%, 44.56% and 46.01%. The final one edges the benchmark's Actor-Simulator-Selector reference, which uses a trained Qwen3.6-35B-A3B with Gemini 3.1 Pro as simulator and selector, by 0.69 points. On Level 1 it scores 0.700 against the reference's 0.665.

What the paper does not say is how any version was made. It does not say what the initial version is, what feedback trained version 2, whether the world model was involved in the updates, or what gate retained each version. The figure's caption itself says "dashed feedback paths depict update routes in the framework; the quantitative comparison below follows retained policy versions." There is one number per version and no seeds or intervals. A 0.69-point lead over a reference with no variance reported is a tie.

The repository can't fill the gap. Its inference guide generates candidates with Qwen3.5-4B-Base and a "local P4 adapter", and those adapters are not in the release. What is released is three world-model checkpoints, seeds 1401 to 1403, 1.6 MB each. I read the model they load (lab_inference/world.py, lines 13 to 25):

class OutcomeModel(nn.Module):
    def __init__(self):
        super().__init__()
        self.encoder = nn.Sequential(nn.Linear(INPUT_DIM, 128), nn.GELU(), nn.Linear(128, 32))
        self.predictor = nn.Sequential(nn.Linear(32, 64), nn.GELU(), nn.Linear(64, 32))
        self.head = nn.Linear(32, 8)
        self.opf = OrthogonalFactorProjection(32, 4, 8)
 
    def forward(self, x):
        z = self.encoder(x)
        p = self.predictor(z)
        return (torch.sigmoid(self.head(p)), z, p)

The input is 544 numbers: 128 hashed bag-of-tokens features of the task, 128 of the candidate plan, 16 hand-counted structure features (number of steps, missing required arguments, positional arguments, and so on), and the same again relative to the first candidate. Five of these small MLPs form an ensemble, and the selection score is predicted quality plus 0.25 × predicted gain, minus 0.1 × risk and 0.1 × uncertainty. Note that self.opf is not on the forward path. It is called only when you ask for --include-factors. Whatever OPF did during training, the "JEPA-Anything-based protocol model" that picks plans at inference is a feature-hashed MLP ensemble.

That may well be a perfectly good plan reranker. But the 21.80 → 46.01 curve is a claim about policy training, and nothing about that training is published.

Reaction yield: a frozen prior meets the top of the table

The chemistry result is the one that drew the most excitement in the replies ("96% yield on a 40 exp budget is crazy", "Huh, actually crushed bayesian opt"), so it is worth being exact about what it is.

expand

The flow screen is a fixed grid of conditions for one coupling, electrophile 1c (6-OTf-quinoline) with boronic ester 2b and Pd(OAc)₂: 12 ligands (counting "none"), 8 bases (counting "none") and 4 solvents. The released candidate catalogue has 321 rows, mapped into a "5,030-row filtered screening table". The world model's readout was trained on 4,709 auxiliary rows from 14 other reaction groups. Those counts fit one dataset exactly: 15 substrate pairs, 4,709 + 321 = 5,030 rows, 12 × 8 × 4 = 384 conditions per pair before filtering. I believe this is the published nanomole-scale Suzuki screen of Perera and co-workers (Science, 2018), the standard benchmark for this task. The paper does not name its source, so treat that as my identification, not theirs.

Now the procedure, from results/evaluation.json and selector.py. The "experiment" is an offline replay: the selector picks a row, and the yield already measured in the published screen is looked up. Each run starts from eight random measured rows. After that, every pick is Gaussian expected improvement over a frozen table of predicted means and calibrated standard deviations:

scores = expected_improvement(prior.mean, prior.std, max(yields), prior.xi)
scores[ids] = -np.inf
selected = int(np.argmax(scores))

The evaluation record says "online_prediction_update": false and "frozen_world": true. Feedback moves the incumbent best yield and removes measured rows from the pool. No model is updated, no version is retained. This is model-based Bayesian optimisation with a fixed prior, and there is no self-improvement in it at all.

Then look at the metric. The pool's best row has a measured yield of 96.15%. The record lists "candidate_pool_best_yield_percent": 96.15 and "mean_final_best_observed_yield_percent": 96.15. All 100 runs find that row by the tenth experiment: 96 of them exactly at the tenth, three at the ninth and one at the seventh. "Mean best observed yield 96.15%" means "every run found the best condition in the table", and 96.15% is a ceiling no method can beat on this pool. The 40-experiment budget in the post is irrelevant to the RSI side: its curve is flat from experiment 10 to 40. What the 40 experiments buy is time for Bayesian optimisation to catch up, and it gets to 82.16%.

The gap is still big, and a good prior is a legitimate advantage. But the prior was fit on 14 other substrate pairs run over the same ligand, base and solvent grid in the same screen, and its readout is an ExtraTrees regressor whose inputs include one-hot encodings of the condition fields. Conditions that work for one Suzuki coupling in this screen tend to work for its neighbours. Bayesian optimisation (Shields and co-workers' EDBO is the baseline cited) started from nothing. The comparison is a warm-started optimiser against a cold one. The control that would tell us what the JEPA part contributes is a Bayesian optimiser, or even a simple regressor on the one-hot conditions, warm-started on the same 4,709 rows. It is not in the paper.

The released model does not reproduce the paper's figure either. Figure 6e shows a mean best of 95.06% after nine experiments. The released replay, dated the day of release and labelled reactiont5-jepa-suzuki-v1, gives 80.14% at nine. Both reach 96.15% at ten, because both find the same top row, so the endpoint agrees while the path does not. The measured yields themselves are not in the release ("target_measurements_exported": false), so nobody outside can rerun the replay.

The GC screen in the top half of the figure, 93.0% against 87.5% after 20 experiments, is a single best observed yield per method. One run each, nothing released. I would not lean on it.

Immune science

The fifth application is a pointer to another paper by the same group (Cui et al. 2026a): an evolved scientific-agent workflow builds an immune world model, and an analysis agent uses it to nominate SIRPα inhibition combined with IL-36γ-axis modulation as a hypothesis for testing. The paper is clear that the hypothesis "awaits experimental testing", and the world model is frozen during the analysis. The Hugging Face folder for it holds one README: "This domain is under development." There is nothing to check yet.

Is this recursive self-improvement?

The paper's own discussion answers it, more candidly than the launch post: "Joint multiround evaluation is needed to establish sustained mutual improvement of the policy and world model within a single task." And its methods section spells out the split: "Code repair holds the coder fixed while testing predictive selection and predictor adaptation; laboratory planning follows five successive policy versions." Each experiment exercises a different slice of the loop:

• code repair: predictive selection, plus a world model retrained offline between versions;
• GUI: both components updated twice and gated as a pair, with the world model gated out of action selection;
• lab planning: a policy that improved over five versions by a route the paper does not describe;
• chemistry: Bayesian optimisation with a frozen learned prior.

In the LobeHub piece I used Awesome-RSI's distinction between persistent self-improvement (changes carry into the next round) and recursive self-improvement (the mechanism that produces improvements is itself improved). By that standard the GUI run is persistent self-improvement with a learned critic attached, and the others are less than that. Nowhere does the improved world model go on to produce better training data for a policy that then produces better data for the world model, which is the circle the title promises. The precise description is an outer loop of world-model-guided selection plus fine-tuning, with a good acceptance protocol sketched on top and implemented once.

That puts it next to Dream-RSI, where a scheduler around a frozen model is what loops, and recursive harness self-improvement, which compares each harness only against its predecessor. "RSI" has become the umbrella word for this family, and this paper is honest in its own text about which loop each experiment closes. The launch post is less so.

What I would take from it

The protocol is worth stealing even though the paper does not run it end to end. Store each prediction with the version of the model that made it, and score reliability only on the current version's predictions. Refuse to call a predictor reliable when feedback covers too little of the candidate range. Gate updates on the assembled pair, not on each component. Most of all, run the crossed evaluation the GUI task runs, old and new policy against old and new world model under every controller you use. It is the one experiment in this release that tells you, unambiguously, which component earned the gain, and here it told the authors something they then did not put in the post.

The release engineering is also better than usual: every asset is hashed, the code-repair decisions are sealed before hidden judging, function bodies are checked against the original experiment source, and the GUI results page lists all 42 evaluated arms, including the ones that make the headline look worse. It also records its own failures. The code-repair validation notes that on the reference checkpoint "strict orthogonality and factor-independence checks did not pass", which matches what I measured in the JEPA-Anything projectors: the factorisation drifts away from orthogonal in trained models.

What is released: Apache-2.0 code for all four tasks; the code-repair world-model LoRAs (CodeContests and transfer), evaluation inputs and the full training records, under the Qwen research licence for the adapted weights, which is non-commercial; the final GUI policy and world model; three 1.6 MB lab world models but not the planning policies; the 807 MB ReactionT5-JEPA checkpoint and its frozen prediction table, without the yields. Compute is not reported in the paper. The repository's recorded GUI setup is three A800 80 GB GPUs, and the code-repair evaluation script is written for eight.

The code-repair result, a learned execution predictor beating a static verifier at equal test cost, is the one I would build on. The GUI world-model result, +53 points under world-model control on 630 instances, is the strongest number in the release and the one the post leaves out. The other two headline numbers say less than they appear to.

How I checked

I read the paper's HTML and PDF (v1, 9 October 2026), both launch threads and their replies through the fxtwitter mirror, and shallow-cloned Gen-Verse/RSI-Anything at commit 99dbf00. I read every task's source, configs, protocol files and result records rather than the README tables. For code repair I downloaded the release's evaluation and training bundles (64 MB and 236 MB), extracted the JSON records without the weights, and compared problem IDs and problem statements between the 200 evaluation tasks and the training and development sets; per-seed counts come from config/validation.json, and checkpoint identities from the manifests and the Hugging Face inference.json files. GUI numbers come from tasks/gui/docs/RESULTS.md, reported_results.json and original_scientific_protocol.json; the alpha = 0 behaviour from experiment.py and worker.py. For chemistry I read evaluation.json, selector.py and the 321-row prior, counted its ligands, bases and solvents, and identified the dataset from those counts. Lab-planning details come from the inference code and the Hugging Face checkpoint configs. Paper figures were cropped from the PDF or taken from the repository's own copies. I did not run any of the authors' code, so the results above are their numbers read correctly, not reproductions. I could not check the OSWorld numbers, the lab-planning training, the Bayesian-optimisation runs or the GC screen, because none of them is in the release.