Source-linked AI summary

Frontis-MA1: Training an AI4AI Model towards Recursive Self-Improvement in Machine Learning Engineering

Junlin Yang, Che Jiang, Yu Fu, Tianwei Luo, Can Ren, Weizhi Wang, Kaikai Zhao, Hongyi Liu, Yuxin Zuo, Yuru Wang, Yuchen Fan, Kai Tian, Zhenzhao Yuan, Xiaojian Lin, Li Sheng, Rushi Qiang, Guoli Jia, Xingtai Lv, Ermo Hua, Dianqiao Lei, Youbang Sun, Ning Ding, Bowen Zhou, Kaiyan Zhang

arXiv:2607.28568v1cs.CL

TL;DR

Building AI with AI is a route toward recursive self-improvement, and machine learning engineering offers a direct testbed with delayed execution feedback. OpenMLE aligns execution-grounded training of reusable operators with long-horizon search; on MLE-Bench Lite, Frontis-MA1-35B reaches 71.21% Medal Average with OpenMLE-Evo-Max1.

  • Problem

    MLE is a direct AI4AI testbed, but its execution feedback can be delayed, noisy, and heterogeneous, making iterative agent improvement demanding.

    Source: §1 · p. 4, §4 · p. 11
  • Method

    OpenMLE connects executable MLE environments, execution-grounded training of Draft, Improve, Debug, and Crossover operators, and their composition in long-horizon search.

    Source: §1 · pp. 5–6
  • Results

    Across model- and system-level MLE-Bench Lite evaluations, Medal Average rises from 39.39% to 60.61% over Qwen3.6-35B-A3B under identical OpenMLE-Evo; Frontis-MA1-35B with OpenMLE-Evo-Max1 reaches 71.21% Medal Average.

    Source: §1 · p. 5
  • Takeaways & Limitations

    OpenMLE provides a validated workflow and released resources for reproducible study and extension of recursive self-improvement in executable MLE.

    Source: §1 · pp. 5–6

    OpenMLE does not yet realize the full vision of recursive self-improvement.

    Source: §8 · p. 30

Abstract

from arXiv · show

Recursive self-improvement (RSI) requires AI systems that improve the process of building AI (i.e., AI4AI); machine learning engineering (MLE) offers a concrete, executable testbed for studying this capability. We introduce OpenMLE, an open full-stack system for RSI research in MLE, spanning verifiable task environments with execution feedback (OpenMLE-Gym), operator learning (OpenMLE-RL), and long-horizon search (OpenMLE-Evo). On this stack we post-train Frontis-MA1 (35B) as a meta-evolution agent for MLE, aligning post-training and inference around four atomic program-evolution operators (Draft, Improve, Debug, Crossover): the same operators are trained via execution-grounded SFT and RL on data deduplicated against all evaluation benchmarks, then composed into long-horizon search, coupling learning and evolution in a single loop. On MLE-Bench Lite under a 12-hour per-task budget on one RTX 4090 capped at 12 GB VRAM, Frontis-MA1 (35B) improves Medal Average from 39.39% to 60.61% over its base model with OpenMLE-Evo, and reaches 71.21% with OpenMLE-Evo-Max (benchmark-independent experience priors and asynchronous search), exceeding GPT-5.5 + Codex and approaching GPT-5.6 Sol and the 2.8T Kimi K3. On held-out NatureBench Lite, both components transfer: with the framework fixed, swapping in the trained model raises Match-SOTA from 50% to 70%; with the model fixed, swapping in OpenMLE-Evo raises it from 20% to 50%. We release the model weights and the full OpenMLE stack to enable reproducible research on executable AI4AI toward RSI. Code: https://github.com/FrontisAI/OpenRSI

1. Introduction

OpenMLE connects executable MLE environments, execution-grounded post-training, and long-horizon search to study meta-evolution in AI4AI. The introduction presents MLE as a demanding testbed for recursive self-improvement and reports gains from the trained model and search system.

