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

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/rsi-anything
> date: 2026-10-12
> tags: self-improvement, world-models, agents, agentic-coding, computer-use, scientific-ai, benchmarks

Six days ago I took apart [JEPA-Anything](/articles/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](https://arxiv.org/abs/2610.13912), code at
[Gen-Verse/RSI-Anything](https://github.com/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.

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig1.jpg"
  alt="RSI-Anything overview: on the left, icons for domains such as code, GUIs, labs, chemistry and immunology; in the middle, the JEPA-Anything predictive foundation with factorised latent prediction; on the right, a loop of action, interaction feedback, policy and world-model updates, and a retained pair feeding the next round."
  caption="The pitch in one picture: JEPA-Anything world models on the left, a loop that improves both the policy and the world model on the right (RSI-Anything paper, Figure 1)."
/>

<RepoCard repo="Gen-Verse/RSI-Anything" />

## 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.

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig2.jpg"
  alt="Two-part diagram. Part a, recursive self-improvement with world models: a retained pair at round k feeds a policy that proposes options A, B and C; a JEPA-Anything world model predicts each; prediction-guided selection executes B; the prediction and observation for B are recorded; then a policy check, a reliability assessment that may trigger world-model adaptation and a model check, and a pair compatibility check decide whether the proposed pair or the current pair is retained for the next round. Part b shows the mechanism instantiated in code repair, GUI tasks, laboratory planning, reaction optimisation and immune research."
  caption="The six operations and the two gates. Part b is where the paper maps the loop onto its five applications; the rest of this article checks how much of part a each application actually runs (RSI-Anything paper, Figure 2)."
/>

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.

<RsiLoop />

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.

| Domain | Policy (proposes) | World model (predicts) | What gets updated |
|---|---|---|---|
| Code repair | ReasonFlux-Coder-7B, frozen | W1: a LoRA on Qwen2.5-Coder-3B with an OPF head, five execution classes | world model only, offline |
| GUI | ReasonFlux-Coder-7B with a LoRA | OPF world model on a Qwen2.5-Coder-3B encoder | both, online, gated |
| Lab planning | Qwen3.5-4B-Base with planning adapters | five small MLPs over hashed features | policy versions, route unstated |
| Chemistry | none; a fixed 321-row grid | ReactionT5 plus a JEPA head, ExtraTrees readout | nothing |

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.

<ClaimLedger />

### 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.

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig3.png"
  alt="Code repair figure. Panel a shows a workflow from buggy initial code to three candidate patches, predicted outcomes, execution and test feedback. Panel b shows hidden-test success: Random-K 26.0%, static verifier 26.3%, RSI-Anything with a fixed world model 29.2%, with world-model adaptation 31.2%. Panel c shows ranking accuracy 66.5% versus 72.8% and Brier score 0.488 versus 0.358 for the static verifier and fixed world model. Panel d shows about 3.72 test-suite calls per task for every method. Panels e and f show APPS at 37.90% initial, 44.07% random, 44.00% static and 46.37% RSI-Anything, and LiveCodeBench at 25.24%, 31.18%, 30.74% and 33.05%."
  caption="Code repair on 200 CodeContests tasks, three seeds, four candidates per round. Panels e and f are the transfer benchmarks; note the static verifier sits at or below random selection on both (RSI-Anything paper, Figure 3)."
/>

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):

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

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig4.png"
  alt="GUI figure. Panels a and b illustrate a MiniWoB++ checkbox task and an OSWorld spreadsheet task. Panel c plots click-checkboxes success for RSI-Anything at 51%, 79% and 99% and for world-based control at 49%, 96% and 98% across baseline, adapted and final configurations. Panel d shows OSWorld relative gains of 12.3% for RLAnything and 18.4% for RSI-Anything over the initial agent. Panels e to g show mean actions per episode 5.30, 2.93, 3.21; repeated clicks 237, 2, 0; and incorrect submissions 9, 21, 1."
  caption="The GUI results. The green line is the reported controller; the dashed grey line, 'World-based control', is the one that actually ranks actions with the world model (RSI-Anything paper, Figure 4)."
/>

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:

```python
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

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig5.png"
  alt="Laboratory planning figure. Panel a shows a protocol context with a lab photograph feeding a 4B policy that proposes options A, B and C, a predictive evaluation of the action sequence, an execution plan and an assessment, with a dashed feedback arrow labelled world-model adaptation and adaptive variant generation. Panel b shows five versions from initial to final. Panel c plots the F200 Level-2 Final Score: 21.80, 38.03, 41.99, 44.56 and 46.01, against a dashed Actor-Simulator-Selector reference at 45.32%."
  caption="Five consecutive versions of one 4B planning policy on LabHorizon F200 Level 2. The paper notes the spacing is schematic and the dashed feedback paths depict the framework, not this experiment (RSI-Anything paper, Figure 5)."
/>

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):

```python
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.

<Figure
  src="https://ai.thesatyajit.com/articles/rsi-anything/fig6.png"
  alt="Reaction optimisation figure. The top half, GC screen, shows a reaction of 4-chloroanisole with a trifluoromethyl phenylboronic acid, condition options, prediction and selection, and execution with a robot arm; a plot of best observed GC yield against cumulative experiments from 6 to 20 with RSI-Anything rising to 93 and Bayesian optimisation to 87.5; and bars of 87.5% against 93.0%. The bottom half, flow LC-MS screen, shows substrates 1c and 2b, catalyst, ligand, base and solvent options; a plot of mean best observed yield over 40 experiments where both curves share a rising start to 71.94 at 8 experiments, RSI-Anything jumps to 95.06 at 9 and 96.15 at 10 and stays flat, while Bayesian optimisation climbs slowly through 73.59 and 79.16 to 82.16 at 40; and bars of 82.16% against 96.15%."
  caption="Two Suzuki screens. The lower panels are the 96.15% claim: both methods share the first eight experiments, then RSI-Anything reaches its final value at the tenth (RSI-Anything paper, Figure 6)."
/>

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:

```python
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](/articles/lobe-rsi-harness) 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](/articles/dream-rsi), where a scheduler around a frozen model is what
loops, and [recursive harness self-improvement](/articles/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](/articles/jepa-anything): 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.