# Towards Execution-Grounded Automated AI Research

###### Abstract

Automated AI research holds great potential to accelerate scientific discovery. However, current LLMs often generate plausible-looking but ineffective ideas. Execution grounding may help, but it is unclear whether automated execution is feasible and whether LLMs can learn from the execution feedback. To investigate these, we first build an automated executor to implement ideas and launch large-scale parallel GPU experiments to verify their effectiveness. We then convert two realistic research problems – LLM pre-training and post-training – into execution environments and demonstrate that our automated executor can implement a large fraction of the ideas sampled from frontier LLMs. We analyze two methods to learn from the execution feedback: evolutionary search and reinforcement learning. Execution-guided evolutionary search is sample-efficient: it finds a method that significantly outperforms the GRPO baseline (69.4% vs 48.0%) on post-training, and finds a pre-training recipe that outperforms the nanoGPT baseline (19.7 minutes vs 35.9 minutes) on pre-training, all within just ten search epochs. Frontier LLMs often generate meaningful algorithmic ideas during search, but they tend to saturate early and only occasionally exhibit scaling trends. Reinforcement learning from execution reward, on the other hand, suffers from mode collapse. It successfully improves the average reward of the ideator model but not the upper-bound, due to models converging on simple ideas. We thoroughly analyze the executed ideas and training dynamics to facilitate future efforts towards execution-grounded automated AI research.

###### Keywords:

## 1 Introduction

We envision automated AI research: LLMs generate research ideas to tackle important research problems, implement the ideas as code, run experiments to verify the effectiveness, and continuously learn from the execution results. If successful, these automated AI researchers could automatically develop and identify effective research ideas in a massive search space, thereby scalably converting compute into scientific discovery; the discovered ideas could, in turn, improve frontier AI models themselves, enabling recursive self-improvement. Despite the promise, automated AI research is bottlenecked by the ability of LLMs to generate effective ideas. Si et al. (2025b) and Si et al. (2025a) evaluated the quality of LLM-generated research ideas through large-scale expert review and found that LLM ideas often look convincing but are ineffective after being executed by human researchers.

This highlights the need to ground idea generation in execution. However, obtaining execution results of ideas in an automated and scalable manner is challenging, especially since we are targeting open-ended AI research where any ideas expressible in natural language are within our action space. To tackle this, we design and build a high-throughput automated idea executor that can implement hundreds of model-generated ideas and execute them in parallel to obtain the experiment results as execution feedback.

To study the extent to which we can automate realistic LLM research, we chose two GPU-intensive research problems (LLM pre-training and post-training) that are critical for improving the capabilities of LLMs as the research environments for our automated AI researchers. For the first time, we demonstrate that our automated executor can implement a large fraction of LLM-generated ideas on these challenging open-ended research problems, with over 90% execution rates on the pre-training environment with Claude-4.5-Sonnet and Claude-4.5-Opus.

To analyze whether grounding on execution-feedback can improve LLM idea generation, we define objective performance metrics for both environments and analyze the strengths and weaknesses of two popular learning algorithms: evolutionary search and reinforcement learning.

We use our automated executor to guide evolutionary search. Within ten search epochs, this execution-guided search finds a post-training recipe that outperforms the GRPO baseline (69.4% vs 48.0%) on the task of post-training a 1.5B model for math reasoning, and a pre-training recipe that outperforms the nanoGPT baseline (19.7 minutes vs 35.9 minutes) on the task of minimizing the training wall-clock time to reach the target validation loss (Table 1 ). Our analysis shows that models are often generating algorithmic ideas apart from tuning hyper-parameters, and evolutionary search significantly outperforms best-of-N under the same sampling budget. However, when analyzing the scaling trend, only Claude-4.5-Opus shows a clear scaling curve, while both Claude-4.5-Sonnet and GPT-5 tend to saturate early.

We then use the automated executor as the reward function in an RL loop to finetune Qwen3-30B. We show that RL with execution reward can successfully improve the average reward of the ideator model, similar to typical RL from verifiable rewards. However, RL does not improve the max reward, which is the more important metric for scientific discovery. In fact, we reveal that RL causes the ideator model to converge on a few easy-to-implement ideas, resulting in a collapse in thinking length and idea diversity.

In summary, we develop a large-scale automated idea executor system that can implement research ideas for open-ended and realistic research problems. Using this automated executor, we conduct an in-depth analysis of how well LLM ideators can learn from execution feedback to improve effectiveness through evolutionary search and RL. Execution-guided evolutionary search is sample-efficient and effective, but shows limited scaling. RL from execution reward suffers from diversity collapse and does not improve the upper-bound. We additionally provide extensive analysis on the executed ideas and suggest promising directions to improve the existing learning algorithms. Altogether, we demonstrate the feasibility and potential of grounding LLM ideation in automated execution and uncover important limitations for future improvement.

## 2 Automated Idea Executor

To measure the effectiveness of model-generated ideas, we build an automated executor that takes natural language research ideas as input, generates code implementations, runs the experiments on the backend, and returns the idea’s benchmark performance as the final output.