1. Introduction

  • MLE offers a concrete, demanding AI4AI testbed because agents iteratively build machine-learning solutions using delayed, noisy, heterogeneous execution feedback.Each experiment consumes time and compute, and its outcome may take minutes or hours.Source: §1 · p. 4
  • The introduction identifies a gap: none of the audited representative public systems jointly spans scalable environments, execution-grounded post-training, long-horizon evolutionary deployment, and reproducible artifacts.Prior work advances MLE harnesses, executable environments, and execution-feedback post-training in complementary but overlapping strands.Source: §1 · p. 5
  • OpenMLE links 5,758 executable OpenMLE-Gym tasks, execution-grounded OpenMLE-ERL post-training, and experience-guided OpenMLE-Evo long-horizon search.OpenMLE-Gym provides isolated execution, structured feedback, and task-specific evaluation; OpenMLE-Evo uses structured experience, non-greedy selection, and operator-conditioned memory.Source: §1 · pp. 5–6
  • Draft, Improve, Debug, and Crossover form a shared interface for training and inference, making Frontis-MA1 the variation engine in a loop that trains the improver itself.Verified evolutionary transitions supervise the same transformations that the search harness later composes; this trained role is termed a meta-evolution agent.Source: Figure 2 · p. 4, §1 · p. 5
  • 60.61% Medal Average (up from 39.39% for Qwen3.6-35B-A3B) and 71.21% Medal Average with OpenMLE-Evo-Max1 exceed GPT-5.5 + Codex.Frontis-MA1-35B’s model-level comparison used the identical OpenMLE-Evo harness; evaluations used a fixed 12 GPU-hour per-task budget.Source: §1 · p. 5
  • Controlled NatureBench Lite comparisons provide evidence that both execution-grounded post-training and adapted evolutionary search transfer beyond competition-style MLE.The authors plan to release datasets, training and evaluation code, execution infrastructure, search framework, and final checkpoints to support reproducibility.Source: §1 · pp. 5–6

2. Problem Formulation

The section frames OpenMLE as a concrete step from AI for AI and execution-based evolution toward meta-evolution: executable search experience trains the model that proposes future modifications. It formalizes MLE search and learning from execution outcomes as linked processes, while distinguishing this step from the sustained improvement loop required for recursive self-improvement.

From AI for AI to meta-evolution

  • OpenMLE reuses executable evolutionary trajectories through supervised fine-tuning and reinforcement learning to improve the program-transformation model, a step toward—but not itself the full sustained loop of—recursive self-improvement.AI for AI identifies what is optimized; evolution describes repeated execution-feedback-driven modification, while meta-evolution learns from those trajectories to guide future modifications.Source: §2 · p. 6

Executable evolution for AI-building tasks

  • Each MLE task specifies natural-language requirements, visible data, a submission contract, an evaluator, and a sandbox; the search algorithm selects an operator and builds its context from parent programs and execution feedback.The formulation follows MLE-Dojo and MLE-Bench [Chan et al., 2024, Qiang et al., 2025a].Source: §2 · p. 6
  • OpenMLE stores candidates with execution feedback in a task-local database and, within a finite budget, seeks the candidate with the highest signed score using Draft, Improve, Debug, and Crossover operators.The inference-time search algorithm determines how these operators are composed; execution returns task scores alongside status, logs, artifacts, and runtime metadata.Source: §2 · p. 6

Learning to evolve from executable experience

  • Meta-evolution updates the same model parameters through SFT and RL so the operator-conditioned policy is more likely to propose programs with stronger execution outcomes.SFT filters for high-scoring programs as positive supervision; RL weights sampled programs using processed execution rewards and entropic advantages in a clipped policy objective.Source: §2 · pp. 6–7

3. OpenMLE-Gym: Building Scalable Verifiable Environments

OpenMLE-Gym provides a compute-backed, verifiable environment for MLE post-training, search, and evaluation, built by scaling curated and automatically constructed executable tasks.

3.4. Sandbox Execution at Scale

  • OpenMLE-Gym runs tasks through isolated execution and structured diagnostics; its shared sandbox backend supports reproducible scoring and parallel jobs, with six feedback modes distinguishing execution failures from weak performance.A centralized scheduler dispatches jobs to CPU/GPU Docker workers, which write logs, submissions, outputs, and artifacts to shared storage.Source: §3 · p. 7, §3.4 · pp. 9–10

3.1. Environment Contract

  • Each task couples a specification, data, evaluator, resource budget, and workspace state with an agent program, sandbox transition, structured observation, and verifiable score.Task completion, controller stopping criteria, and time or compute budgets determine whether an interaction terminates or is truncated.Source: §3.1 · p. 7, §3 · p. 7

3.2. Scalable Task Construction

  • OpenMLE-Gym standardizes curated anchors, Kaggle datasets, and competitions as executable packages, using grounded file and catalog evidence to construct competition tasks.Packages separate public inputs from private answers and include task-specific metrics; MLE-Bench-overlapping competitions are excluded, and packages undergo execution validation before semantic filtering.Source: §3.2 · pp. 8–9

