RSI-Anything: How a Patch Outcome Can Change the Next Choice

RSI-Anything’s code-repair experiment improves the repair system while keeping the model writing the code fixed. With ReasonFlux-Coder-7B unchanged, a capacity-matched static verifier yields a final hidden-test all-pass rate of 26.3%; selection by a fixed world model reaches 29.2%; adapting that world model with execution feedback reaches 31.2%. The last comparison adds 2.0 percentage points while retaining both the coder and the candidate budget. The component learning from execution is the predictor used to choose later patches. Code-repair results, §3.1

Following a candidate through the system makes that distinction concrete. Each round, the coder proposes four patches. The execution-outcome predictor W1 returns a probability distribution over five result classes for every candidate–test pair. Both world-model configurations aggregate those probabilities to rank the patches, then execute one. All four candidates have forecasts; only the executed patch obtains observed test results at this selection step. Code methods, §6.1

This waytoRSI editorial illustration explains the mechanism; it is not primary experimental evidence. A–D and the selected B are schematic identifiers, not recorded patches. Solid paths show prediction, selection and observation. Dashed paths denote updating across cycles, not training after every execution.

The useful learning record matches the same patch and the same test. For the illustrative B, its observed result class can be paired with the distribution W1 predicted for that test. A, C and D have no corresponding observation from this step: their predictions cannot stand in for results that were never measured. The framework keeps predictions and observations separate and links them to the action, context, evidence source and generating system version. Feedback records, §§2.1–2.4

That pairing explains how execution can supervise prediction. The observed class supplies a target against which the predicted distribution can be compared. Even an unsuccessful repair can therefore supply a prediction target: success at fixing the program and usefulness as an observed outcome are different properties. The framework specifies that outcome labels can supervise the outcome readout. Such a label does not reveal a complete next state, although its loss can also update upstream parameters when those parameters are trainable. The supervision target alone does not determine which weights change. Adaptation targets, §2.4

The methods identify W1’s starting point more precisely than they identify every later update. W1 is a 3B execution-outcome model built using JEPA-Anything’s predictive design and adapted from Qwen2.5-Coder-3B-Instruct with LoRA. That describes initial construction. The cited code-methods passage reports subsequent W1 adaptation without specifying the parameter subset and optimizer for every online update; the framework explicitly allows adaptation choices to differ from construction. What the comparison establishes is which component changes: the adaptive configuration updates W1, while the fixed configuration retains it and both keep the coder fixed. W1 construction and adaptation, §6.1; target and parameter choices, §2.4

The connection to recursive improvement lies in what a retained change can influence next. A revised predictor can rank the next candidate set differently. A different selection produces a different opportunity to observe execution and collect learning material. This is a dependency between selection and learning, not a guarantee that the next observations or updates will be better. Retained versions and subsequent experience, §2.5

The reported success rates measure this process under a specific evaluation. The authors use 200 CodeContests tasks across three seeds, with at most three feedback rounds. The resulting 600 task–seed evaluations reuse the same tasks across seeds; they are not 600 independent tasks. Online tests provide repair feedback, while hidden tests provide the final all-pass measure. Evaluation and statistical reporting, §6

The static-to-fixed comparison also supplies evidence about the quality of selection. Candidate-ranking accuracy rises from 66.5% to 72.8%, and the five-class Brier score falls from 0.488 to 0.358, where lower is better. These diagnostics compare the static verifier with the fixed world model. They support the first part of the argument: predictive ranking improves alongside repair success. The separate 29.2%-to-31.2% comparison measures the additional reported gain when W1 can adapt. Prediction diagnostics and adaptation results, §3.1

Mean online test-suite calls per task are nearly identical: 3.72 for the static verifier, 3.71 for the fixed world model and 3.72 for the adaptive world model. This makes the comparison informative about use of execution feedback under the shared candidate budget. It does not establish equal total computation. Predictor inference, adaptation, historical re-evaluation and acceptance checks are not measured by a count of online test-suite calls; the framework accounts for external feedback separately from update and evaluation computation. Table 2; computation accounting, §2.4

When to update and which version to retain