### 2.1 Research Environments for Ideation

Our automated idea executor is grounded in specific research environments, where each environment consists of a research problem, a baseline codebase, a benchmark to measure performance on, fixed training and evaluation data, and evaluation metrics. When constructing the research environments, we aim to select research problems that are open-ended, so that there is ample room for new algorithmic innovations, and at the same time have well-established baselines and benchmarking metrics so that measuring effectiveness is straightforward. In this work, we construct both a pre-training environment and a post-training environment for the automated AI researchers to work on. 1 1 1 We open-source our environments and idea execution trajectories in https://github.com/NoviScl/Automated-AI-Researcher .

Pre-Training Task: Improving nanoGPT In the nanoGPT environment, we provide a baseline codebase adapted from the nanoGPT speedrun ( Jordan et al., 2024 ) and ask the ideator model to brainstorm possible improvements. The original speedrun task is to minimize the time to pre-train a 124M GPT-2 model ( Radford et al., 2019 ) on the FineWeb corpus ( Penedo et al., 2024 ) to reach a validation loss of 3.28 on the validation set on 8 H100 GPUs. We did several modifications to the original speedrun setting. First, we introduce a proxy reward equal to the reciprocal of the validation loss ( 1 l ​ o ​ s ​ s \frac{1}{loss} ) when performing the search and RL experiments in later sections of the paper. This way, we can fix the training wall-clock time to be 25 minutes and ask the model to directly optimize the proxy reward under this fixed budget, so that we can avoid different runs having vastly different runtimes. We report the validation loss or the proxy reward metric in most plots, and only measure and report the training time metric for the top solution in order to directly compare it with the human experts’ solutions on the original nanoGPT speedrun leaderboard. Second, to avoid any possible reward hacking, we freeze all evaluation hyper-parameters and implement an inference function that predicts one future token at a time to prevent models from changing the attention mechanism in a way that leaks future tokens (which happened multiple times during our initial development). We use this inference function during the final validation after each training run.

Post-Training Task: Improving GRPO In the GRPO environment, the baseline is an implementation of the GRPO algorithm ( Shao et al., 2024 ) that finetunes a Qwen2.5-Math-1.5B checkpoint ( Yang et al., 2024 ) on the MATH dataset ( Hendrycks et al., 2021 ) . The ideator model needs to brainstorm post-training algorithms that are more effective than the baseline. We specify a fixed training wall-clock time budget and use the max accuracy on the MATH validation set during training as the metric. To prevent reward hacking, we keep all validation-related code in a separate file and do not allow the automatic executor to access or modify it.

In both environments, we do not set any constraints on the ideation scope, so anything between extensive hyperparameter tuning and novel model architecture or training algorithms is within scope.

### 2.2 System design

The automated idea executor can be viewed as a high-level API whose input is a batch of natural language ideas, and the output is the benchmark performance of each idea. There are three core building blocks of this API (Figure 1 ): Implementer – the server that generates the code diff for the idea and applies those changes; Scheduler – a middle layer that receives the list of codebases and allocates resources to run experiments; Worker – the cluster with GPU available that runs the experiments and uploads the experiment results.

#### Implementer

The implementer is hosted on a CPU machine with high IO capacity. First, the user submits a batch of natural language ideas. Then, for each idea, the implementer makes parallelized API calls to the code execution LLM to obtain a diff file that can be patched into the corresponding baseline codebase. To optimize for efficiency, we prompt the code execution LLM with both the idea and the baseline codebase to sample 10 10 code diff files in parallel. For each sample, if the generated diff file cannot be patched into the original codebase, we provide the patch log and ask the model to revise the original generation. We repeat this sequential self-revision for a maximum of 2 2 times. In the end, we return the first code diff file that can be successfully patched into the baseline codebase. The patched codebase is then submitted to a cloud bucket as a .zip file.

#### Scheduler

Under a set clock frequency, the scheduler downloads the new codebases from the cloud. If the codebase has not been executed, the scheduler examines the resource requirement of the given research environment and prepares a job configuration to be submitted.

#### Worker

Once the scheduler finds available resources, it connects the prepared job configuration with the GPU resource and initializes the worker to run the experiment. If the execution of the experiment is successful, the worker will upload the experiment logs including all performance metrics to another cloud bucket ( wandb ) along with the complete metadata: idea content, code change, execution log, etc. If the execution fails (e.g., due to bugs in code implementation), the worker halts. The user (i.e., the ideator model) can then download the execution results and see the performance of the batch of ideas they submitted with full training logs.

## 3 Benchmarking LLM Ideators and Executors

The prerequisite for an execution-grounded feedback loop is that current LLMs can serve as both ideators and executors, so that we can get meaningful reward signals for the models to learn from. To examine this prerequisite, we first benchmark various frontier LLMs as both the ideator and the executor.

### 3.1 End-to-End Ideation and Execution