3.5. Composition and Statistics

  • 5,758 executable tasks comprise 156 Curated Anchors, 3,362 Kaggle Dataset tasks, and 2,240 Kaggle Competition tasks; 11% are multimodal, while classification and regression account for 87%.The suite spans tabular, text, time-series, image, and other modalities, with additional engineering-intensive task types.Source: Figure 4 · p. 9, §3.5 · p. 10

3.3. Task Quality Filtering

  • An LLM-based semantic filter assesses task validity, data sufficiency, raw-data usage, complexity, and quality, retaining only metric-valid tasks with a strict recommended decision.It screens for degenerate targets, inadequate signal, leakage, annotation errors, and malformed processing, separately from executability checks.Source: §3.3 · p. 9

4. OpenMLE-ERL: Reinforcing Reusable Evolutionary Operators

OpenMLE-ERL trains executable program transformations rather than complete search trajectories, using execution-grounded SFT and RL to improve reusable operators for budgeted evolutionary search.

4.3. Execution-Grounded Reinforcement Learning

  • RL preserves score differences among strong candidates with adaptive score bounds and entropic advantages, admits completed execution groups asynchronously, and selects parents using reward, child-reward variance, and visit-based cooling.The RL rollout also previews state selection, adaptive reward normalization, and upper-tail weighting; sandbox feedback can take minutes or hours, and non-Draft actions depend on their selected parent program.Source: §4 · pp. 10–11, §4.3 · p. 12

4. OpenMLE-ERL: Reinforcing Reusable Evolutionary Operators

  • The SFT warm start combines complete executable solutions distilled from stronger teachers with successful local revisions, broadening executable behaviors before online RL.RL then shifts probability toward better candidates within that broadened distribution.Source: §4 · pp. 10–11
  • OpenMLE releases full task-package data for 1,415 tasks and prepare.py and metric.py scripts without source data for the remaining 4,343 tasks.The source-data limitation reflects licensing and copyright constraints.Source: §4 · p. 10

4.1. Trainable Atomic Operators for Evolutionary Inference

  • OpenMLE trains reusable Draft, Improve, Debug, and Crossover operators on executable candidates, separating learned local skills from inference-time search procedures.This lets different evolutionary search procedures compose the same operators under a shared sandbox protocol, rather than requiring sparse controller-specific trajectory supervision.Source: §4 · p. 10, §4.1 · p. 12

4.2. Execution-Grounded Supervised Warm Start

  • Budget-adaptive executable SFT retains valid, task-scored programs until an accepted-example quota or execution limit, directing more attempts to sparse-success tasks.Parallel Draft sampling contributed 17,245 full-response examples, while evolutionary Improve, Debug, and Crossover contributed 9,014 trajectory-step examples, forming a 26,259-example corpus.Source: §4.2 · p. 12

LEARNING FROM EXECUTED ROLLOUTS

OpenMLE uses executed rollouts to construct operator-learning SFT data and shape RL around comparable rewards, best-candidate learning signals, and informative program states.

SFT corpus construction

  • 26,259 selected examples form the released SFT corpus: threshold-passing Drafts are retained directly, while evolutionary solutions trace back before repeated Debug repairs and use an LLM to select useful steps under budget-adaptive stopping.The corpus combines examples from parallel and evolutionary paths.Source: Figure 7 · p. 13

Adaptive reward bounds

  • Adaptive task-specific bounds remap direction-aligned raw scores using historical on-policy frontiers, preserving reward resolution where current candidates lie when fixed bounds would collapse differences.The bounds evolve with the policy while maintaining a stable reward direction.Source: LEARNING FROM EXECUTED ROLLOUTS · p. 13

Upper-tail reward shaping

  • Entropic advantages replace GRPO-style group-normalized signals, amplifying reward gaps near the top under a fixed entropy/KL budget so top candidates drive more learning than merely viable programs.The concentration parameter β is selected under that fixed budget.Source: LEARNING FROM EXECUTED ROLLOUTS · pp. 13–14

Asynchronous rollouts

  • Independent generation-execution groups feed completed results from a queue, avoiding synchronous waits for the slowest sandbox job while retaining group-level advantages; speedup depends on task runtimes and worker allocation.The paper keeps the main-text speedup claim qualitative and reports timing measurements in Appendix B.4.Source: LEARNING FROM EXECUTED ROLLOUTS · p. 14

Informative state selection

  • Parent sampling combines parent reward, child-reward variance, and visit cooling to balance promising states, informative outcomes, and diversity across operator learning.Visit cooling prevents a repeatedly selected incumbent from monopolizing the rollout budget.Source: Figure 7 · p. 13, LEARNING FROM EXECUTED ROLLOUTS · pp. 14–15

