# RSI-Anything

> Source: https://aiwiki.ai/wiki/rsi_anything
> Updated: 2026-10-13
> Categories: AI Agents, AI Research, Open Source AI, World Models
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "RSI-Anything." aiwiki.ai, 13 Oct 2026. https://aiwiki.ai/wiki/rsi_anything
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

RSI-Anything is a research framework for improving [AI agents](https://aiwiki.ai/wiki/ai_agents) through [world-model](https://aiwiki.ai/wiki/world_model) predictions and feedback from tests, interfaces, or experiments. It applies a shared candidate-selection and update process to code repair, graphical user interfaces, laboratory planning, reaction optimization, and immune-science workflows. Each application retains its own models, task definitions, and evaluation criteria.[2]

Taoyong Cui and coauthors submitted the RSI-Anything preprint to arXiv on October 9, 2026.[1]

## Predictive foundation

The framework builds on JEPA-Anything, a separate study of predictive learning across heterogeneous domains. Its orthogonal predictive factorization splits a latent target into complementary factors, predicts those factors through separate pathways, and recombines them for downstream use. JEPA-Anything's experiments cover vision, biology, clinical trajectories, control, molecular dynamics, physical fields, and weather. This is a shared modeling principle rather than a requirement that unrelated domains use identical observations.[3]

RSI-Anything connects that predictive foundation to [recursive self-improvement](https://aiwiki.ai/wiki/recursive_self-improvement): an accepted system version influences the next round's candidates and learning experience. The public project describes domain adapters for translating task states, actions, prediction targets, and external feedback into the shared process.[2]

## Selection, updates, and retention

The method separates proposing an action from checking its consequences. A policy generates candidates, a world model forecasts their outcomes, and selected candidates receive external evaluation. Observed feedback can support changes to the policy or agent workflow. Predictor adaptation is conditional: it requires unreliable predictions, enough evidence, and an available update budget.[4]

| Operation | Function[4] |
| --- | --- |
| Propose | Produce candidate actions or solutions. |
| Predict | Estimate candidate outcomes before external evaluation. |
| Select | Choose candidates that merit the available evaluation budget. |
| Evaluate | Obtain feedback from actual tests or measurements. |
| Learn | Propose policy, workflow, or predictor updates. |
| Retain | Carry forward versions that pass the declared checks. |

Policy and world-model changes can occur on different schedules. Proposed components pass individual checks, then the pair is compared with the current pair under matched conditions and predefined criteria. Separately improved components may perform worse together.[4]

## Reported evaluations

The following results belong to the authors' task-specific evaluations. Their metrics measure different outcomes and should not be compared as a single capability score.[1]

### Code repair

The [CodeContests](https://aiwiki.ai/wiki/codecontests) experiment uses 200 problems and three seeds, producing 600 problem-seed evaluations. ReasonFlux-Coder-7B proposes four revisions per round, with at most three rounds. The coder is shared across selection methods. Online tests provide repair feedback; passing every hidden test determines final success.[5]

| CodeContests selection method | Final hidden-test success[1] |
| --- | ---: |
| Capacity-matched static verifier | 26.3% |
| RSI-Anything with a fixed world model | 29.2% |
| RSI-Anything with world-model adaptation | 31.2% |

These reported improvements keep the coder fixed and use comparable online-test feedback. They therefore concern prediction-guided selection and predictor adaptation, rather than training a better code generator.[1]

| Additional repair benchmark | Problems | Seeds | Mean full-test success[5] |
| --- | ---: | --- | ---: |
| APPS Introductory | 1,000 | 0, 1, 2 | 46.37% |
| [LiveCodeBench](https://aiwiki.ai/wiki/livecodebench) v6 | 1,055 | 0, 1, 2 | 33.05% |

The additional benchmarks share initial programs, coder, and candidate budgets across methods. Repair uses public tests and stops when they all pass; the complete official test suite supplies the final result. The reported rates are arithmetic means across the three seeds.[5]

### Graphical user interfaces

On MiniWoB++ `click-checkboxes`, strict success requires every checkbox to match the instruction and a completed submission within 120 seconds and eight actions. The same 100 test instances are evaluated across three retained versions.[6]

| Selected-controller metric | Initial | Intermediate | Final[6] |
| --- | ---: | ---: | ---: |
| Successful tasks | 51/100 | 79/100 | 99/100 |
| Mean actions per episode | 5.30 | 2.93 | 3.21 |
| Incorrect submissions | 9 | 21 | 1 |

The final mean action count is 39.4% below the initial value. The intermediate version's lower action count accompanies more incorrect submissions. The selected controller uses `alpha=0`, following policy ranking. A separate controller that ranks candidates by world-model values reaches 98/100 in the final version. The 99% result therefore should not be described as pure world-model control.[6]

The protocol separates training, development, and test cohorts using disjoint instance seeds. Both successive update proposals are trained, selected, and frozen before the RSI test cohort opens. Expert continuations supply training targets; expert assistance is confined to training.[7]

For [OSWorld](https://aiwiki.ai/wiki/osworld), the project reports an 18.4% relative success-rate gain over the initial agent and a 5.5% relative gain over RLAnything. These are relative improvements, not additions of 18.4 or 5.5 percentage points.[5]

### Laboratory planning

LabHorizon F200 Level 2 evaluates plans for 200 laboratory tasks. Inputs include experimental context, goals, materials, constraints, and an operation library. The planning agent proposes four candidate sequences; JEPA forecasts quality, improvement, risk, uncertainty, and validity to select a plan.[8]

The paper reports that five successive versions of one 4B policy increased the planning score from 21.80% to 46.01%. This measures protocol-aligned planning; reliable physical execution still requires equipment-specific evaluation.[1]

The released inference guide uses Qwen3.5-4B-Base with local planning adapters and matching JEPA checkpoints for three seeds. Candidate generation produces one greedy and three sampled plans. Candidate selection can run on CPU, and both the planning policy and world model remain frozen during inference.[8]

### Reaction optimization

The released Suzuki-Miyaura adapter evaluates a fixed pool of 321 conditions by sequentially replaying measured flow LC-MS yields. Its 100 runs begin with eight observations and allow 40 distinct observations in total, including those initial eight. All runs find the pool's optimum by observation 10; the reported mean best observed yield is 96.15%.[9]

The adapter's predictions remain frozen while measured feedback changes the expected-improvement acquisition score and excludes conditions already observed. Its released inference table supports this particular reaction context and condition pool. The 96.15% figure is an observed reaction yield, not a prediction-accuracy score or success rate across arbitrary chemical reactions.[9]

For the paper's flow LC-MS comparison, the reported mean best observed yield after 40 experiments is 96.15%, versus 82.16% for [Bayesian optimization](https://aiwiki.ai/wiki/bayesian_optimization).[4]

The machine-readable evaluation identifies the experiment as offline sequential replay, records 100 seeds and the 321-condition target pool, and states that target rows were not used to select the readout or calibration. This release result should not be described as 100 newly executed laboratory optimization campaigns.[13]

### Immune-science workflow

The project also describes scientific-agent workflow evolution, immune-state forecasting, and evidence-guided hypothesis prioritization. Its prospective nomination combines SIRPα inhibition with modulation of the IL-36γ axis. It is a hypothesis for experimental testing, not an established treatment.[2]

## Software and reproduction

The repository provides a shared command-line runner and task implementations. Installation uses Python 3.10 or newer and an editable package installation from the repository checkout.[2]

| Command | Purpose[10] |
| --- | --- |
| `rsi tasks` | List available tasks. |
| `rsi plan --config configs/code_repair/default.json` | Print the resolved stage plan without starting workers or creating a run. |
| `rsi run --config configs/code_repair/default.json` | Execute code-repair stages in order. |
| `rsi run --config configs/gui/default.json --resume` | Resume a GUI workflow with the same recipe and source identity. |
| `rsi status --run runs/gui` | Read recorded workflow state. |
| `rsi report --run runs/gui` | Combine state with task result files. |

Run records preserve configuration, stage state, output hashes, logs, and task-specific artifacts. Before skipping a completed stage during resume, the runner checks its recorded output hashes. A filesystem lock prevents simultaneous runners from owning the same run. Scientific training remains in the task implementations rather than the common runner.[10]

### Recorded-input evaluation versus retraining

The code-repair reproduction guide distinguishes evaluating a released checkpoint from generating new trajectories. Recorded-input evaluation preserves initial programs, sampled candidates, public feedback, and execution durations, but recomputes world-model scores and decisions. Hidden tests run after all 600 decisions are completed and sealed. Fresh-input evaluation preserves the initial programs and first-round candidates, regenerates later candidates, and reruns public tests.[11]

The full training chain has four stages that inherit checkpoints in sequence. Selection combines predicted full-suite pass probability with one quarter of the predicted pass fraction; a revision replaces the incumbent only if its score is strictly greater. Evaluation performs no optimizer updates. Packaging validation recorded checkpoint evaluation and short training checks, but did not run full-epoch retraining; its strict orthogonality and factor-independence checks did not pass.[11]

### Code, models, and data terms

Project-owned source code uses Apache-2.0. That license does not replace the separate terms for model backbones, adapted weights, and datasets. The asset card identifies research-only terms for the Qwen world backbone and its adapted weights, MIT for ReasonFlux's model card, and CC BY 4.0 for CodeContests non-code material and contributed transition records.[12]

## Scope of the evidence

The paper's applications test different parts of the framework. It explicitly calls for joint multiround evaluation to establish sustained mutual improvement of a policy and world model within one task. Domain generality refers to reusing the procedure across domain-specific implementations, not evidence of unbounded intelligence growth.[1]

## References

1. Cui, Taoyong, et al. "RSI-Anything: Unlocking Recursive Self-Improvement with World Models." arXiv:2610.13912v1, October 9, 2026. [Paper and submission record](https://arxiv.org/abs/2610.13912); [full text](https://arxiv.org/html/2610.13912v1).
2. Gen-Verse. "RSI-Anything." [Official repository overview](https://github.com/Gen-Verse/RSI-Anything). Accessed October 13, 2026.
3. Cui, Taoyong, et al. "JEPA-Anything: Learning Predictive Models across Different Worlds." arXiv:2609.20800v1, September 17, 2026. [Paper](https://arxiv.org/abs/2609.20800).
4. PhAI Labs. "RSI-Anything: Recursive Self-Improvement across Domains: World Models in Every Round of Improvement." October 12, 2026. [Research announcement](https://phai-labs.com/en/news/rsi-anything/).
5. Gen-Verse. "Benchmark Settings and Results." [Code and GUI protocols](https://github.com/Gen-Verse/RSI-Anything/blob/main/docs/benchmarks.md). Accessed October 13, 2026.
6. Gen-Verse. "GUI Experiment Results." [Evaluation cohorts and controller results](https://github.com/Gen-Verse/RSI-Anything/blob/main/tasks/gui/docs/RESULTS.md). Accessed October 13, 2026.
7. Gen-Verse. "Frozen Scientific Protocol." [GUI training, selection, and test protocol](https://github.com/Gen-Verse/RSI-Anything/blob/main/tasks/gui/docs/PROTOCOL.md). Accessed October 13, 2026.
8. Gen-Verse. "Laboratory Planning." [Task and inference guide](https://github.com/Gen-Verse/RSI-Anything/blob/main/tasks/laboratory_planning/README.md). Accessed October 13, 2026.
9. Gen-Verse. "Suzuki Reaction Optimization." [Task, inference, and evaluation guide](https://github.com/Gen-Verse/RSI-Anything/blob/main/tasks/reaction_optimization/README.md). Accessed October 13, 2026.
10. Gen-Verse. "RSI Workflow." [Runner commands and stage interfaces](https://github.com/Gen-Verse/RSI-Anything/blob/main/docs/workflow.md). Accessed October 13, 2026.
11. Gen-Verse. "Code-Repair Reproduction." [Evaluation, retraining, and validation guide](https://github.com/Gen-Verse/RSI-Anything/blob/main/docs/reproduction.en.md). Accessed October 13, 2026.
12. Gen-Verse. "RSI-Anything Experiment Assets." [Provenance and licensing asset card](https://github.com/Gen-Verse/RSI-Anything/blob/main/docs/ASSET_CARD.md). Accessed October 13, 2026.
13. Gen-Verse. "Suzuki-Miyaura Flow LC-MS Condition Optimization." [Machine-readable evaluation record](https://github.com/Gen-Verse/RSI-Anything/blob/main/tasks/reaction_optimization/results/evaluation.json), dated October 12, 2026.