In the first setting, we sample ideas from an LLM, and use the same LLM as the code execution model to execute its own ideas. We sample and execute 50 ideas from Claude-4.5-Opus, Claude-4.5-Sonnet, and GPT-5, and measure several metrics: (1) completion rate: the percentage of ideas that are successfully executed with a valid (non-zero) experiment result after execution; (2) average performance: the average validation accuracy or loss for all the successfully executed ideas among the 50 samples; (3) best performance: the highest validation accuracy or lowest validation loss among all executed ideas. We present results in the top row of Figure 2 . Notably, a large fraction of the sampled ideas can indeed be executed successfully, with Claude-4.5-Opus and Claude-4.5-Sonnet having a significantly higher execution rate than GPT-5. Moreover, the best-of-N performance ( N = 50 N=50 ) of these models can already beat the original baseline solutions. For example, on the GRPO environment, Claude-4.5-Sonnet gets a max accuracy of 60.4% as compared to the baseline of 48.0%; on nanoGPT, Claude-4.5-Opus gets a lowest loss of 3.237 as compared to the baseline of 3.255.

### 3.2 Comparing Ideators with the Same Executor

In the second setting, we fix the executor model to be GPT-5 and use different ideator models to sample ideas. As shown in the bottom row of Figure 2 , even when the ideator and executor are different models, the execution rate is still decent (ranging from 42% to 78%), although we do notice that the same ideas from Claude-4.5-Sonnet get a lower execution rate when executed by GPT-5 instead of itself (84% vs 42% on GRPO and 90% vs 78% on nanoGPT). Moreover, frontier open-weight models like Kimi-K2-Thinking ( Kimi Team, 2025 ) and Qwen3-235B-A22B ( Yang et al., 2025a ) can also get non-trivial completion rates and achieve best-of-N performance that outperforms the baseline solutions in this setting. For example, Qwen3-235B achieves a max accuracy of 50.2% on GRPO and min loss of 3.238 on nanoGPT with N = 50 N=50 , both better than the baselines.

These benchmarking results demonstrate the feasibility of the automated ideation and execution loop. Next, we build search scaffolds and RL training loops to examine whether models can learn from the execution feedback.

## 4 Execution-Guided Evolutionary Search

Evolutionary search ( Koza, 1994 ; Lehman et al., 2023 ) is a traditional optimization method without the need for gradient updates. We develop an evolutionary search scaffold on top of frontier LLMs to optimize for effective ideas based on execution feedback. We introduce our search method that blends exploration and exploitation, its effectiveness on our two research environments, and various analyses of the generated ideas throughout the evolutionary search process.

### 4.1 Search Scaffold

Our search method is inspired by prior evolutionary search approaches for code optimization, such as AlphaEvolve ( Novikov et al., 2025 ) . Our algorithm is detailed in Algorithm 1 . At the first search epoch, we sample a full batch of new ideas. In all subsequent epochs, we split the idea generation into exploitation and exploration subsets. For exploitation, we choose ideas from previous epochs that outperform the baseline and append them to the idea generation prompt to ask the ideator model to generate new variants that combine their strengths. For exploration, we randomly sample ideas from previous epochs to append to the idea generation prompt until reaching the max context length and instruct the ideator model to generate completely new ideas different from them. We start with 50% exploitation and 50% exploration at epoch 1 and gradually anneal the exploration rate and increase the exploitation ratio in later epochs. We use a batch size of 50 for the GRPO environment and a batch size of 80 for the nanoGPT environment.

### 4.2 Experiment Results

For each environment, we perform execution-guided search with three different models: Claude-4.5-Opus, Claude-4.5-Sonnet, and GPT-5. For each experiment, we use the same model as both the ideator and executor (i.e., self-execution). We plot the progression of the best performance at each search epoch in Figure 3 . We summarize several notable trends below.

First, we observe a scaling trend with Claude-4.5-Opus, where searching for more epochs leads to a higher upper bound. In contrast, Claude-4.5-Sonnet and GPT-5 tend to saturate early. Second, all models can find ideas that significantly outperform the baselines. On GRPO, Claude-4.5-Sonnet finds that using vanilla policy gradient with the group-average baseline without importance reweighting or clipping outperforms the standard GRPO objective in this particular experiment setup and exploits this finding in all subsequent search epochs, resulting in the best solution of 69.4% at epoch 2 with precise hyper-parameter tuning. On nanoGPT, Claude-4.5-Opus achieves the min validation loss of 3.1407 at epoch 9 by combining various architectural modifications, hyper-parameter tuning, and applying exponential moving average of intermediate checkpoints during validation (see Appendix A.2 for the full idea). We run this top solution on 8 H100s to follow the same setup as the nanoGPT speedrun, and it reaches the 3.28 target validation loss in 19.7 minutes, a significant speedup as compared to the baseline codebase, which takes 35.9 minutes of training time to reach the same target validation loss.

To better contextualize these solutions optimized by the model, we also compare the top performance of our execution-guided search to human experts (Table 1 ). For the GRPO environment, we compare with the leaderboard of the Stanford CS336 graduate-level LLM class, which hosted the same environment as an assignment for all students to optimize the validation accuracy under the same training time budget. The best student solution 2 2 2 https://github.com/stanford-cs336/assignment5-alignment-leaderboard achieved an accuracy of 68.8%, lower than Claude-4.5-Sonnet’s top solution using our execution-guided search. For the nanoGPT environment, we directly compare with the nanoGPT speedrun leaderboard, 3 3 3 https://github.com/KellerJordan/modded-nanogpt where the top human solution as of December 2025 can reach the target validation loss under 2.1 minutes, indicating significant headroom for further model capability and search method improvement on this environment.