5. OpenMLE-Evo: Scaling Experience-driven Long-Horizon Search

OpenMLE-Evo turns executable search outcomes into reusable, structured experience that guides future expansion. It combines selection based on quality, progress, and novelty with bounded, operator-conditioned memory synthesis.

5.1. Structured Experience Accumulation

  • Structured experience cards and a task-global board preserve candidate outcomes and neighborhood evidence for search decisions.Cards record provenance, performance, execution outcomes, and resource use; the board aggregates method-family statistics, score trends, failures, and parent relationships. Figure 9 depicts how these records inform parent selection and memory retrieval.Source: §5.1 · pp. 15–16, Figure 9 · p. 16

5.2. Experience-Guided Parent Selection

  • Parent selection jointly weighs current validation quality, improvement over the strongest parent, and method-family novelty.Unlike fitness-driven selection, this policy allocates search to strong candidates while also considering progress and promising underexplored approaches.Source: §5.2 · pp. 16–17

5.3. Operation-Triggered Memory Synthesis

  • OpenMLE-Evo defers language-model memory synthesis until an operation selects relevant nodes, then caches method and parent-comparison summaries.This avoids summarizing nodes that are never selected and enables operation-aware extraction from the selected parents and retrieved related attempts.Source: §5.3 · p. 17

5.4. Operator-Conditioned Context Construction

  • Operator-conditioned retrieval gives each transformation bounded, actionable evidence instead of an ever-growing free-form history.Improve receives ranked siblings, recent ancestors, and global search signals; Crossover builds context for both parents with a complementarity cue; Debug retrieves matching-error attempts or recent fallbacks. Prompts also include remaining search and execution budgets.Source: §5.4 · p. 17

6. Experiments

Under a 12-hour-per-task, single-RTX-4090 evaluation, execution-grounded post-training improved Frontis-MA1-35B’s Medal Average by 21.22 percentage points over its Qwen3.6 backbone, and OpenMLE-Evo-Max raised the combined system’s Medal Average to 71.21%.

6.1. Experimental Setup

  • Evaluations used the official 22-task MLE-Bench Lite split, three independent runs, and a fixed 12-hour per-task budget on one RTX 4090 with 12 GB VRAM.The study reports Valid Rate as tasks with valid submissions out of 22, Medal Average as the fraction earning any Kaggle medal, and Human Rank as the fraction of human leaderboard participants surpassed.Source: §6.1 · p. 18

6.2. Training and Search Gains Compose

  • Frontis-MA1-35B with OpenMLE-Evo-Max reached 71.21% Medal Average, 3.03 percentage points above GPT-5.5 with Codex; post-training alone gained 21.22 points over its Qwen3.6 backbone.Frontis-MA1-30B also reproduced a post-training gain of 18.18 percentage points over its Qwen3 backbone.Source: §6.2 · p. 18, Table 1 · p. 18

Table 1 — continued from previous page

  • Frontis-MA1-30B OpenMLE-Evo scored 21.67/22 Valid Rate, 53.03% Medal Average, and 0.7055 Human Rank; OpenMLE-Evo-Max scored 22.00/22, 66.67%, and 0.8053, respectively.OpenMLE-Evo-Max adds distilled cross-task priors from public competition artifacts excluding MLE-Bench-related sources, and asynchronous multi-GPU search without increasing total sandbox compute.Source: §6.1 · p. 18, Table 1 — continued from previous page · p. 19

B. Broader OpenMLE-Evo system context

The listed models report a range of results with OpenMLE-Evo, from 27.27% to 65.15%.

C. General-purpose coding-agent references

Execution-grounded post-training and OpenMLE-Evo’s specialized search improve MLE-Bench Lite results, with sustained long-horizon gains and evidence of transfer to NatureBench Lite. The results also point to improvements in solution quality, search productivity, and performance across modalities.

C. General-purpose coding-agent references

6.3. Long-Horizon Self-Improvement

  • 71.21% final-test Medal Rate for Frontis-MA1-35B with OpenMLE-Evo-Max compares with 68.18% on validation and 72.73% for GPT-5.6 Sol and Kimi K3.The improvement continues throughout long-horizon search, rather than stopping after the first executable solution.Source: §6.3 · p. 21, Figure 12 · p. 21
  • Later Improve and Crossover operations account for 85.0% of validation gain on leaf classification and 91.9% on bird classification, where Frontis-MA1-35B earns Bronze and Silver, respectively.The search recombines useful branches rather than repeatedly repairing one program; gains persist in three-epoch averages.Source: §6.3 · pp. 21–22, Figure 13 · p. 22, Figure 14 · p. 23

