Paper Feed

Issue 31 · Project 04 GitHub AI / ML ✓ read

FrontisAI/OpenRSI

Executable, measurable, and reproducible AI4AI toward recursive self-improvement. Home of OpenMLE and Frontis-MA1.

TL;DR: OpenRSI is a full-stack, open attempt to make "AI improving AI" a measurable engineering discipline rather than a slogan, starting in the machine-learning-engineering domain. Its first release pairs Frontis-MA1 (a 35B model post-trained as a program-evolution agent) with the OpenMLE stack (executable task environments, execution-grounded SFT+RL, and long-horizon evolutionary search), and reports jumping MLE-Bench Lite Medal Average from 39.4% to 60.6% via post-training alone, and to 71.2% with the full async search system — model-plus-harness numbers, but with unusually careful controlled comparisons and a held-out transfer benchmark.

What it is

The framing is the interesting part: rather than debating recursive self-improvement in the abstract, OpenRSI picks a bounded, executable domain — MLE tasks where an agent drafts, runs, debugs, and recombines programs against verifiable metrics — and closes the loop between search and training. Search produces trajectories, trajectories become training data, the trained model returns to search. They explicitly call this "meta-evolution" (training the improver) and explicitly do not claim general RSI, which is refreshing.

The design decision that makes it coherent: post-training and inference are aligned around the same four atomic operators — Draft, Improve, Debug, Crossover. These are learned via execution-grounded SFT and online RL (OpenMLE-RL), then composed into long-horizon search (OpenMLE-Evo). The same action space that the search harness uses is the one the model was trained on, so the model and the harness improve each other rather than being bolted together.

OpenMLE-Gym executable tasks + eval OpenMLE-RL SFT + online RL Frontis-MA1 35B / 30B agent OpenMLE-Evo long-horizon search trajectories → training data Shared action space: Draft · Improve · Debug · Crossover
One loop: the same four operators are trained with execution feedback and then composed into search; search trajectories flow back into training data.

The evidence

The headline results are on MLE-Bench Lite (Kaggle-style tasks) under a 12-hour-per-task budget on a single RTX 4090 capped at 12 GB VRAM — a deliberately modest compute envelope:

MLE-Bench Lite, Medal Average (%)01020304050607039.4Base model + Evo60.6Frontis-MA1-35B + Evo71.2MA1 + Evo-Max12h/task, one RTX 4090 @ 12GB. Evo-Max adds experience priors + async search; it is a system gain, not a pure model gain.

The README claims 71.21% exceeds GPT-5.5 + Codex and approaches GPT-5.6 Sol and Kimi K3 (2.8T). More convincing than the headline are the two controlled ablations on held-out NatureBench Lite (can an agent match published SOTA from Nature-family papers?): swap the model with the framework fixed and Match-SOTA goes 50%→70%; swap the framework with the model fixed and it goes 20%→50%. Both components transfer independently, which is the key claim if you care about whether anything was actually learned versus overfitted-searched. Training data was reportedly deduplicated against all evaluation benchmarks.

The README itself flags the right caveat: these are model–harness results, not one-shot model scores, and Evo-Max's benchmark-independent "experience priors" and asynchronous multi-GPU search should not be read as a model gain.

What's actually released

Substantial: 35B and 30B weights plus GGUF derivatives on HF, the SFT trace dataset, the task dataset, and source for all three stack components (Gym, ERL with SFT+RL stages, Evo) plus a self-hosted distributed sandbox for code execution and evaluation. There's a quick-start that runs a real single-task NatureBench search locally. Docs look genuinely thorough (results protocol, training pipeline, release boundaries, per-component usage guides).

Gaps and friction: the repo is source-only — weights, task artifacts, and benchmark environments are distributed separately and wired together via config. Each component manages its own environment (the quick-start mixes venv and conda). You need a serving endpoint (SGLang or any OpenAI-compatible URL) for the model. License is CC BY-NC 4.0, so non-commercial only — and CC licenses on code/weights are an awkward fit. The 2.8T-parameter Kimi K3 comparison and "approaching GPT-5.6" claims should wait for independent reproduction; the whole point of the release is that reproduction is at least possible.

Why it matters

MLE-Bench is the benchmark that most directly measures automated ML research, and a 21-point jump from post-training a 35B open model — verified with model-vs-harness ablations and held-out transfer — is a genuinely large result if it holds. The operator-aligned training/search design and the "make the rate of improvement the optimization target" framing are likely to be copied. The EEMA follow-up (EMNLP 2026) suggests active development.

Try it

Smoke-test one NatureBench task end-to-end (needs a served model endpoint):

git clone https://github.com/FrontisAI/OpenRSI.git
git clone https://github.com/FrontisAI/NatureBench.git
cd OpenRSI/OpenMLE-Evo
python3.12 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
conda env create -f environments/naturebench-local.yml
export PRIMARY_KEY='your-api-key'
python scripts/run_naturebench_local.py \
  --naturebench-repo ../../NatureBench \
  --conda-env naturebench-local \
  --model-base-url https://model.example/v1 \
  --model-id served-model-name --smoke

Weights: Frontis-MA1-35B on Hugging Face · paper: arXiv 2607.28568.