### 4.3 Comparison with Best-of-N

To demonstrate the effectiveness of our search scaffold, we compare our execution-guided search with the best-of-N baseline with the same sampling budget on the nanoGPT environment. Since the batch size for our search is 80, we compare the first 3 epochs of the execution-guided search using the GPT-5 backbone with the best-of-N results of GPT-5 with N ∈ { 80,160,240 } N\in\{80,160,240\} . As shown in Figure 4 , search and best-of-N start from similar performance at epoch 0 (they are not exactly the same due to variances from sampling), but evolutionary search significantly outperforms best-of-N from epoch 1 onward, demonstrating that the model is effectively leveraging trajectories from previous epochs to generate more effective ideas in future epochs.

### 4.4 Analysis of Generated Ideas

Hyper-parameter vs Algorithmic To quantitatively understand the types of ideas that models generate during the execution-guided search, we perform a stratified analysis by classifying all generated ideas into either hyper-parameter tuning (including any ideas that can be implemented via changing existing configs) or algorithmic (including all ideas that involve implementing new changes not originally supported by the baseline codebase) by using an LLM-judge. Based on Table 2 , all three models generate a substantial amount of algorithmic ideas apart from hyper-parameter tuning. Interestingly, different models exhibit different patterns, where Claude-4.5-Sonnet generates significantly more hyper-parameter ideas than both Claude-4.5-Opus and GPT-5. Moreover, the most effective ideas come from algorithmic ideas in most cases, except when using Claude-4.5-Sonnet.

Qualitative Examples To complement the quantitative analysis, we provide several executed ideas on the GRPO environment in Table 3 and provide example ideas on the nanoGPT environment in Appendix A.2 . When sampling ideas, models would generate a thinking trace, followed by the natural language idea and a brief description of all the code changes needed to implement the idea. For brevity, we only include the natural language ideas in the table, but we present additional examples in Appendix A.3 with more details, including full code execution trajectories. Based on the qualitative examples in Table 3 , different models generate different styles of ideas. For example, Claude-4.5-Sonnet generates more intuitive ideas while Claude-4.5-Opus and GPT-5 are more mathematically inclined.

Recovering Recent Research Papers We observed multiple cases where the model-generated ideas (without any RAG) are highly similar to research papers released within the three months prior to the writing of this paper. For example, Claude-4.5-Sonnet proposed: “ Implement response diversity rewards within groups where responses to the same prompt receive bonus rewards for being dissimilar to other responses in their group, encouraging exploration of different solution paths. ”, which is similar to Li et al. (2025) . For pre-training, Claude-4.5-Opus proposed: “ Causal Context Compression: Before each attention layer, apply a learned compression that mixes local context (previous 2-3 tokens) into the current representation, providing implicit local context without convolutions. ”, which is similar to the “canon layer” described in Allen-Zhu (2025) . Although assessing the novelty of LLM-generated ideas is beyond the scope of this work, models’ ability to rediscover ideas from recent research papers nevertheless indicates that automated AI researchers could plausibly support work at the frontier of LLM research.

## 5 Reinforcement Learning from Execution Reward

Different from evolutionary search, reinforcement learning is an alternative learning algorithm that shapes model behaviors through gradient updates. Despite much recent success on verifiable domains like math and coding ( DeepSeek-AI et al., 2025 ) , RL’s effectiveness on open-ended AI research remains unclear. For the first time, we explore whether we can leverage the automated executor as a reward function to directly finetune LLMs to generate more effective ideas via RL. We detail our implementation, experiment setup, and analysis of the training dynamics.

### 5.1 Reward Design and Experiment Setup

We use Qwen3-30B-A3B ( Yang et al., 2025a ) as the base model and finetune it using the standard GRPO algorithm ( Shao et al., 2024 ) , motivated by its consistent empirical success on other verified domains. Our prompt batch size is one since we only have one prompt for each environment. In the prompt, we provide the baseline codebase and ask the model to generate new ideas to improve the baseline (GRPO or nanoGPT). This experiment setup is similar to prior work exploring RLVR from one training example ( Wang et al., 2025 ) .

We use large group sizes to stabilize training. For the post-training environment, we use a group size of 256; for the pre-training environment, we use a group size of 128. Since each idea on the GRPO environment runs on one single GPU and each idea on the nanoGPT environment runs on 8 GPUs, these group sizes correspond to parallel execution on 256 GPUs (for GRPO) or 1024 GPUs (for nanoGPT) to obtain the execution reward on each batch of rollout ideas. Each rollout is a thinking trace followed by the natural language idea. We set a max output length of 8192 tokens for rollout sampling and only feed the extracted ideas to the automated executor without the preceding thinking trace.