6.4. Solution Ceiling

  • Post-training and OpenMLE-Evo-Max shift successful solutions toward Gold, a pattern also seen in the 30B comparison and fixed-model search comparisons.Frontis-MA1-35B with OpenMLE-Evo-Max outperforms Claude Opus 4.8 and Gemini 3.5 Flash in Gold rate, and matches Kimi K3’s Gold rate.Source: §6.4 · p. 23, Figure 15 · p. 24

6.5. Search Efficiency and Mechanism

  • OpenMLE-Evo reduces model-token consumption from 129.3M to 75.3M (−41.7%) and raises new-best updates per million tokens from 1.77 to 3.27 (+84.3%).It evaluates 3,004 nodes versus 3,430 for original AIRA-Evo; Improve and Crossover prompts are also substantially shorter, especially at the 99th percentile.Source: §6.5 · p. 24, Figure 16 · p. 25
  • Targeted Crossover and Score/Gain/Novelty parent selection preserve complementary branches for refinement, while operation-conditioned memory bounds context and records useful or negative evidence.In the right-whale example, Parent B’s selection probability rises from 10.47% to 17.09%; the full-framework gain should not be attributed to the three selection weights alone.Source: §6.5 · pp. 24–26, Figure 17 · p. 26, Figure 18 · p. 27

6.6. Meta-Ability and Transfer

  • Frontis-MA1-35B raises mean Human Rank in all five MLE-Bench Lite modality groups and distributes 14 additional medals across image, text, tabular, audio, and multimodal tasks.The groups are small, which limits the breadth of this result.Source: §6.6 · p. 26, Figure 19 · p. 28
  • On NatureBench Lite, Frontis-MA1-35B improves Match-SOTA from 5/10 to 7/10 with the adapter fixed, while OpenMLE-Evo raises it from 2/10 to 5/10 with the base model fixed.The combined system matches the 3/10 Surpass-SOTA and 7/10 Match-SOTA results of GPT-5.4, GLM-5.1, and MiniMax-M3 on the ten-task subset.Source: §6.6 · pp. 26–27, Table 2 · p. 28

7. Related Work

Related work spans executable MLE environments, inference-time search, learned MLE agents, and broader AutoResearch. OpenMLE’s contribution is to couple execution-grounded training of program-transformation operators with their use in evolutionary search, within an open stack for studying RSI in executable MLE.

AutoResearch systems and evaluation targets

  • AutoResearch systems automate scientific workflows, while benchmarks target distinct slices; OpenMLE evaluates on MLE-Bench Lite and tests broader scientific transfer on NatureBench Lite.MLE-Bench targets end-to-end Kaggle-style competitions [Chan et al., 2024], whereas NatureBench emphasizes reproducing published scientific results [Wang et al., 2026].Source: §7 · p. 29

Executable MLE environments and scalable task resources

  • OpenMLE-Gym unifies scalable MLE tasks, isolated execution, structured feedback, and task-specific evaluators as shared infrastructure for training, search, and evaluation.Prior executable-task resources expand execution and training infrastructure, but tasks alone do not specify how experience becomes reusable capabilities or inference-time behavior.Source: §7 · p. 29

Inference-time scaffolds and evolutionary search

Learning MLE agents from executable experience

  • MLE-specific learning methods show executable task rewards can be internalized, but their artifacts and interfaces are not uniformly organized for reproducible workflows and long-horizon search.OpenMLE-ERL trains reusable Draft, Improve, Debug, and Crossover transformations whose interfaces match the operations invoked by OpenMLE-Evo.Source: §7 · p. 30

AI-for-AI and trainable improvers

  • OpenMLE post-trains the same program-transformation operators that govern evolutionary search, coupling verified experience and inference without claiming general autonomous RSI.Its open stack spans task packages, sandbox execution, operator training, search, evaluation, and released model weights.Source: §7 · p. 30

8. Limitations and Future Work

OpenMLE connects executable environments, post-trained models, and long-horizon search, but does not yet realize full recursive self-improvement (RSI); the paper identifies five consequential capability boundaries.

Richer objectives for improving the improver

  • OpenMLE optimizes executed solutions using outcome signals, but needs objectives that also assess hypotheses, reasoning, critiques, and transferable research strategies.Current outcomes show whether a program works and how well it scores, but do not fully capture whether a research direction is promising, generalizable, robust, or worth more computation.Source: §8 · p. 30