The wider framework adds a second decision beyond choosing the next action: which version of the system should make future decisions? Its notation keeps these timescales separate. Action steps are indexed by t; update-and-acceptance cycles by k. A cycle can aggregate feedback from several steps, trajectories or tasks. It ends after update decisions and acceptance checks, even if neither component changes. A longer history can thus be carried forward without constituting a policy or model revision. System state and cycle definitions, §2.1

Policy changes in this framework can involve trainable parameters or a persistent workflow. Policy and predictor updates can run on different schedules, and either component can stay unchanged. For an enabled predictor-adaptation path, the trigger requires an assessment of unreliability, sufficient adaptation data and enough remaining budget. Because observations come from selected candidates, the reliability conclusion is limited to the range those observations cover. Inadequate coverage yields an “insufficient” assessment and does not activate this trigger. Policy improvement and conditional adaptation, §2.4

Version handling matters to that assessment. To judge the current predictor, the framework compares observations with predictions attributable to the current version: either forecasts already stored from that version or forecasts recomputed on the recorded inputs. Predictions from older versions remain useful for understanding past decisions, but are not pooled directly into the current error estimate. The question is whether the predictor now being used is reliable on the covered candidates. Reliability protocol, §2.4

An attempted update still has to become an accepted version. The full protocol checks each proposed component against its current version, then evaluates the assembled policy–model pair under matched, prespecified conditions. The pair check has a concrete purpose: a changed policy may propose candidates its predictor judges poorly, while a changed predictor may alter which candidates get selected. Better isolated components do not necessarily make better joint decisions. A failed component check keeps that component’s current version; a failed pair check keeps the entire old pair. If neither component changes, no new pair comparison is required. The retained pair and accumulated history then enter the next cycle. These are the full framework’s rules; the fixed-coder success rates alone do not validate every trigger and retention step. Component and pair acceptance, §2.5; reported experimental scopes, §6

What changes across the five applications

The other applications become easier to interpret once the changed object is explicit.

Domain bindings and update scope, Table 4

GUI is the case that reports updating both sides: MiniWoB++ click-checkboxes and OSWorld use observed interaction outcomes to update the action policy and world model, then use the retained pair in subsequent interactions. Laboratory planning follows a different object over time: five consecutive retained versions of one 4B policy from the same improvement process, evaluated on the same 200-task LabHorizon F200 benchmark. Its Final Score combines action-sequence similarity and parameter accuracy. Reliable execution on physical equipment remains a separate evaluation question. GUI and laboratory methods, §6.1; physical-execution boundary, §5

Chemistry demonstrates how observations guide a search. In two Suzuki–Miyaura screens, predicted yields help select reaction conditions; measured yields extend the history used for the next choice. One protocol uses GC measurements, the other LC–MS. These search curves show the use of accumulating observations. By themselves, they do not establish an accepted, persistent revision to a policy or world model. Reaction search, §3.4; chemistry methods, §6.1

Immune science separates construction from downstream use. During construction, the system searches scientific-agent workflows and model configurations, then retains the selected model-building workflow and its predictor. Measured perturbations support model development. In downstream analysis, forecasts and experimental evidence guide intervention ranking and self-correction, but the predictor’s parameters remain frozen: candidate interventions and hypothesis rankings change. The resulting therapeutic hypothesis still awaits experimental testing. Immune-science application, §3.5; construction and downstream analysis, §6.1

Across these applications, “domain generality” means reusing the improvement mechanism with domain-specific models, policies and evaluations. The results establish different pieces: predictive selection, predictor adaptation, successive policy versions and observation-guided search. Combining those pieces does not establish sustained mutual improvement by one unified policy–world-model system in a single task, much less general recursive self-improvement. The paper itself identifies joint multiround evaluation as the evidence still needed for the narrower, single-task claim. Discussion, §5

The forward-looking question follows the feedback all the way through: over successive cycles of one task, do retained policy and predictor revisions support better prediction quality and better subsequent task performance? Answering it requires connecting the versions that survive acceptance to the decisions they make later, with evaluation criteria unchanged and external-feedback use accounted for separately from update and evaluation computation.

This analysis concerns RSI-Anything v1, submitted on October 9, 2026. Experimental results are those reported by the authors. Version history