For the post-training environment, we directly use the validation set accuracy of each rollout idea after execution as the reward. For ideas without a valid accuracy (i.e., when the execution failed due to code generation errors), we assign a reward of 0. For the pre-training environment, we use the reciprocal of the validation loss as the reward ( 1 l ​ o ​ s ​ s \frac{1}{loss} ) and assign a reward of 0 to ideas with failed execution. Our experiments are based on the Tinker API ( Thinking Machines Lab, 2025 ) .

### 5.2 Experiment Results

#### Positive Training Curves for Average Reward

We plot the average reward of all rollouts of each training epoch in the upper row of Figure 5 . For the first time, we demonstrate that the average performance of the generated ideas can increase after sufficient training epochs for open-ended research environments. For instance, the average accuracy on the GRPO environment increases from 0.253 at the beginning to 0.343 after 40 training epochs (top left plot of Figure 5 ); and the average reward on the nanoGPT environment increases from 0.194 at the beginning to 0.246 after 68 epochs (top right plot of Figure 5 ), corresponding to a decrease in the average validation loss from 5.150 to 4.066. Such training curves are similar to prior findings on the effectiveness of one-shot RVLR on other verified domains like math ( Wang et al., 2025 ) .

#### The Case of Max Reward

Despite successfully reproducing the positive training curves observed in other domains, we argue that there is a distinction between idea generation and other verifiable domains. For advancing scientific discovery, we often care about the upper-bound of idea generation, rather than the average quality. In our particular case, we care more about having one breakthrough idea that dominates the baselines, rather than having many safe ideas with a high average. Thus, we plot the max reward of all rollouts at each training epoch in the lower row of Figure 5 . The trend here is very different – the max reward is fluctuating throughout RL training without a clear upward trend . This reveals the crucial limitation of the standard GRPO algorithm for improving idea generation. In the next subsection, we analyze why RL from execution reward improves the average reward but not the max.

### 5.3 Analysis of Training Dynamics

#### Thinking Length

We first plot how the lengths of the thinking traces evolve over RL training in the upper row of Figure 6 . In both environments, the thinking traces rapidly decrease in length while the idea lengths stay roughly constant. This is the opposite of the thinking emergence trend from prior RLVR work, such as DeepSeek-R1 ( DeepSeek-AI et al., 2025 ) . To further understand why the thinking length decreases, we investigate the correlation between the idea execution rate and the thinking trace length. In the bottom row of Figure 6 , for the first 20 epochs of the RL training, we sort all ideas in each epoch by their thinking trace lengths and plot the average execution rate of the top-30% longest thinking ideas (red line) and the bottom-30% shortest thinking ideas (blue line). We see a clear trend where ideas with longer thinking consistently have a lower execution rate. We thus hypothesize that longer thinking correlates with more complex ideas with lower execution rates, leading the model to prefer shorter thinking instead in order to maximize the reward.

#### Diversity Collapse

Upon manual investigation of all the rollouts being sampled throughout the RL training, we also observed a diversity collapse. Specifically, the model learned to converge on a few simple ideas that can consistently get a positive reward. For example, in the nanoGPT environment, the model learned to converge towards two common ideas: (1) replacing RMSNorm with LayerNorm; and (2) performing exponential moving average (EMA) over intermediate model checkpoints. As shown in Figure 7 , out of a batch of 128 sampled ideas per epoch, 51 ideas sampled from Qwen3-30B at epoch 0 are one of the two common ideas above. Towards the end of the RL training, 119 out of 128 sampled ideas at epoch 68 are one of the two common ideas, indicating a severe diversity collapse.

The above analyses reveal that RL causes the models to converge on a few simple-to-implement ideas, accompanied by shrinking thinking lengths. These lead to an increase in the average reward, but do not push the upper-bound due to the lack of exploration. This phenomenon is analogous to mode-collapse observations on other verifiable domains, where the pass@k performance stagnates or even decreases after RL ( Yue et al., 2025 ; Wu et al., 2025 ) . Avoiding such convergence and collapse is an open problem and likely requires new algorithmic interventions beyond standard GRPO, which is beyond the scope of this work. However, we do share several preliminary attempts, including: sampling and appending previous epochs’ trajectories into the current epoch’s prompt for rollout sampling, adding a weighted length reward in the total reward, and adding a weighted similarity penalty in the total reward. We did not observe clear gains in the initial epochs and thus early-stopped them, but we document all these results in Appendix A.1 to inform future work.

## 6 Related Work

#### AutoML

Our work has deep connections to the AutoML literature. For example, the Neural Architecture Search (NAS) line of work typically defines a constrained set of neural network operators and optimizes for architectures based on validation set performance through reinforcement learning ( Zoph & Le, 2017 ; Zoph et al., 2017 ) or search ( Liu et al., 2018 ; So et al., 2019 ) . In the modern era, recent works also explored directly using LLMs to propose architecture variants and implement them for validation ( Liu et al., 2025 ; Cheng et al., 2025 ) . Beyond architectures, similar automatic optimizations have been applied to improve hyperparameter tuning ( Zhang et al., 2023 ) , discover machine learning algorithms ( Real et al., 2020 ) , improve post-training objectives ( Lu et al., 2024a ) , discover better neural network optimizers ( Chen et al., 2023 ) , and design agent scaffolds ( Hu et al., 2025 ) . Different from this line of work, we tackle automated AI research in a fully open-ended setting without any constraint on the type of ideas. Moreover, our goal is to improve the effectiveness of idea generation, where natural language ideas represent a higher level of abstraction than specific architecture variants or code optimizations.