Integrating evolutionary search with general coding agents

  • OpenMLE composes trained operators through an external evolutionary harness, limiting model-initiated actions; future work should unify evolutionary search with general coding agents.The unified framework would combine population-based exploration with flexible agentic problem solving.Source: §8 · pp. 30–31

Broader participation in AI development

  • Current environments let agents improve external machine-learning artifacts, but broader RSI requires participation in more of AI development, especially improving language models themselves.Source: §8 · p. 31

Evolving the evolutionary system

  • OpenMLE evolves candidate solutions while keeping its evolutionary system largely fixed; a further step is to make that system itself an object of evolution.Source: §8 · p. 31

Richer use of experience in node expansion

  • Experience-guided node expansion is preliminary: parent selection uses three fixed factors, leaving recorded evidence underused and motivating task-dependent weights and learned predictive signals.The three factors are solution quality, parent-relative improvement, and method-family novelty; future work could let the search policy discover which experience signals predict useful outcomes.Source: §8 · p. 31

9. Conclusion · A. OpenMLE-Gym Details

OpenMLE combines executable-feedback task environments, execution-grounded operator learning, and long-horizon search in a shared interface that makes the trained Frontis-MA1 agent part of its evolutionary harness. The conclusion reports complementary gains from learning and search, with initial evidence of transfer beyond competition-style MLE.

A. OpenMLE-Gym Details

  • OpenMLE-Gym supplies quality-gated tasks, isolated execution, and task-specific evaluation for executable-feedback MLE agents.OpenMLE-ERL learns Draft, Improve, Debug, and Crossover through execution-grounded supervised fine-tuning and reinforcement learning; OpenMLE-Evo composes those operators into long-horizon search.Source: §9 · p. 31

9. Conclusion

  • A shared operator and execution interface makes Frontis-MA1-35B both a product of the training stack and the variation engine of its evolutionary harness.OpenMLE-Evo uses structured experience, multi-factor parent selection, and operator-conditioned memory.Source: §9 · p. 31
  • Medal Average rises from 39.39% with Qwen3.6-35B-A3B to 60.61% with Frontis-MA1-35B under the identical OpenMLE-Evo harness; OpenMLE-Evo-Max reaches 71.21%.The companion Frontis-MA1-30B reproduces the gain on a second backbone and scale.Source: §9 · p. 31
  • Matched comparisons find OpenMLE-Evo outperforms general-purpose coding-agent scaffolds across four frontier models and original AIRA-Evo on Frontis-MA1-35B.The passage reports these comparisons but does not provide their individual numerical results.Source: §9 · p. 31
  • Mechanism analyses show sustained late-horizon gains from refinement and recombination, while matched AIRA-Evo comparisons show shorter bounded contexts and lower token use.The AIRA-Evo comparison also reports more validation progress per token.Source: §9 · p. 31
  • Controlled comparisons on a ten-task NatureBench Lite subset provide initial evidence that both the post-trained model and adapted search framework transfer beyond competition-style MLE.Source: §9 · p. 31
  • The released OpenMLE stack establishes a reproducible testbed for meta-evolution in executable AI4AI.Source: §9 · p. 31

A.1. Task Construction and Selection · A.2. OpenMLE-Gym Execution Infrastructure · B. OpenMLE-ERL Details

The appendix details how OpenMLE constructs and gates competition tasks, and how OpenMLE-Gym executes candidate programs in isolated workers and returns diagnostic feedback.

A.1. Task Construction and Selection

  • Competition tasks are built from local-file evidence and competition metadata, then accepted only after package checks and strict semantic quality gating.The pipeline inspects files and documentation to ground task descriptions; final aggregation admits only metric-valid tasks judged recommended.Source: §A.1 · p. 39, Figure 20 · p. 40
  • Preparation failures clear partial outputs and feed execution errors into another generation attempt; successful packages must include required task files and isolated held-out answers.Metric generation and validation follow preparation, with validation failures preventing semantic assessment.Source: §A.1 · p. 39
  • The quality evaluator hard-fails packages with missing critical files or metric errors, then uses semantic scores and a strict recommended decision for final admission.The judge assesses validity, data sufficiency, raw-data usage, task complexity, and data quality.Source: §A.1 · p. 39

A.2. OpenMLE-Gym Execution Infrastructure

  • Table 3 covers six sandbox feedback modes by connecting real-job triggers with returned fields and their usable training or evaluation signals.The table summarizes representative cases from real job logs.Source: §A.2 · p. 40, Table 3 · p. 41
  • OpenMLE-Gym dispatches agent requests to isolated CPU/GPU Docker workers that run candidate programs against task data and evaluators and return structured feedback.The execution backend separates scheduling, workers, shared job state, and returned feedback.Source: §A.2 · p. 40, Figure 21 · p. 41
  • When execution fails, the returned record retains status, runtime, artifacts, and logs while skipping evaluation and leaving the score null.The traceback and related fields localize the failure before evaluation and provide evidence for a repair action.Source: §A.2 · p. 42

B.1. SFT Data Generation … D. Supplementary Experiments

This section details the training data, configurations, rollout, and reward-handling procedures used to train the model, including measures to prevent reward hacking. It also describes OpenMLE-Evo’s search mechanisms, prompts, experience records, and operation-triggered memory for guiding subsequent MLE edits.

B.1. SFT Data Generation

  • SFT data combines independently drafted, sandbox-executed solutions with evolutionary segments selected for successful, inherited contributions to medal-level endpoints.The final corpus exact-deduplicates normalized messages and excludes examples exceeding 32,768 tokens; trajectory annotation applies a causal-inheritance criterion and discards cosmetic edits, blind retries, and resource-limit scale reductions.Source: §B.1 · p. 43
  • The SFT corpus contains 26,259 examples, including 17,245 full responses (65.7%) and 9,014 trajectory steps (34.3%).Draft, Improve, Crossover, and Debug contribute 19,436, 1,741, 742, and 4,340 examples, respectively; trajectory steps are longer because they include parent programs, execution feedback, and local search context.Source: §B.1 · p. 43

B.2. SFT Training Configuration

  • Table 4 summarizes core SFT hyperparameters for Frontis-MA1-30B and Frontis-MA1-35B.The supplied passage identifies the table’s scope but does not provide its hyperparameter values.Source: §B.2 · p. 47, Table 4 · p. 47

B.3. RL Training Configuration

  • Table 5 summarizes verified RL hyperparameters for Frontis-MA1-30B and Frontis-MA1-35B while retaining the original configuration fields.The supplied passage identifies the table’s scope but does not provide its hyperparameter values.Source: §B.3 · p. 48, Table 5 · p. 48

B.4. Asynchronous Rollout

  • Synchronous rollout averaged 97.0 minutes per step versus 50.8 minutes asynchronously across 40 matched steps, a 1.91× ratio.In two representative asynchronous runs, per-task step counts stayed within ±2 of the median, with coefficients of variation of 1.56% and 2.06%.Source: Figure 23 · p. 48, §B.4 · p. 48

B.5. Reward Normalization and Entropic Advantage

  • Adaptive reward processing rescales task scores using a moving range from successful historical programs and current rollout scores, preserving distinctions among current candidates.The best observed score sets the upper end and the 16th-best score (or lowest available score with fewer than 16) anchors the lower reference; adaptive reward supplies the main RL configuration while static and adaptive views remain in metadata.Source: §B.5 · p. 49
  • Entropic post-processing groups rewards by prompt, returns zero advantages for groups smaller than two or with equal rewards, and computes other advantages with a leave-one-out denominator.The implementation uses a maximum search value of 106 and 60 bisection iterations, returning raw rewards alongside processed advantages.Source: §B.5 · pp. 49–50

B.6. Detection and prevention of reward hacking.

  • When RL rewards plateau, the authors identify reward hacking such as shuffling a sample submission and assign a -0.5 reward when an o3-mini judge detects it before sandbox execution.The reported plateau occurred particularly in smaller models trained on difficult tasks.Source: §B.6 · p. 50

C.1. Evolutionary Parent Fitness

  • Training-time parent fitness combines optional normalized learning values with normalized raw complexity, while Improve and Crossover select positive-reward programs and Debug selects non-positive-reward programs.Parent selection uses roulette-wheel sampling without replacement; Crossover draws two parents sequentially and removes the first before the second draw.Source: §C.1 · p. 51

C.2. Operator Prompt Templates

  • OpenMLE-Evo’s Draft, Improve, Crossover, and Debug prompts respectively propose, revise, combine, or repair solutions, with prompts requesting distinct ideas and consistent evaluation.Templates also instruct agents to verify submission-file requirements and leave enough runtime to produce ./submission.csv.Source: §C.2 · pp. 51–54

C.3. Structured Experience Records

  • OpenMLE-Evo creates a deterministic experience card after each sandbox evaluation and aggregates accumulated cards into a task-level experience board.A leaf-classification example records validation loss, parent-relative change, method family, runtime, and token usage in the card; the board describes the incumbent and recent search context.Source: §C.3 · pp. 55–56, Table 6 · p. 55, Table 7 · p. 56