#### LLM-based Research Agents

Recent works have been building LLM-based research agents for accelerating scientific discovery in various domains, including AI research. AI-Scientist ( Lu et al., 2024b ; Yamada et al., 2025 ) , AI-Researcher ( Tang et al., 2025 ) , and Agent Laboratory ( Schmidgall et al., 2025 ) are examples of end-to-end research agents that use LLMs to generate ideas and implement them through carefully designed agent scaffolds. They address open-ended AI research as we do, but do not study how to learn from execution feedback and improve idea effectiveness. On the other hand, on more grounded benchmarks with clear performance metrics such as MLE-Bench ( Chan et al., 2025 ) , RE-Bench ( Wijk et al., 2024 ) , and ML-Gym ( Nathani et al., 2025 ) , various works have explored how to learn from execution feedback through either search ( Toledo et al., 2025 ; Jiang et al., 2025 ) or RL ( Yang et al., 2025b ) to optimize performance on these targeted ML engineering tasks. While we also study algorithms for learning from execution feedback, we tackle open-ended research problems like pre-training and post-training rather than ML engineering tasks that heavily depend on feature engineering and hyper-parameter tuning rather than algorithm development.

#### AI for Research

Apart from fully end-to-end automated AI research, many works have studied how to use LLMs for specific components of the scientific research pipeline, such as literature review ( Asai et al., 2024 ; L’ala et al., 2023 ) , idea generation ( Si et al., 2025b ; Wang et al., 2024 ) , data analysis ( Majumder et al., 2025 ; Mitchener et al., 2025 ) , experiment plan generation ( Goel et al., 2025 ) , research code execution ( Starace et al., 2025 ; Hua et al., 2025 ; Tian et al., 2024 ) , and paper reviewing ( Liang et al., 2024 ; Zhu et al., 2025 ) . Our work focuses on automated idea execution and learning from the execution feedback. We consider our work complementary to many of the above works that improve other aspects of the scientific research pipeline.

#### Execution Grounding for Code

The idea of learning from execution feedback has been explored in the code generation domain. For example, Zheng et al. (2024) curate data and train models to refine code from either human or execution feedback; Gehring et al. (2025) use end-to-end RL training to teach models to improve code based on execution feedback; Lavon et al. (2025) directly guide code generation with execution signals during inference time. In contrast, our work explores execution grounding for the application of idea generation, where the verification is more complicated and expensive.

## 7 Conclusion

In this work, we built a large-scale parallel executor for automatically executing model-generated ideas to verify their effectiveness on open-ended LLM research problems, including both LLM pre-training and post-training. Using this executor as a reward function, we analyzed the effectiveness of execution-guided evolutionary search, where frontier LLMs equipped with a simple evolutionary search scaffold can significantly outperform the baseline solutions. We also benchmarked and revealed the limitations of reinforcement learning with execution rewards, where models tend to converge on simple ideas to improve the average reward but lose diversity and do not improve the upper-bound. Our empirical results demonstrate the feasibility and potential of the automated execution feedback loop and also point out the remaining limitations for future improvement. We hope this work paves the foundation and inspires more efforts towards execution-grounded automated AI research.

## 8 Discussion

Despite encouraging initial signals, there are still many limitations to our current set of experiments, which would be great directions for future improvement.

First, our current procedure does not test the generalizability of the generated ideas. It is possible that the best-performing ideas at the small scales may not transfer to gains at a larger scale or on other datasets. Future work should explore methods that explicitly test such generalizability and scalability, and even incorporate them as part of the optimization objectives.

Second, we have shown that RL with execution reward in our current setup can only improve the average reward but not the upper bound. There are many possible reasons, such as a lack of diversity in the base model and missing exploration incentives in the current RL objective. Future work should explore remedies and better learning algorithms for LLMs to more efficiently learn from the execution feedback. For instance, future works could explore how to exploit richer learning signals from the execution trajectories beyond just scalar rewards.

Third, our current experiment scope is bounded by the capability of the execution agent. There exist many promising model-generated ideas that could not be successfully executed by the execution agent (e.g., see the end of Appendix A.2 ), leading to noise in the reward signal. Future work could develop more capable execution agents and extend our setup to even more complex research problems. For instance, instead of directly prompting an LLM for code diff, future work can implement more capable coding agents with access to external tools and the ability to install new libraries in the execution environments.

Last but not least, we only explored effectiveness as the training reward in this work. There are many other, more subjective alternative metrics that could complement the effectiveness reward, such as the idea novelty and interestingness. Future work could explore how to computationally measure them and incorporate them as part of the training objective to discover more insightful ideas.

## Acknowledgment

We thank DST Global, Laude Institute, and Thinking Machines Lab for their generous sponsorship of computing resources. We thank Yuandong Tian, Edward Hughes, Ludwig Schmidt, Cong Lu, Jenny Zhang, Jiaxin Wen, Chris Rytting, Chen Zhao, Xinran Zhao, Yanzhe Zhang, John Yang, Shicheng Liu, Andy Zhou, Will Held, Haotian Ye, Luke Bailey, as well as members of Tatsu Lab and SALT Lab for their helpful discussion and feedback. This work was supported by an HAI grant, DSO labs, gifts from Open Philanthropy, Amazon, Schmidt Sciences, the Tianqiao and Chrissy Chen Foundation and a grant under the NSF CAREER IIS-2338866 and IIS-2247357, ONR N00014-24-1-2609 and N00014-24-1-2532, and DARPA Cooperative Agreement HR00112520013. This work does not necessarily reflect the position or policy of the government and no official endorsement should be inferred.

## Appendix A Appendix

### A.1 Other RL Attempts

We present several attempts to improve our RL from the execution reward recipe.

#### Attempt 1: Dynamic Prompt

At each epoch (except the first epoch), we randomly sample different executed idea trajectories from the previous epoch and append them to the idea sampling prompt when sampling new rollouts. This merges in-context learning with RL and adds diversity to the idea sampling process. We present the experiment results on the GRPO environment in Figure 8 . We did not see significant improvement in early epochs and thus early stopped.

#### Attempt 2: Length Reward

Since we noted a rapid thinking length decrease in our main RL experiment, we tried a simple fix by adding a weighted length reward that counts the number of tokens in the entire rollout sequence, including the thinking trace and the idea. We cap the length reward to a maximum of 0.3 0.3 to avoid it dominating the accuracy reward. We present the experiment results on the GRPO environment in Figure 9 . As shown on the right panel, the thinking length no longer decreases after adding the length reward to the total reward, but the total training reward isn’t going up as shown on the left panel.

#### Attempt 3: Diversity Reward

We also tried adding a diversity reward in addition to the effectiveness reward. Specifically, when computing the reward for each rollout, we compute its token-level Jaccard similarity with ideas from the previous epoch and add the negative similarity as a penalty to the total reward to discourage repeating ideas that have already been generated before. In fact, this is similar to one of the post-training ideas proposed by Claude-4.5-Sonnet (see example 4 in Appendix A.3 ). We show the training curves on the GRPO environment in Figure 10 . The model maintains a consistent idea similarity (right plot), suggesting sustained exploration. The effectiveness reward is generally showing an upward trend (left plot), but not markedly better than the main RL run with just the effectiveness reward (first sub-plot in Figure 5 ).

### A.2 Additional Idea Examples

We provide several additional example ideas generated by Claude-4.5-Opus (Table 4 ) and Claude-4.5-Sonnet (Table 5 ) on the GRPO environment, including ideas with failed code execution. In most cases, code execution errors happen when the idea involves complicated changes or installing and importing external packages not supported in our execution environment. Future work should explore improvement to the execution agent so that more complicated types of ideas (e.g., training additional auxiliary models or system-level optimizations) can be implemented correctly.

We also present the top-performing ideas from Claude-4.5-Opus, Claude-4.5-Sonnet, and GPT-5 on the nanoGPT environment below:

While the best-performing ideas on nanoGPT tend to be heavily optimized with extensive hyper-parameter tuning mixed with various architecture tweaks, we also pick a few more “atomic” algorithmic ideas that are successfully executed.

Examples from Claude-4.5-Opus

• Head-Wise Attention Output Scaling Add learnable per-head scaling factors to attention, allowing different heads to contribute with different magnitudes to the output. Validation Loss: 3.2386

• Learned Residual Connection Weights Add learnable scalar weights for each residual connection that are initialized to 1.0, allowing the model to learn optimal residual scaling during training. Validation Loss: 3.2517

• Mixture of Embeddings with Position Learn to mix token embeddings and position embeddings with a content-dependent weight, allowing the model to dynamically balance positional vs semantic information per token. Validation Loss: 3.2497

• Shared Input-Output Embedding with Learned Asymmetry Keep weight tying but add a small learned transformation on the output side, providing the benefits of weight tying while allowing output-specific adaptation. Validation Loss: 3.2499

• Gated Final Normalization Replace the final RMSNorm before lm_head with a gated version where a learned gate controls how much normalization is applied vs passing the raw representation. Validation Loss: 3.2503

• Position-Aware MLP Gating Gate the MLP output based on position information, allowing the model to learn position-dependent processing depth. Validation Loss: 3.2506

• Learned Residual Connection Weights Add learnable scalar weights for each residual connection that are initialized to 1.0, allowing the model to learn optimal residual scaling during training. Validation Loss: 3.2517

• Grouped Token Embeddings Group the vocabulary into clusters and add a learned embedding per cluster on top of token embeddings, providing hierarchical vocabulary structure. Validation Loss: 3.2521