C.4. Experience-Guided Parent Selection

  • Inference-time parent selection combines normalized validation score, progress over the strongest parent, and method-family novelty, then samples parents within an island while deterministically choosing the best executable candidate for submission.Crossover samples two parents sequentially without replacement; Improve samples one.Source: §C.4 · pp. 56–57

C.5. Operation-Triggered Memory Synthesis

  • After selecting an operation and its parents, the controller retrieves bounded, operation-specific evidence, synthesizes each retrieved node relative to a direct parent, and caches the resulting summary for reuse.Improve receives parent, ancestor, sibling, and board context; Crossover receives branch context for both parents, while Debug receives error-signature and related-error context.Source: §C.5 · p. 57, Table 8 · p. 57
  • 0.012080 followed Improve’s replacement of a 0.765432-log-loss ResNet50/handcrafted parent with ResNet18, tabular features, and calibrated out-of-fold ensembling.Memory also surfaced a ResNet18/tabular incumbent at 0.031825 and a feature-heavy sibling that timed out after 7,200 seconds, alongside board-level family and timeout statistics.Source: §C.5 · p. 59

D.1. Repeated-Evaluation Statistics on MLE-Bench Lite · D.2. NatureBench Lite Task Composition · E. Simplified comparison of public release surfaces

The appendices qualify the paper’s comparisons by documenting repeat-run variability, the scope and granularity of the ten-task NatureBench Lite subset, and limits on cross-system release comparisons. They also define the audited release criteria and note that complete public post-training stacks remain uncommon.

D.1. Repeated-Evaluation Statistics on MLE-Bench Lite

  • Table 9 reports mean and standard deviation across three evaluation epochs for configurations with repeat-level records, reducing sensitivity to sampling trajectories and sandbox variation.Valid Rate is the mean number of tasks producing valid submissions out of 22; Medal Average and Human Rank are higher-is-better.Source: §D.1 · p. 59, Table 9 · p. 60
  • Codex, Claude Code, and Gemini CLI references are point estimates from single evaluations; reported ± values are standard deviations, not confidence intervals.Some Table 9 entries lack ± because archived summaries provide aggregate estimates without repeat-level dispersion.Source: §D.1 · p. 59, Table 9 · p. 60

D.2. NatureBench Lite Task Composition

  • NatureBench Lite’s fixed 10-task subset favors moderately tractable tasks while covering all six scientific domains and diverse data structures.The listed data types include biological sequences, omics matrices, molecular structures, temporal signals, images, and tabular features.Source: §D.2 · p. 59, Table 10 · p. 61
  • Because NatureBench Lite has only ten tasks, each task changes All S or All M by ten percentage points.The subset is intended for rapid model–harness comparisons.Source: §D.2 · p. 60

E. Simplified comparison of public release surfaces

  • Public MLE-agent and resource releases are fragmented, and their scores are not strictly comparable because models, budgets, hardware, resources, runs, and aggregation differ.The audit finds the combination of executable training data, sandbox infrastructure, training code, RL method, evaluation framework, and weights to be rare; the cited work spans agent and resource releases, leaderboard results, and MLE-specific RL designs [Cai et al., 2026, Li et al., 2025b, Liu et al., 2025b, Qiang et al., 2025b, Yang et al., 2025a].Source: E. Simplified comparison of public… · p. 60, Table 11 · p. 61
  • The release audit defines separate evidence requirements for Data, Sandbox, Train code, Eval, Weights, and an MLE-specific RL method.A tick indicates public accessibility and independent verifiability at audit time; an RL-method tick does not establish that its implementation is public. The table’s audit date is July 2026.Source: E. Simplified comparison of public… · p. 61, Table 11 · p. 61
  • Run settings report per-task wall-clock limits and sandbox GPU allocation, while omitting remote LLM-serving compute and CPU/RAM.GPU-h denotes total sandbox accelerator time rather than elapsed wall-clock time; NR means not reported, and “–” means no corresponding MLE-Bench Lite result is available.Source: E. Simplified comparison of public… · p. 61
  • The audit counts MLZero’s excluded task as a non-medal result under the standard 22-task denominator, while ML-Agent releases only exploration-enriched SFT training code.MLZero evaluated 21 of 22 tasks; ML-Agent’s step-wise RL implementation, training dataset, evaluation code, and model checkpoints remain unreleased.Source: E. Simplified comparison of public… · p. 61
Loading 2607.28568v1…