Lastly, we present several interesting ideas on the nanoGPT environment that didn’t get successfully executed. These examples are generated by Claude-4.5-Opus.

• Soft Layer Repetition Allow the model to softly repeat computation through layers by adding a learned gate that mixes the current layer’s input back into its output, simulating variable depth.

• Causal Context Compression Before each attention layer, apply a learned compression that mixes local context (previous 2-3 tokens) into the current representation, providing implicit local context without convolutions.

• Attention Head Specialization via Orthogonal Loss Add a soft penalty that encourages different attention heads to attend to different patterns by penalizing similarity between head outputs.

• Skip Connections with Learned Residual Weights Combine skip connections with learned residual weights. The skip connections provide alternative gradient paths while learned weights allow adaptive scaling.

• Token Difficulty-Aware Loss Weighting Weight the loss contribution of each token based on the model’s uncertainty (entropy) at that position, focusing learning on difficult tokens while not over-optimizing easy ones.

### A.3 Code Execution Examples

We present a few ideas with their full code execution to demonstrate the full end-to-end trajectories. All examples below are from Claude-4.5-Sonnet on the GRPO environment. For each example, we first present the natural language idea, followed by the code implementation generated by Claude-4.5-Sonnet.

Example 1

[Experiment] Create mathematical working memory simulation by maintaining a context buffer of mathematical facts, definitions, and intermediate results during problem solving. This buffer gets updated as the model works through problems and provides additional context for subsequent mathematical steps, simulating how humans maintain mathematical working memory during complex calculations.

[Code Changes] Modify the prompt template in sample.py to include a “Mathematical Context” section that accumulates relevant mathematical facts during problem solving. Implement context buffer management in train_loop in grpo.py that maintains recent mathematical definitions, formulas, and intermediate calculations across problems in the same batch. Update the buffer with key mathematical expressions extracted from each response. Use enhanced prompts that include relevant context from the buffer. Set --learning_rate 2.5e-5 and --loss_type reinforce_with_baseline .

Validation Accuracy: 58.0

⬇

Example 2

[Experiment] Implement mathematical solution robustness training through systematic perturbation testing that teaches the model to solve mathematically equivalent problems with varied presentations, notation styles, and problem phrasings. Combine this with proven reward shaping by creating robustness-aware rewards that encourage mathematical understanding that generalizes across problem variations.

[Code Changes] Create problem perturbation system in sample.py that generates equivalent mathematical problems with varied notation, different variable names, alternative problem phrasing, and equivalent mathematical formulations. Track solution consistency across perturbations. Enhance r1_zero_reward_fn_train in drgrpo_grader.py to reward robustness: robustness_bonus = 0.12 * consistency_score_across_perturbations where consistency measures solution method stability across equivalent problems. Apply generalization bonuses: +0.08 for solving problems with unfamiliar notation, +0.06 for handling varied problem presentations. Modify train_loop in grpo.py to include perturbation-based training batches and track robustness improvement. Use robustness-aware learning rate with cosine annealing from 3.4e-5 to 1.8e-5 . Implement perturbation-complexity gradient clipping. Set --loss_type reinforce_with_baseline .

Validation Accuracy: 56.2

⬇

Example 3

[Experiment] Implement token-level reward attribution by using attention weights to identify which input tokens contributed most to correct answers, then amplifying the gradient updates for those tokens during policy gradient training.

[Code Changes] Modify get_response_log_probs in utils.py to also return attention weights from the last layer. In grpo_microbatch_train_step , compute token importance scores by averaging attention weights across heads, then multiply the policy gradient loss by (1 + importance_score) for tokens with high attention to mathematical content.

Validation Accuracy: 45.2

⬇

Example 4

[Experiment] Implement response diversity rewards within groups where responses to the same prompt receive bonus rewards (0.05-0.15) for being dissimilar to other responses in their group, encouraging exploration of different solution paths while maintaining the proven group_size=8 and 3e-5 learning rate combination.

[Code Changes] Modify compute_group_normalized_rewards in grpo_utils.py to compute pairwise similarity between responses in each group using token-level Jaccard similarity. Add diversity bonus: diversity_reward = 0.15 * (1 - max_similarity_in_group) to each response’s reward before advantage computation. Reshape responses into groups, compute similarities, and add bonuses before advantage normalization. Set --learning_rate 3e-5 , --loss_type reinforce_with_baseline , --group_size 8 .

Validation Accuracy: 19.2

⬇

## Instructions for reporting errors

We are continuing to improve HTML versions of papers, and your feedback helps enhance accessibility and mobile support. To report errors in the HTML that will help us improve conversion and rendering, choose any of the methods listed below:

Click the "Report Issue" ( ) button, located in the page header.

Tip: You can select the relevant text first, to include it in your report.

Our team has already identified the following issues . We appreciate your time reviewing and reporting rendering errors we may not have found yet. Your efforts will help us improve the HTML versions for all readers, because disability should not be a barrier to accessing research. Thank you for your continued support in championing open access for all.

Have a free development cycle? Help support accessibility at arXiv! Our collaborators at LaTeXML maintain a list of packages that need conversion , and welcome developer contributions .