Agnostics: Learning to Synthesize Code in Any Programming Language with a Universal Reinforcement Learning Environment
Authors: Aleksander Boruch-Gruszecki
Yangtian Zi
Zixuan Wu
Tejas Oberoi
Carolyn Jane Anderson
Joydeep Biswas
Arjun Guha
Venue: ICLR 2026 Poster (2026)
Keywords: large language models
program synthesis
code generation
reinforcement learning
low-resource programming languages
Primary area: neurosymbolic & hybrid AI systems (physics-informed, logic & formal reasoning, etc.)
TL;DR: We show a universal reinforcement learning environment for any programming language and use it to train SOTA small LLMs for 5 low-resource programming languages.

Abstract: Large language models (LLMs) already excel at writing code in high-resource languages such as Python and JavaScript, yet stumble on low-resource languages that remain essential to science and engineering. Besides the obvious shortage of pre-training data, post-training itself is a bottleneck: every new language seems to require new datasets, test harnesses, and reinforcement learning (RL) infrastructure.

We introduce Agnostics, a language-agnostic post-training pipeline that eliminates this per-language engineering. The key idea is to judge code solely by its externally observable behavior, so a single verifier can test solutions written in any language. Concretely, we (i) use an LLM to rewrite existing unit-test datasets into an I/O format, (ii) supply a short configuration that tells the verifier how to compile and run a target language, and (iii) apply reinforcement learning with verifiable rewards (RLVR) in a robust code execution environment.

Applied to five low-resource languages—Lua, Julia, R, OCaml, and Fortran—Agnostics (1) improves Qwen-3 4B to performance that rivals other 16B–70B open-weight models; (2) scales cleanly to larger and diverse model families (Qwen-3 8B, DeepSeek Coder 6.7B Instruct, SmolLM3, Phi 4 Mini); and (3) for open-weight models with ≤16B parameters, sets new state-of-the-art pass@1 results on MultiPL-E and a new multi-language version of LiveCodeBench that we introduce.

We release the language-agnostic training datasets (Ag-MBPP-X, Ag-Codeforces-X, Ag-LiveCodeBench-X), training code, and ready-to-use configurations, making RL post-training in any programming language as simple as editing a short YAML file.

Published as a conference paper at ICLR 2026
AGNOSTICS: LEARNING TO SYNTHESIZE CODE IN ANY PROGRAMMING LANGUAGE WITH A UNIVERSAL REINFORCEMENT LEARNING ENVIRONMENT
Aleksander goruch-Gruszecki; Yangtian Zi Zixuan Wu, Tejas Oberoi,
Carolyn Jane Anderson, Joydeep Biswas, Arjun Guha'
Northeastern University, Universitty of Texas, 'Wellesley College
"research @ abgru.me
ABSTRACT
Large language models (LLMs) excel at writing code in high-resource languages such as Python and JavaScript, yet stumble on low-resource languages that remain essential to science and engineering. Besides the obvious shortage pre- pre-training data, post-training itself is a bottleneck: every new language seems require new datasets, test harnesses, and reinforeement-learing (RL. infrastructure.
We introduce Agnostics, Language-agnosee post-training pipeline that elimi- nates this per-language engineering. The key idea is to judge code solely by its externally observable behavior, so a single verifier can test solutions written any language. Concretely, we (i) use an LLM to rewrite existing unit-test datasets into an I/O format, (ii) supply a short configuration that tells the verifier how to compile and run target language, and (iii) apply reinforcement learning with verifiable rewards (RLVR) in a robust code execution environment.
Applied five low-resource languages- Lua, Julia, R, OCaml, and For- tran-Agnostics (1) improves Qwen-3 4B to performance rivaling other 16B-70B open-weight models; (2) scales to larger and diverse model families (Qwen-3 8B, DeepSeek Coder 6.7B Instruct, SmolLM 3, Phi 4 Mini); and (3) for <16B pa- rameter models, sets new state-of-the art pass @ results on MultiPL-E and a new multi-language version of LiveCodeBench which we introduce.
We release the language-agnostin training datasets (Ag-MBPP-X, Ag- Codeforces- X. (--LiveCodeBBnch-X)) training code, and ready-to-use configurations, mak- ing RL training for any programming language as easy as a few lines of YAML.
INTRODUCTION
Large language models (LLMs) are remarkably good programming tasks, especially when coding in high-resource programming languages such as Python and JavaScript. Their proficiency in low- resource programming languages, such as Fortran, Julia, and others, is far more limited. This gap appears both on benchmarks (Cassano et al., 2023) and in popular discourse. Many low-resource languages are adapted to and widely used in particular sectors such as computational science (e.g., Julia, Fortran), medicine (e.g.. Mumps), data science (e.g., R), and others. Methods for improving LLMs on such languages would help programmers in these sectors truly take advantage of LLMs.
The capability gap between high high-resouree and low-resource programming languages occurs for two reasons. First, there is vastly more training data for some languages. For example, The Stack V2 (Lozhkov et al., 2024a), the largest public training corpus of code, has 2200GB of Python but only =2GB Julia and Fortran. Thus pretraining on code makes models significantly better at Python. A subtler reason is the availability of post-training datasets and techniques. Contemporary LLMs are developed with an extensive post-training process that relies on (a) high-quality curated data for supervised fine-tuning, and (b) carefully designed environments for reinforcement leamn ing, which must be able to execute and verify modee--genraal solutions. Both of these require significant human expertise, which is hard to find for low-resource programming languages.

---

Published as a conference paper at ICLR 2026
Our goal in this work is to facilitate post-training LLMs on low-resource programming languages, working towards closing the resource gap. Our key idea is that for large class programming tasks, correctness can be stated property not of functions or code snippets, but of the entire pro- gram's observable behavior (e.g.. 1/O). Furthermore, if its correctness can be tested with a verifier program, such verifier with appropriate problems and test cases can be used to make universal inforcement learning environment which can be instantiated for nearly any programming language. In fact, the verifier's implementation language is independent from the one being learned. This ap- proach matches the formulation of some existing post-training datasets (even if they are intended for Python/C++), and we can reformulate language-spece
datasets into this format with LLMs.
Our approach, Agnostics, works based on this insight as follows (Figure 1). 1) We use an LLM to reformulate language-specific datasets into our uniform language-agnostic format. 2) target particular language, we generate prompts and instantiate the verifier based on small (4-5 line) configuration file. 3) We apply reinforcement learning with verified rewards (RLVR) using a robust, language-agnostic execution sandbox that we develop. 4) The result is model specialized to the target language. Agnostics particularly excels at finetuning models for low-resource languages, as does not rely high-quality datasets specific to particular language.
Contributions
1. Agnostics, a post-training pipeline for coding in arbitrary programming languages;
The best-performing open- open-weights <16B models for Lua, R, Julia, OCaml and Fortran;
Three Agnostics datasets: Ag- 0g-MMPP-X, Ag- Codeforces-.... and Ag Le-LiveCodBBechh-- XX, based on MBPP (Austin et al., 2021), Open-RI Codeforces (Penedo et al., 2025) and LiveCodeBench (Jain et al., 2024b) respectively.
small and carefully designed Agnostics training framework, including a parallel code execution sandbox, sampling, rewards computation, GRPO, and model back propagation.
Our leaderboard, data, code, and artifacts are referenced at aggnottic..abru.me and in $5.
Trained models
Agnostics dalaset
Targeted dalasets
3
Reinforcement (with our trainer)
Write program...
Write program... Lua.
generate
verity
Here is your... code.
Agnostics converter
y
Write a program... in
TO
Here is your Lua code.
Write a Python function...
Write a program... ...in Julia.
updale
reward
julia
Figure 1: Overview: Agnostics Data Preparation and Training, (1) We reformulate existing cod- ing datasets our format. (2) We adapt the language-agnosti datasets particular programming language. (3, 4) We reinforce coding via Group Relative Policy Optimization (Shao et al., 2024; DeepSeek-Al et al., 2025), verifying the programs in code execution sandbox.
2 BACKGROUND AND RELATED WORK
Data Scarcity for Low-Resource Languages General-purpose LLMs have been pretrained on code for several years, both because LLMs are widely used for practical programming tasks, and because pretraining on code improves their gen- eral reasoning abilities (Ma et al., 2023). Code- specialized models may be trained from general- purpose model checkpoint or exclusively on code (e.g., Xu et al. (2022); Allal al. (2023)).
Language
Language
%
JavaScript
17.04 %
Lua
0.53 %
Java
8.38 %
R
0.35 %
C++
5.41 %
Fortran Julia
0.07 %
Python
3.56 %
0.10 %
Figure 2: High-resource (left) and low-
resource (right) languages in the Stack v2.
2

---

Published as a conference paper at ICLR 2026
However, the publicly available pretraining data for code is heavily skewed toward handful of programming languages. E.g., consider The Stack V2 (Lozhkov et al., 2024b), the largest public code pretraining dataset, with code from GitHub and dozens of other sources. The Stack V2 is dominated by relatively few programming languages: just 10 of 619 languages account for over 90% of the dataset. We want develop models for low-resource programming languages that each account for 50.5% of publicly available code (Figure 2). We can imagine working around this data scarcity in a few ways. However, previous work shows that up-sampling low-resource languages during pretraining only leads to small benchmark improvements (Orlanski et al., 2023), while fine- tuning on the pre-training data for low-resource languages has negligible impact (Cassano et al., 2024). Thus, it is not clear how to make further gains from existing natural data.
Synthetic Data for Low-Resource Languages If natural data is not available for a task, it is possible to use LLMs to generate synthetic fine-tuning data (Wang et al., 2023), and there many techniques for building code-centric supervised fine-tuning datasets (e.g. Luo et al. (2023); Wei et al. (2024c;b) that work remarkably for Python. Although these approaches could in principle be applied to any programming language, Cassano et al. (2024) show that without distillation or verification (e.g., see Hu et al. (2025); Wei et al. (2024a)), synthetic tasks and code for low-resource programming languages are low-quality, and models fine-tuned on them perform poorly.
MultiPL-T (Cassano et al., 2024), similar to TransCoder-Si ST (Roziere et al., 2021) and CMTrans (Xie et al.. 2024), couples synthetic data generation with verification using rejection sampling: it gen- erates up n candidate programs a target, low-resource language and only fine-tune models on generations that pass hidden unit tests that it translates from Python. However, the MultiPL-T ap- proach has two significant limitations. (1) For the verifier to not reject all samples, the model must be able to generate a working program within attempts. In MultiPL-T, <30% of prompts produce a working program for n E (50, 100} attempts, and the rest are discarded. We train on much harder problems, and estimate that rejection sampling would require order of magnitude more resources for a comparable acceptance rate (54.3). (2) For each low lowrresource language of interest, MultiPL-T requires writing little compiler to translate test cases and function signatures from Python to the target language. MultiPI-TT only supports a limited set of built-in Python types (e.g.. no classes) and dictates that all Python types and values must faithfully map to the target language. However, depending on the problem and language, the natural data representation may not map cleanly to Python. This can lead peculiar, unidiomatic translations that require deep language expertise to get right. The Agnosties approach is far easier to use than MultiPL-T, and only requires the user to know how to compile and run a program in the target language from the shell.
Reinforcement Learning on Coding Tasks DeepSeek R1 (DeepSeek-AAeet et al., 2025) popularized RL on LLMs with rule-based rewards, instead of learned reward models. RI reports applying RL to coding tasks without further dataset details. A number of papers apply RL to the NL to code task (Zeng et al., 2025; Gehring et al., 2024; Jain et al., 2025). These techniques target Python and show that RL can improve LLM capabilities beyond what supervised fine-tuning allows alone.
However, the key benefit of RL is that it can train a model to do tasks for which high-quality su- pervised fine-tuning data is unavailable. There are recent examples of using RL for code optimiza- tion (Du et al., 2025; Nichols et al., 2024), resolve GitHub, issue resolution (Wei et al., 2025), and iterative development (Zhou et al., 2025). These papers target tasks in high- languages (C++, Java, and Python) whereas Agnostics targets several low-resource languages.
3 THE AGNOSTICS APPROACH
Our approach comprises (1) a data preparation stage which reformulates Language-specife pro- gramming tasks to be iaguage--ggnstic and retargets language-agnoste datasets to programming language of interest (1, 2 in Figure I); and (2) the training stage which uses the GRPO algorithm and an efficient, language-agnostic verification framework (3, 4 in Figure 1). Our tasks ask for programs by deseribing their behavior. The test cases are samples of this behavior, and a verifier program can check if solution behaves according to the sample. In this paper, limited ourselves working with tasks asking for programs which read data from the standard imput, compute a unique answer, and write it to the standard output. Hence, the datasets we prepared share one verifier.
3

---

Published as a conference paper at ICLR 2026
Write a python function to identify nen-prime numbers, def pennot_priimmn) (
Instruction: Given integer V (N 2 2), deter- mine if it is a non non-prime number. Output 'Truc' if the number is non-poe non-prime, 'False' otherwise. In- put format: a single integer N (N 2 2). Output format: single line containing 'True' or 'False'.
assert is.not.prime (2) == False
Input
Output
False
assert is_not_prime (10) True
True
(a) An MBPP task prompt and associated tests gray). (b) The task and tests reformulated Agnostics.
Figure 3: For dataset preparation, we an LLM to reformulate fine-tuning datasets with language- specific prompts and tests (above) into equivalent language-agnostic programming tasks.
3.1 DATASET PREPARATION
Some datasets, like Open-R1 Codeforces (Penedo et al., 2025), already define tasks in the desired 1/O style. More commonly, however, code datasets provide a set of unit tests. Figure shows a representative item from MBPP: it has natural language problem description and Python function signature that comprise the prompt, and suite of tests used to test model-generated code. These datasets be easily translated into the I/O format.
To make such problems lanuuage-agnoste and compatible with our verifier, we prompt an LLM to reformulate each task that the program communicates exclusively via plain-text standard in and standard out. We ask the model to spell out concrete I/O conventions-numaa newline versus comma separators, ordering of values, and unambiguous. Figure 3b shows the reformulated example. $A presents the prompt we use to reformulate MBPP; other datasets might require small changes the prompt.
of decimal places, that the expected behavior
3.2 PROGRAMMING LANGUAGE PREPARATION
To prepare new language, author small configuration file with two purposes. First, defines a prompt prefix (prepended to each problem by the trainer) which instructs the model to produce code in the target language. Second, the configuration file specifies the shell commands to install the language toolchain and run code. In our experience, a prompt prefix simply asking for solution in language L enough for more widespread languages with 25% base accuracy. However, when starting from near-zero accuracy, a longer prefix can help prevent common mistakes. E.g., our R language configuration (Figure features longer prompt explaining the quirks of I/O APIs in R!
If a model barely knows a programming language, a good prefix can help it. Still, writing the prefix takes manual effort. For OCaml and Fortran, we let base model generate several faulty snippets, and asked a capable LLM (OpenAl o3) for advice based on the snippets with the following prompt.
What follows are several Fortran programs. You'll see that most of them are wrong. Read them carefully and identify the Fortran programming mistakes that I'm making, Ignore algorithmic mistakes, and focus on my misconceptions about Fortran. Come up with advice on how should program Fortran correctly. Distill this advice into 10-20 sentences.
We use the resulting instructions verbatim (see {B) when training models. The prefix only needed to slightly raise the model's train split performance; base accuracy as low as 0.09% was enough for the model to start learning (see $4.3). Configuring the two languages took hour each.
3.3 TRAINER AND CODE EXECUTION
The Agnostics trainer uses the Group-Relative Policy Optimization (GRPO) reinforcement learn- ing algorithm (Shao et al., 2024), with verifiable rewards (DeepSeek-Al et al., 2025), and further
'There are 3 ways R, 3 I/O APIs, and only one portable way read from standard in.
4

---

Published as a conference paper at ICLR 2026
install: apt-get install -y z-cran-tidyverse
filename: snippet.R.
execute: Rscript snippet.R
prompt:
Use R version 4, Use 'readLines (cen file("stdi"")) read from stdin. Use the 'n' argument to read the first 'n' lines. example: "'r
input <- readLines (con = file ("stdin"), n= =)
<- as.integer (input)
cat (n) & print the first 1ine of input ..
Also, please remember to use "cat" to print output.
Figure 4: An Agnostics configuration snippet for (slightly rephrased for presentation).
common tweaks to improve its efficiency (Yu et al., 2025). We couple the algorithm with language- agnostic code execution framework designed to be robust and efficient.
Trainer The trainer instantiates the GRPO algorithm as follows. Let (x, {(ing, outx) ] ~ D be a dataset language-agnostics tasks, where æ is the task prompt and {(ing, outx) k= is the set of I/O examples. Let P be L.prompt from language configuration L (e.g.. Figure 4). From the behavior policy Th we sample a group G candidate responses {y:)- ~ To.. (. P.x). We assign each candidate reward R,, with R; if the execution environment (described later) verifies that the extracted program behaves as in the I/O examples (ing, outx) and Rg = otherwise.
We turn group rewards into sequence-level advantages Å,, and update the policy with the objective
LGRPO (0) [(....)DD. (M.)) P,z))
lud
Uk Σ
min (clip(r.,c()); e, (2))
To To(ii P. Vi,et) Tew (21, P. Wi,c1)
A R4 mean (R (=))
where
(0) =
std({R,) G
We omit the KL-divergence term, similar to Yu et al. (2025). We also considered and decided against reward for partially- correet answer (see SC.3). We tried to reward the model for code which runs without errors but produces wrong output or for code which only passes the public tests (if there are any). In both cases the models were very likely learn how exploit the reward, e.g., by producing empty programs or by hard-coding the public tests (and claiming to produce a "draft answer").
Code Execution Our verifier, a language-agnostic code execution sandbox, (1) extracts a program from each candidate; (2) compiles it if needed; and (3) tests it on the I/O examples {(in, outx) ) K k=
To extract the code, we instruct the model to put it in a Markdown block, which all major instruction- tuned models do by default. Since we rely on the native format of the model, we do not need train the model with a format reward. This guarantees that the increases in rewards we see during training real improvements and merely the result of the model learning format correctly.
For each language, we build and cache an OCI (2025) container using the configuration L. To build the container, we install the language compiler and runtime (the script L.install), and include a generic execution harness which runs and tests candidate programs. The execution harness runs continuously in the container, waiting for triples with the candidate program, the set of input/output examples, and timeouts. The harness (1) writes the program to disk (to L. lefemme)), (2) compiles needed (..comple) (3) runs it on each received input (L.execute), and verified that produces the expected output. The harness imposes timeouts the compilation step and each execution, and returns reward on any timeout or failed verification. is important to have timeouts for both compilation and execution. This prevents pathologies such unbounded macro expansion in Julia (caught by the compile timeout) and infinite loops (caught by the execution timeout). Using containers also allows limit CPU, memory, and filesystem usage; elevated privileges
5

---

Published as a conference paper at ICLR 2026
granted to the generated program. Although the current datasets only specify tasks by standard I/O, the same sandbox can safely accommodate problems that read/write from network or disk.
A subtle resource limit that impose is limit the size of output. Even with short timeout such as 30 seconds, a pathological candidate program can output tens gigabytes of text. This erash the verifier if it naively tries to read and store all output. Instead, the verifier maintains fixed-size (5MB) read buffer and immediately kills programs which overflow it.
Overall, this design lets keep a pool of warm containers for the duration of training: find that spawning fresh container is two orders of magnitude slower than re-using an existing one. In experiments, single training run may involve testing 150,000 programs, each several I/O examples. Most of the generated programs are faulty and some behave badly, c.g. they either timeout, consume too much memory, or produce too much output. So containers do occasionally crash need to be killed, and our execution environment handles this automatically.
Finally, to improve compile times, our execution environment mounts a RAM disk in each con- tainer. Compilation may be slow due to creating many intermediate files, and indeed some large C++ projects, e.g., Firefox, recommend using a RAM disk to speed up their builds (Firefox, 2025).
Implementation We implement the trainer and execution environment with Ray (Moritz et al., 2018), which facilitates multiprocessing and distributed computing. In particular, Ray lets us dis- tribute the training over network of heterogeneous nodes, which allows running the trainer node specialized for GPU work and the execution environment on a node specialized for CPU work. Ray also lets us easily separate group generation and loss computation into inter-communicatin processes. Running the two in parallel significantly speeds up training, as we found that they take roughly comparable amount of time. The execution environment is also actor and manages containers with Python asynci o coroutines, not actors, to minimize inter-process data copying.
HYPERPARAMETER
We use the Adam W optimizer (Loshchilov & Hutter, 2019) with learning rate of 5 x 10-6 and cosine decay schedule with warmup of 0.1 epochs. We process 4 prompts in each batch, with group size 32 per prompt. When training we use temperature 0.7 and disable reasoning in hybrid models. (Many generations still show reasoning-like text, either before the answer or in comments.) We describe how we chose the hyperparameter values and how we evaluted different values SC.1.
EVALUATION
To evaluate Agnostics, we train and benchmark models on 5 low-resource programming languages. We measure pass @ accuracy with reasoning disabled, 20 samples per prompt at temperature 0.2. We trained the models for epoch, unless specified otherwise.
4.1 TRAINING DATASETS
Ag- P--Codfforces-x X, the main dataset we use for training, was created based on competitive program- ming problems from the Open-R1 Codeforces dataset (Penedo et al., 2025). Few adjustments were necessary, since the problems already specified programs and tests using standard I/O. The train split contains 5369 problems.
Ag-MBPP-X, the other training dataset we was created from MBPP explained in $3.1.
Both datasets were analyzed to ensure no contamination with benchmarks we use. See $A for more detailed description of how the datasets were prepared.
4.2 BENCUMARKS
We evaluate Agnostics with the following benchmarks.
MultiPL-E (Cassano et al., 2023) is well-established benchmark, frequently used to evaluate the performance of new LLMs on a broad set languages (c.g.. Kimi Team (2025); Yang et al. (2025); Grattafiori al. (2024); ByteDance al. (2025)). MultiPL-EE prepared by compiling

---

Published as a conference paper at ICLR 2026
HumanEval (Chen et al., 2021) prompts and unit tests from Python to each target language. Each MultiPL-E programming language requires a ==500 LOC prompt and test translator, considerably more effort than writing an Agnostics configuration file. A major limitation of MultiPL-E is being too easy for frontier models. With Python, frontier models are now evaluated on solving program- ming contest problems (Jain et al., 2024b); no multi-language benchmarks are as challenging.
Ag-LiveCoodeeenh-X,, a contribution of this paper, new multi-language benchmark derived from LiveCodeBench. (The benchmark has no overlap with our training data; see $A.) Live- CodeBench 5.0 has 880 problems; 381 problems have Python starter code and test cases, while the remaining 499 problems instead use standard I/O to specify and test solutions. We used the latter problems to transform LiveCodeBench into an Agnostics dataset. Accordingly, benchmark- ing a new programming language with Ag-LiveCodeReecc--X X straightforward: we can reuse our trainer's language configurations and execution environment ($3.3). Our results and leaderboard (see 11) show that Ag-LiveCodeBBnchh is far harder than MultiPI.-E. and challenging for fron- tier models as of February 2026.
4.3 RESULTS
We now present our results. We use a few abbreviations in the tables. Ag-LCB-X stands for Ag-LiveCCodeBench-X. we clarify abbreviated model names in the text. Highlighted rows present models; note that each cell in such row presents the score of a different model trained on programming lan- guage X. We compute the score explained in $4.
Model
Ag-I.C--X
Lua
Julia
R
Llama 3.3 70B Ins
25
22
13
Qwen 3 32B
22
DSC v2 Lite Ins 16B
13
12
9
Qwen 3 4B
11
10
10
Qwen 3 8B
11
9
9
SOTA small LLMs for low-resource PLs Using Agnos- ties, we train Qwen 3 4B and 8B on Ag-Codeforces-- spe-
Dwen3-4B-MBPPT
15
9
Dwen3-4B-CF-X
23
22
cialized to Fortran, Julia, R, Lua, and OCaml. The result- ing models are sate-offthe-aa at coding in low-resource pro- gramming languages among open-went weight models with $16B parameters.
Qwen3-8B-CF-X
25
25
19
Table 1: Ag-LCB-X pass@
Agnostics training yields significant improvements on Ag- LiveCodeBench-X (tables 1 and 2). (i) On every language, our models match or outperform DeepSeek Coder v2 Lite Instruct (16B), and their performance comes close or ex- ceeds that of Qwen 3 32B and Llama 3.2 70B. (ii) The OCaml and Fortran scores improve from near zero to =7% and =15%, outperforming even some frontier models. Im- portantly, these scores show what the models learned from training: during evaluation we omit the prompt prefix used to facilitate learning ($3.1). )). (iii) Finally, the pass scores improve by factor of 1.5-2x over the base model. This indicates that Agnostics can improve models beyond usual training on all the publicly available code data, as we can safely assume that the Qwen models were trained all such data, like the Llama models (Grattafiori
Model
Ag-LCB-X
X=
OCaml Fortran
Sonnet 4
6
6
Llama 3.3 70B Ins
7
Qwen 3 32B
2
DSC v2 Lite Ins 16B
7
6
Qwen 3 4B
1
0
Qwen 3 8B
0
0
Qwen3-4B-CF-X
7
Qwen3-8B-Cr-X
7
17
Table 2: Ag-I.C--X pass@1
et al., 2024).
Models trained with our approach generalize over the compet- itive programming format: the improvements are not limited to synthesizing programs using standard I/O. To demonstrate this, we evaluate them the established MultiPL-E bench- mark. It features problems which ask for Python functions operating usual Python data structures, and we find that training also significantly improves the models on such prob- lems (Table 3). We also confirmed that our training does not lower performance on other programming languages ($C.4).
Model
MultiP-EE Julia
X=
Lua
R
Qwen 3 4B
61
51
36
Qwen
53
44
Dwen3-4B-MBPP
51
62
41
Qwen3-4B-CH 4B-CF-X
64
54
43
Qwen3-8B-CEB
61
52
Table 3: MultiP--E pass
Note that MultiPI-EE does support OCaml and Fortran.

---

Published as a conference paper at ICLR 2026
Figure shows the GRPO batch pass@1 I rates seen when training Qwen3-4B-CE. All the models follow similar curves, partially due to being trained on the same data permutation. Nearly all the models slowly keep improving almost until the dataset end. We also observed the train and test split rewards to be correlated with each other ($C.2).
Agnostics scales to larger models To test if the gains from Agnostics training scale with model size, we train the Qwen 8B model on Ag- ge-Codeforcees-X specialized to Lua, Julia and R and benchmarked it on Ag-LiveCodeBenchr X and MultiPL-E (tables and 3). The Qwen3- 8B-CF-X models show significant gains both benchmarks, improving over their 4B counterparts. We expect Agnostics to scale to even larger models, with appropriate comput- ing resources. However, found that Agnos- ties training on Ag-Codeforces-X does not im- prove two smaller models, Qwen 3 1.7B and Llama 3.2 3B Instruct, perhaps due to the prob- lems being too difficult for models of this size.
0.25
group batch pass@1
0.20
0.15
0.10
Lua
Julia
0.05
OCaml
Fortran
0.00
1000
1250
Training step
Figure 5: Group batch pass 1, Qwen3-4B-CF-X.
Agnostics works with easier problems All of the models we discussed so far were trained on Ag-Coot Ag-Codeforces-X. To show that Agnostics works with other datasets, we also train models for Julia, Lua, and R using MBPP training set. ($3.1 describes how we prepare MBPP.) MBPP problems are trivial compared to the Open-RI Codeforces problems (see Figure 3a), and cannot expect models trained on the MBPP problems to be as good as ones we presented before. Still, training on MBPP improves Lua and Julia performance (tables and 3). The table shows small drop in R performance on Ag-LivveCoeeBench- but a significant improvement on MultiPI.FE.
Agnostics works on multiple model families To show that Agnostics works on non-Qwen models, we train SmolLM 3 (S3olLM3 Team, 2025), Phi Mini Instruct (Microsoft, 2025), and DeepSeek Coder 6.7B Instruct (Guo et al., 2024) on Ag- Codeforces-X X specialized Lua, Julia, and R. Ag- nostics improves these models' performance all languages, as measured by MultiPL-E and Ag- LiveCodeBench-X (Table 4).
Model
MultiL--E
Ag-LCB-X
Lua Julia
Lua Julia
R
SmolLM3
11
12
18
2
Phi mini ins
40
39
34
8
5
DSC 6.7B Ins
40
54
37
5
8
SmoLLM3-3B-CF-XX
14
Phi4-mini-ins CF
41
43
35
12
8
12
DSC-6.7B-Ins CF-
42
55
52
9 10
Note that DeepSeek Coder 6.7B relatively old LLM, superseded by the much larger DeepSeek and V3 models. Unlike Qwen 3, DeepSeek Coder is not trained with reinforcement learning, but only instruction-tunn model. Thus this result also shows that Agnostics work models that have had relatively limited post-training.
Table 4: Non-Qwen models, pass @
Agnostics outperforms distillation So far we dis- cussed training a model its generations. An al-
Model
Ag-I.CB-Fortran
ternative is to distill a larger model (assuming one exists). As larger models do not perform very well on many low-resource programming languages, one can expect distillation be less effective.
Sonnet 4 Thinking (teacher) Qwen 4B (student)
12
0
epoch
3
epochs epochs
3
2
We run the following experiment to verify this claim. Using Sonnet 4 Thinking, we synthesize Fortran solutions to Ag-Codeforces-X problems, creating training set 1,987 items. (For 13 items, Sonnet 4 (sonnet-4-200 4-225505-002551144 with extended thinking does not produce response within its reasoning budget.) To make generating the training items does not use significantly more compute compared to Agnostics training, we use at most 32K reasoning tokens, spending $96 to generate the items. We fine-tune Qwen 3 4B for 3 epochs (batch
Table 5: Distillation experiment results.
8

---

Published as a conference paper at ICLR 2026
size 64, learning rate 2 x 10-5, cosine learning rate decay with warmup ratio 0.1). Table 5 shows the resulting models reach scores far lower than the 15% Beve3--B-CFF-Fore (Table 2).
Agnostics outperforms rejection sampling We also ran small experiment to confirm that rejec- tion sampling would be prohibitively expensive in our case. In rejection sampling with supervised fine-tuning, , we prompt the model to synthesize solutions to each task, reject solutions that fail tests, and fine-tune on the task-solution pairs that pass tests. Cassano et al. (2024) use this approach to get solutions for =30% of the tasks in their dataset.
The efficiency of this approach depends on the hardness of the task and the capabilities of the model. In this paper, we use newer models that are marginally better at low-resource languages (based on MultiPL.-E benchmark results). The task of Cassano et al. (2024) is to translate a simple, self- contained Python function from the model's pretraining data into an equivalent function in another programming language. This task is significantly easier than the Ag- Lag-Codfforce-> - task, which is to solve competitive programming problem in a low-resource language without any reference code.
Rejection sampling would be prohibitively expensive for the low-resource programming languages consider. Cassano al. (2024) report 30% success rate their code translation task. During Agnostics training, Qwen3-4B-CF-Forree 6.64% of the time, generating 11400 verified programs overall. We also sampled responses to the same problems from the base model of Qwen3-4B- CF--C--rrrrr.. Qwen 3 4B, taking the same amount of samples with the same generation parameters as used during training. The base model succeeded 0.09% of the time, generating only 158 test-passing programs.
generated a correct answer to a train split problem only
4.4 QUALITATIVE IMPROVEMENTS
We now take deeper look at how training with Agnostics qualitatively improves Qwen 4B. First, define taxonomy of common bugs; we prompt o3 to classify bugs in sample of faulty programs and lightly edit the suggestion. SD has the full taxonomy and the prompt used develop it. The taxonomy spans fundamental programming errors such as syntax errors, and subtler mistakes such as logic flaws.
Syntax and Proggrpphiall
Dutput Forratting and Presontatin
Input Reading and Parsing
7a
6
4p%
$390
We sample 100 problems from Ag- LiveCodeBench-X, and for each take five OCaml programs produced by Qwen 3 4B and the models trained on Ag-Codeforces-X. Recall from Table that our models signif- icantly outperform the base Qwen models on our benchmark. With Sonnet 4, we the taxonomy to classify the bugs in each program.
Algerithmic
Variables
Function Misuse and Missing
Data Type and Conversion Emrors
Owenn 3-0
Figure 6 shows the bug distribution for OCaml. We see that the base Qwen 4B model makes many more fundamental OCaml programming mistakes. More programs have syntax errors (55% vs 35% after training), more programs misuse builtin functions (60% vs 32%), and so on. We do observe a small increase in logic flaws (18% vs 25% after training). When pro- gram is full of syntax errors and hallucinated functions, it is hard to decide if the algorithmic approach is correct; training eliminates these shallow bugs and lets deeper issues manifest. Models trained for the other four programming languages show the same patterns ($D).
Figure 6: LLM labels of bugs in programs syn- thesized by Qwen 4B and our trained model, Owen3-4B-CC-OCCam. A radial represents a bug class, and points along the radial show how many programs seem to have that bug. Qwen 3 4B makes more fundamental programming mistakes, such syntax errors and misusing builtins, show- ing its limited grasp of OCaml. Our trained model makes far fewer such mistakes. We increase in logic flaws: the trained model makes fewer shallow mistakes, revealing deeper issues.
small
9

---

Published as a conference paper at ICLR 2026
5 CONCLUSION
Arguably, practicioners need LLMs the most for low-resource programming languages, which need highly specialized knowledge. Unfortunately. this is precisely where LLMs are weak due to lack of sufficient pre-training and post-training data. We propose Agnostics, sanguage-agnosiin post- training pipeline that minimizes the per-language engineering tax by verifying code entirely via externally observable behavior. A short configuration file is enough adapt the pipeline, including the reinforcement learning setup, to a new programming language.
Empirically, Agnostics consistently improves small open-weight models on five low-resource languages-Lua, Julia, R, OCaml, and wirtran-without requiring language-specific test translators. Training Qwen 3 4B with Ag-Codeforces-X yields large gains on our new Lag-LiveCodeBench-- benchmark and on MultiPL-E, often rivaling surpassing 16B-70 open-weight baselines. The method scales to larger and different model families: Qwen 3 8B shows similar gains to its smaller sibling, and we also observe improvements on DeepSeek Coder 6.7B, Phi 4 Mini and SmolLM3 3B. Error-type analysis shows our training decreases fundamental programming language mistakes.
A practical advantage of the approach is how little per-language work it requires. After the frame- work was in place, extending the pipeline to support OCaml and Fortran took us less than an hour each. We expect adaption to be just straightforward for any pragmatic programming language with a command line toolchain.
We believe the approach scales models of arbitrary size, although our experiments limited by available compute to at most 8B models. For scaling data, the Agnostics reformulation approach also applies much larger problem sets. For instance, OpenCodeReasooing has ~600K problems with Python solutions (Ahmad et al., 2025); converting such corpora into language-agnostic I/O tasks would provide rich RL datasets with many target languages with minimal additional engineering.
REPRODUCIBILITY STATEMENT
We provide references data, code, and artifacts agnostics.abgru.ma We share our Wandb training logs at and our training framework hww.:///oooouu//goosssssrraaaaaa
datasets and models at bandb.ai/nuprl/Agnoos
The existing datasets we used are publicly available and are accompanied by citations. We publicly release all datasets we introduce, allowing free for research. In the same way, we release all code required for conducting and analyzing our experiments, including the code for dataset preparation, as well as the models we presented and Wandb records from training them. We state the number and range of values tried per (hyper) parameter, and outline how we chose the final values and what they are ($$ 3.3 and C.1). I). We specify the computing infrastructure (hardware and software) we used for our experiments ($C.5). The released codebases specify the exact versions of all the libraries we used.
ACKNOWLEDGMENTS
This work is partially supported by the U.S. National Science Foundation (SES-2326174). This material is based upon work supported by the U.S. Department of Energy, Office of Science under Award Number DESC0025613.
This research used resources of the National Energy Research Scientific Computing Center (NERSC), a Department of Energy User Facility using NERSC award ALCC-ERCAP 0038272 (m5083-2024).
This work is supported by Czech Science Foundation Grant No. 23-07580X.
We thank Northeastern Research Computing for support with the Northeastern University Explorer cluster. This work used the Delta cluster at the National Center for Supercomputing Applica- tions (NCSA) through allocation CIS230213 from the Advanced Cyberinfrastructure Coordination Ecosystem: Services & Support (ACCESS) program, which is supported by U.S. National Science Foundation grants 21,8259, 2138286, 2138307, 2137603, and 21 2138296.
10

---

Published as a conference paper at ICLR 2026
This work uses vLLM (Kwon et al., 2023), Transformers (Wolf et al., 2020), and GNU Paral- lel (Tange, 2023).
This report prepared States Government. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, assumes any legal liability responsibil- ity for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply endorsement, recommendation, or favor- ing by the United States Government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof.
Disclaimer:
account of work sponsored by an agency of the United
REFERENCES
Wasi Uddin Ahmad, Somshubra Majumdar Scan Narenthiran, Aleksander Ficek, Siddhartha Jain, Jocelyn Huang, Vahid Noroozi, and Boris Ginsburg, Opencoderreasoning: Advancing data distil- lation for competitive coding, 2025. URL
2504. 0.1 01995. 943.
Loubna Ben Allal, Raymond Li, Denis Kocetkov, Chenghao Mou, Christopher Akiki, Carlos Munoz Ferrandis, Niklas Muennighoff, Mayank Mishra, Alex Gu, Manan Dey. Logesh Kumar Umapathi, Carolyn Jane Anderson, Yangtian Zi, Joel Lamy Poirier, Hailey Schoelkopf, Sergey Troshin, Dmitry Abulkhanov, Manuel Romero, Michael Lappert, Francesco De Toni, Bernardo García del Río, Qian Liu, Shamik Bose, Urvashi Bhattacharyya, Terry Yue Zhuo Ian Yu, Paulo Villegas, Marco Zocca, Sourab Mangrulkar, David Lansky, Huu Nguyen, Danish Contractor, Luis Villa, Li, Dzmitry Bahdanau, Yacine Jernite, Sean Hughes, Daniel Fried, Arjun Guha, Harm de Vries, and Leandro von Werra. SantaCoder: Don't reach for the stars! In Deep Learning for Code Workshop (DL4C), 2023.
Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoe Le, and Charles Sutton. Program Synthesis with Large Language Models. Technical Report arXiv:2108.0773 arXiv, August 2021. URL http: //arxiv. org. abs /2108. 07732.
ByteDance, Yuyu Zhang, Jing Su, Yifan Sun, Chenguang Xi, Xia Xiao, Shen Zheng, Anxiang Zhang, Kaibo Liu, Daoguang Zan, Tao Sun, Jinhua Zhu, Shulin Xin, Dong Huang, Yetao Bai, Lixin Dong. Chao Li, Jianchong Chen, Hanzhi Zhou, Yifan Huang, Guanghan Ning. Xierui Song, Jiaze Chen, Siyao Liu, Kai Shen, Liang Xiang, and Yonghui Wu. Seed-Coder: Let the Code Model Curate Data for Itself, June 2025.
Federico Cassano, John Gouwar, Daniel Nguyen, Sydney Nguyen, Luna Phipps-Costin. Donald Pinckney, Ming-Ho Yee. Yangtian Zi, Carolyn Jane Anderson, Molly Q. Feldman, Arjun Guha, Michael Greenberg, and Abhinav Jangda. MultiLLEE: A Scalable and Polyglot Approach to Benchmarking Neural Code Generation. IEEE Transactions on Software Engineering (TSE), 49 77:3615-3691, 2023.
Federico Cassano, John Gouwar, Francesca Lucchetti, Claire Schlesinger, Anders Freeman, Car- olyn Jane Anderson, Molly Q Feldman, Michael Greenberg, Abhinav Jangda, and Arjun Guha. Knowledge Transfer from High-Resource Low-Resource Programming Languages for Code LLMs. Artifact: Knowledge Transfer from High Resouce to Low-Resource Programming Lan- October 2024. doi: 10.1145/3689735.
guages for Code LLMs, :
URL httphttp////mm. /dl acm. wwwp///ggooo//oooooo/o///ooooeeo /00 11411144411 36677355.
Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fo- tios Chantzis, Elizabeth Barnes, Ariel Herbert- Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders,
11

---

Published as a conference paper at ICLR 2026
Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, 1lya Sutskever, and Wojeiech Zaremba. Evaluating Large Language Models Trained on Code, July 2021.
Decon Decon. / wwt.o//mallaaai.a
/econ, 2025.
DeepSeek-AL, Daya Guo, Dejian Yang, Haowei Zhang. Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang. Xiao Bi, Xiaokang Zhang. Xingkai Yu, Yu Wu, F. Wu, Zhibin Gou, Zhihong Shao, Zhuoshu Li, Ziyi Gao, Aixin Liu, Bing Xue, Bingxuan Wang. Bochao Wu, Bei Feng. Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, Damai Dai, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fucong Dai, Fuli Luo, Guangbo Hao, Guanting Chen, Guowei Li, H. Zhang, Han Bao, Hanwei Xu, Haocheng Wang. Honghui Ding, Huajian Xin, Huazuo Gao. Hui Qu, Hui Li, Jianzhong Guo, Jiashi Li, Jiawei Wang, Jingchang Chen, Jingyang Yuan, Junjie Qiu, Junlong Li, J. L. Cai, Jiaqi Ni, Jian Liang, Jin Chen, Kai Dong, Kai Hu, Kaige Gao, Kang Guan, Kexin Huang. Kuai Yu, Lean Wang. Lecong Zhang, Liang Zhao, Litong Wang. Liyue Zhang, Lei Xu, Leyi Xia, Mingchuan Zhang, Minghua Zhang, Minghui Tang, Meng Li, Miaojun Wang, Mingming Li, Ning Tian, Panpan Huang, Peng Zhang, Qiancheng Wang, Qinyu Chen, Qiushi Du, Ruiqi Ge. Ruisong Zhang, Ruizhe Pan, Runji Wang, R. Chen, R. L. Jin, Ruyi Chen, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shengfeng Ye, Shiyu Wang, Shuiping Yu, Shunfeng Zhou, Shuting Pan, S. S. Li, Shuang Zhou, Shaoqing Wu, Shengfeng Ye, Tao Yun, Tian Pei, Tianyu Sun, T. Wang. Wangding Zeng. Wanjia Zhao, Wen Liu, Wenfeng Liang. Wenjun Gao, Wenqin Yu, Wentao Zhang, W. L. Xiao, Wei An, Xiaodong Liu, Xiaohan Wang, Xiaokang Chen, Xiaotao Nie, Xin Cheng, Xin Liu, Xin Xie, Xingchao Liu, Xinyu Yang, Xinyuan Li, Xuecheng Su, Xuheng Lin, X. Q. Li, Xiangyue Jin, Xiaojin Shen, Xi- aosha Chen, Xiaowen Sun, Xiaoxiang Wang, Xinnan Song, Xinyi Zhou, Xianzu Wang, Xinxia Shan, Y. K. Li, Y. Q. Wang. Y. X. Wei, Yang Zhang, Yanhong Xu, Yao Li, Yao Zhao, Yaofeng Sun, Yaohui Wang, Yi Yu, Yichao Zhang, Yifan Shi, Yiliang Xiong, Ying He, Yishi Piao, Yisong Wang, Yixuan Tan, Yiyang Ma. Yiyuan Liu, Yongqiang Guo, Yuan Ou, Yuduan Wang, Yue Gong, Yuheng Zou, Yujia He, Yunfan Xiong, Yuxiang Luo, Yuxiang You, Yuxuan Liu, Yuyang Zhou, Y. X. Zhu, Yanhong Xu, Yanping Huang. Yaohui Li, Yi Zheng, Yuchen Zhu, Yunxian Ma, Ying Tang, Yukun Zha, Yuting Yan, Z. Z. Ren, Zehui Ren, Zhangli Sha, Zhe Fu, Zhean Xu, Zhenda Xie, Zhengyan Zhang, Zhewen Hao, Zhicheng Ma, Zhigang Yan, Zhiyu Wu, Zihui Gu, Zijia Zhu, Zijun Liu, Zilin Li, Ziwei Xie, Ziyang Song, Zizheng Pan, Zhen Huang, Zhipeng Xu, Zhongyu Zhang, and Zhen Zhang. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. Technical Report arXiv:2501. 12948, arXiv, January 2025. URL http:// /ttp:///axiv..// org/ abs/abbs////0 /tt.///11...11.......1
Mingzhe Du, Luu Anh Tuan, Yue Liu, Yuhao Qing, Dong Huang. Xinyi He, Qian Liu, Zejun Ma, and See-kiong Ng. Afterburner: Reinforcement Learning Facilitates Self-Improving Code Efficiency Optimization, June 2025.
Firefox. Why the build system might be slow. https://iirefox-ooucoe--o0 mozilla.org/bene owwabaiiggbbbl/alae hww.a///uudssseemmmmm
2025.
Jonas Gehring, Kunhao Zheng, Jade Copet, Vegard Mella, Taco Cohen, and Gabriel Synnaeve. RLEF: Grounding Code LLMs in Execution Feedback with Reinforcement Learning, October 2024.
Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Alex Vaughan, Amy Yang, Angela Fan, Anirudh Goyal, Anthony Hartshorn, Aobo Yang, Archi Mitra, Archie Sravankumar, Artem Ko- renev, Arthur Hinsvark, Arun Rao, Aston Zhang, Aurelien Rodriguez, Austen Gregerson, Ava Spataru, Baptiste Roziere, Bethany Biron, Binh Tang, Bobbie Chern, Charlotte Caucheteux, Chaya Nayak, Chloe Bi, Chris Marra, Chris McConnell, Christian Keller, Christophe Touret, Chunyang Wu, Corinne Wong, Cristian Canton Ferrer, Cyrus Nikolaidis, Damien Allonsius, Daniel Song, Danielle Pintz, Danny Livshits, Danny Wyatt, David Esiobu, Dhruv Choudhary, Dhruv Mahajan, Diego Garcia-Olano, Diego Perino, Dieuwke Hupkes. Egor Lakomkin, Ehab AlBadawy, Elina Lobanova, Emily Dinan, Eric Michael Smith, Filip Radenovic, Francisco
12

---

Published as a conference paper at ICLR 2026
Guzmán, Frank Zhang, Gabriel Synnaeve, Gabrielle Lee, Georgia Lewis Anderson, Govind That- tai, Graeme Nail, Gregoire Mialon, Guan Pang, Guillem Cucurell, Hailey Nguyen, Hannah Kore- vaar, Hu Xu, Hugo Touvron, lliyan Zarov, Imanol Arrieta Ibarra, Isabel Kloumann, Ishan Misra, Ivan Eytimov, Jack Zhang. Jade Copet, Jaewon Lee, Jan Geffert, Jana Vranes, Jason Park, Jay Ma- hadeokar, Jeet Shah, Jelmer van der Linde, Jennifer Billock, Jenny Hong, Jenya Lee, Jeremy Fu, Jianfeng Chi, Jianyu Huang, Jiawen Liu, Jie Wang, Jiecao Yu, Joanna Bitton, Joe Spisak, Jong- soo Park, Joseph Rocca, Joshua Johnstun, Joshua Saxe, Junteng Jia, Kalyan Vasuden Alwala, Karthik Prasad, Kartikeya Upasani. Kate Plawiak, Ke Li, Kenneth Heafield, Kevin Stone, Khalid El-Arini, Krithika Iyer, Kshitiz Malik, Kuenley Chiu, Kunal Bhalla, Kushal Lakhotia, Lauren Rantala-Yeary, Laurens van der Maaten, Lawrence Chen, Liang Tan, Liz Jenkins. Louis Martin, Lovish Madaan, Lubo Malo, Lukas Blecher, Lukas Landzaat, Luke de Oliveira, Madeline Muzzi, Mahesh Pasupuleti, Mannat Singh, Manohar Paluri, Marcin Kardas, Maria Tsimpoukelli, Mathew Oldham, Mathicu Rita, Maya Pavlova, Melanic Kambadur, Mike Lewis, Min Si, Mitesh Ku- mar Singh, Mona Hassan, Naman Goyal, Narjes Torabi, Nikolay Bashlykov, Nikolay Bogoy- chev, Niladri Chatterji, Ning Zhang, Olivier Duchenne, Onur Çelebi, Patrick AIrassy, Pengchuan Zhang, Pengwei Li, Petar Vasic, Peter Weng, Prajjwal Bhargava, Pratik Dubal, Praveen Krishnan, Punit Singh Koura, Puxin Xu, Qing He, Qingxiao Dong, Ragavan Srinivasan, Raj Ganapathy, Ra- mon Calderer. Ricardo Silveira Cabral, Robert Stojnic, Roberta Raileanu, Rohan Maheswari, Ro- hit Girdhar, Rohit Patel, Romain Sauvestre, Ronnie Polidoro, Roshan Sumbaly, Ross Taylor, Ruan Silva, Rui Hou, Rui Wang. Saghar Hosseini, Sahana Chennabusappa, Sanjay Singh, Sean Bell, Seohyun Sonia Kim, Sergey Edunov, Shaoliang Nie, Sharan Narang, Sharath Raparthy, Sheng Shen, Shengye Wan, Shruti Bhosale, Shun Zhang. Simon Vandenhende, Soumya Batra, Spencer Whitman, Sten Sootla, Stephane Collot, Suchin Gururangan, Sydney Borodinsky, Tamar Herman, Tara Fowler, Tarek Sheasha, Thomas Georgiou, Thomas Scialom, Tobias Speckbacher, Todor Mi- haylov, Tong Xiao, Ujjwal Karn, Vedanuj Goswami, Vibhor Gupta, Vignesh Ramanathan, Viktor Kerkez, Vincent Gonguet, Virginie Do. Vish Vogeti, Vítor Albiero, Vladan Petrovic, Weiwei Chu, Wenhan Xiong, Wenyin Fu, Whitney Meers, Xavier Martinet, Xiaodong Wang, Xiaofang Wang, Xiaoqing Ellen Tan, Xide Xia, Xinfeng Xie, Xuchao Jia, Xuewei Wang. Yaelle Gold- schlag, Yashesh Gaur, Yasmine Babaei, Yi Wen, Yiwen Song, Yuchen Zhang, Yue Li, Yuning Mao, Zacharie Delpierre Coudert, Zheng Yan, Zhengxing Chen, Zoe Papakipos, Aaditya Singh, Aayushi Srivastava, Abha Jain, Adam Kelsey, Adam Shajnfeld, Adithya Gangidi, Adolfo Victoria, Ahuva Goldstand, Ajay Menon, Ajay Sharma, Alex Boesenberg, Alexei Baevski, Allie Feinstein, Amanda Kallet, Amit Sangani, Amos Teo, Anam Yunus, Andrei Lupu, Andres Alvarado, An- drew Caples, Andrew Gu, Andrew Ho, Andrew Poulton, Andrew Ryan, Ankit Ramchandani, An- nie Dong, Annie Franco, Anuj Goyal, Aparajita Saraf, Arkabandhu Chowdhury, Ashley Gabriel, Ashwin Bharambe, Assaf Eisenman, Azadeh Yazdan, Beau James, Ben Maurer, Benjamin Leon- hardi, Bernie Huang, Beth Loyd, Beto De Paola, Bhargavi Paranjape, Bing Liu, Bo Wu, Boyu Ni, Braden Hancock, Bram Wasti, Brandon Spence, Brani Stojkovic. Brian Gamido, Britt Mon- talvo, Carl Parker, Carly Burton, Catalina Mejia, Ce Liu, Changhan Wang, Changkyu Kim, Chao Zhou, Chester Hu, Ching-Hsiang Chu, Chris Cai, Chris Tindal, Christoph Feichtenhofer, Cynthia Gao, Damon Civin, Dana Beaty, Daniel Kreymer, Daniel Li, David Adkins, David Xu, Davide Testuggine, Delia David, Devi Parikh, Diana Liskovich, Didem Foss, Dingkang Wang, Due Le, Dustin Holland, Edward Dowling, Eissa Jamil, Elaine Montgomery, Eleonora Presani, Emily Hahn, Emily Wood, Eric-Tuan Le. Erik Brinkman, Esteban Arcaute, Evan Dunbar, Evan Smoth- ers, Fei Sun, Felix Kreuk, Feng Tian, Filippos Kokkinos, Firat Ozgenel. Francesco Caggioni, Frank Kanayet, Frank Seide, Gabriela Medina Florez, Gabriella Schwarz, Gada Badeer, Georgia Swee, Gil Halpern, Grant Herman, Grigory Sizov, Guangyi, Zhang, Guna Lakshminarayanan, Hakan Inan, Hamid Shojanazeri, Han Zou, Hannah Wang, Hanwen Zha, Haroun Habeeb, Harri- son Rudolph, Helen Suk, Henry Aspegren, Hunter Goldman, Hongyuan Zhan, Ibrahim Damlaj, Igor Molybog, Igor Tufanov, Ilias Leontiadis, Irina-Elena Veliche, Itai Gat, Jake Weissman, James Geboski, James Kohli, Janice Lam, Japhet Asher, lean-Baptiste Gaya, Jeff Mareus, Jeff Tang, Jen- nifer Chan, Jenny Zhen, Jeremy Reizenstein, Jeremy Teboul, Jessica Zhong, Jian Jin, Jingyi Yang, Joe Cummings, Jon Carvill, Jon Shepard, Jonathan McPhie, Jonathan Torres, Josh Ginsburg, Jun- jie Wang, Kai Wu, Kam Hou U, Karan Saxena, Kartikay Khandelwal, Katayoun Zand, Kathy Matosich, Kaushik Veeraraghavan, Kelly Michelena, Keqian Li, Kiran Jagadeesh, Kun Huang, Kunal Chawla, Kylc Huang, Lailin Chen, Lakshya Garg, Lavender A, Leandro Silva, Lee Bell, Lei Zhang, Liangpeng Guo, Licheng Yu, Liron Moshkovich, Luca Wehrstedt, Madian Khabsa, Manav Avalani, Manish Bhatt, Martynas Mankus, Matan Hasson, Matthew Lennie, Matthias Reso, Maxim Groshev, Maxim Naumov, Maya Lathi, Meghan Keneally, Miao Liu, Michael L.
13

---

Published as a conference paper at ICLR 2026
Seltzer, Michal Valko, Michelle Restrepo, Mihir Patel, Mik Vyatskov, Mikayel Samvelyan, Mike Clark, Mike Macey, Mike Wang, Miquel Jubert Hermoso, Mo Metanat, Mohammad Rastegari, Mumish Bansal, Nandhini Santhanam, Natascha Parks, Natasha White, Navyata Bawa, Nayan Singhal, Nick Egebo, Nicolas Usunier, Nikhil Mehta, Nikolay Pavlovich Laptev, Ning Dong, Norman Cheng, Oleg Chernoguz, Olivia Hart, Omkar Salpekar, Ozlem Kalinli, Parkin Kent, Parth Parekh, Paul Saab, Pavan Balaji, Pedro Rittner, Philip Bontrager, Pierre Roux, Piotr Dollar, Polina Zvyagina, Prashant Ratanchandani, Pritish Yuvraj, Qian Liang, Rachad Alao, Rachel Ro- driguez, Raf Ayub, Raghotham Murthy, Raghu Nayani, Rahul Mitra, Rangaprabhu Parthasarathy, Raymond Li, Rebekkah Hogan, Robin Battey, Rocky Wang, Russ Howes, Ruty Rinott, Sachin Mehta, Sachin Siby, Sai Jayesh Bondu, Samyak Datta, Sara Chugh, Sara Hunt, Sargun Dhillon, Sasha Sidorov, Satadru Pan, Saurabh Mahajan, Saurabh Verma, Seiji Yamamoto, Sharadh Ra- maswamy, Shaun Lindsay. Shaun Lindsay, Sheng Feng, Shenghao Lin, Shengxin Cindy Zha, Shishir Patil, Shiva Shankar. Shuqiang Zhang, Shuqiang Zhang, Sinong Wang, Sneha Agarwal, Soji Sajuyigbe, Soumith Chintala, Stephanie Max, Stephen Chen, Steve Kehoe. Steve Satter- field, Sudarshan Govindaprasad, Sumit Gupta, Summer Deng, Sungmin Cho, Sunny Virk, Suraj Subramanian, Sy Choudhury, Sydney Goldman, Tal Remez, Tamar Glaser, Tamara Best, Thilo Koehler, Thomas Robinson, Tianhe Li, Tianjun Zhang, Tim Matthews, Timothy Chou, Tzook Shaked, Varun Vontimitta, Victoria Ajayi, Victoria Montanez, Vijai Mohan, Vinay Satish Kumar, Vishal Mangla, Vlad Ionescu, Vlad Poenaru, Vlad Tiberiu Mihailescu, Vladimir Ivanov. Wei Li, Wenchen Wang, Wenwen Jiang, Wes Bouaziz, Will Constable, Xiaocheng Tang. Xiaojian Wu, Xiaolan Wang. Xilun Wu, Xinbo Gao, Yaniv Kleinman, Yanjun Chen, Ye Hu, Ye Jia, Ye Qi, Yenda Li, Yilin Zhang, Ying Zhang, Yossi Adi, Youngjin Nam, Yu, Wang, Yu Zhao, Yuchen Hao, Yundi Qian, Yunlu Li, Yuzi He, Zach Rait, Zachary Vetioo, Zef Rosnbrick, Zhaoduo Wen, Zhenyu Yang, Zhiwei Zhao, and Zhiyu Ma. The Llama Herd of Models, November 2024.
Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi. Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xiong, and Wenfeng Liang. Deepseek-coder: When the large language model meets programming the rise of code intelligence, 2024. URL https:
//arxiv. org/ abs .1199.1.......
Zichao Hu, Junyi Jessy Li. Arjum Guha, and Joydeep Biswas. Robo- Instruct: Simulator-Augmentte Instruction Alignment For Finetuning Code LLMs, April 2025. URL http:://axxii...//////// abs abs/2405.222 20779.
Arnav Kumar Jain, Gonzalo Sonzalez-Pumarieege Wayne Chen, Alexander M. Rush, Wenting Zhao, and Sanjiban Choudhury. Multi-Turn Code Generation Through Single-Step Rewards, June 2025.
Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. Technical Report arXiv:2403.07974 arXiv, June 2024a. URL http: / arxiv. org/ abs 2403. 07974.
Naman Jain, King Han, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and lon Stoica. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. In International Conference on Learning Rep- resentationsm (ICLR), October 2024b.
Kimi Team. Kimi K2: Open Agentic Intelligence, 2025.
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng. Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023.
Ilya Loshchilov and Frank Hutter. Decoupled Weight Decay Regularization, January 2019. URL http://arxiv. org/ 1711.05100..
Anton Lozhkov, Raymond Li. Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Noua- mane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, Tianyang Liu, Max Tian, De- nis Kocetkov, Arthur Zucker, Younes Belkada, Zijian Wang, Qian Liu, Dmitry Abulkhanov, In- draneil Paul, Zhuang Li, Wen- Wen-Ding Li, Megan Risdal, Jia Li, Jian Zhu, Terry Yue Zhuo, Evgenii Zheltonozhskii, Nii Osae Osae Dade, Wenhao Yu, Lucas KrauB, Naman Jain, Yixua Su, Xuanli
14

---

Published as a conference paper at ICLR 2026
He. Manan Dey, Edoardo Abati, Yekun Chai, Niklas Muennighoff, Xiangru Tang, Muhtasham Oblokulov, Christopher Akiki, Mare Marone, Chenghao Mou, Mayank Mishra, Alex Gu, Binyuan Hui. Tri Dao, Armel Zebaze, Olivier Dehaene, Nicolas Patry, Canwen Xu, Julian McAuley, Han Hu, Torsten Scholak, Sebastien Paquet, Jennifer Robinson, Carolyn Jane Anderson, Nicolas Cha- pados, Mostofa Patwary, Nima Tajbakhsh, Yacine Jernite, Carlos Muñoz Ferrandis, Lingming Zhang, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. Star- Coder and The Stack v2: The Next Generation. Technical Report 1rXiv:2402.19173, arXiv, February 2024a. URL ht attp:// / arxiv. org/ abs/ abs/2402. 22122402..111 19173.
Anton Lozhkov. Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Noua- mane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, Tianyang Liu, Max Tian, De- nis Kocetkov, Arthur Zucker, Younes Belkada, Zijian Wang, Qian Liu, Dmitry Abulkhanov, In- draneil Paul, Zhuang Li, Wen-Ding Li, Megan Risdal, Jia Li, Jian Zhu, Terry Yue Zhuo Evgenii Zheltonozhskii, Nii Osae Osae Dade, Wenhao Yu, Lucas KrauB, Naman Jain, Yixuan Su, Xuanli He, Manan Dey, Edoardo Abati, Yekun Chai, Niklas Muennighoff, Xiangru Tang, Muhtasham Oblokulov, Christopher Akiki, Marc Marone, Chenghao Mou, Mayank Mishra, Alex Gu, Binyuan Hui, Tri Dao, Armel Zebaze, Olivier Dehaene, Nicolas Patry, Canwen Xu, Julian McAuley, Han Hu, Torsten Scholak, Sebastien Paquet, Jennifer Robinson, Carolyn Jane Anderson, Nicolas Cha- pados, Mostofa Patwary, Nima Tajbakhsh, Yacine Jernite, Carlos Muñoz Ferrandis, Lingming Zhang, Sean Hughes, Thomas Wolf, Arjun Guha, Leandro von Werra, and Harm de Vries. Star- Coder 2 and The Stack v2: The Next Generation, February 2024b.
Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma. Qingwei Lin, and Daxin Jiang. WizardCoder: Empowering Code Large Language Models with Evol-Instruct, June 2023.
Yingwei Ma, Yue Liu, Yue Yu, Yuanliang Zhang, Yu Jiang, Changjian Wang, and Shanshan Li. At Which Training Stage Does Code Data Help LLMs Reasoning? In The Twelfth International Conference on Learning Representations, October 2023.
Microsoft. Phi-4-mini technical report: Compact yet powerful multimodal language models via mixture-of-loras, 2025. URL https: / /atpiaiiivvv///////aaa///aaaavva www.iii.oggaaaa....oo.o http//bb/25555 01743.
Philipp Moritz, Robert Nishihara, Stephanic Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, and Ion Stoica. Ray: distributed framework for emerging ai applications. In Proceedings of the 13th USENIX Conference on Operating Systems Design and Implementation, OSDI' 18, pp. 561-577, USA, 2018. USENIX Association. ISBN 1981991971478.
Daniel Nichols, Pranav Polasam, Harshitha Menon, Aniruddha Marathe, Todd Gamblin, and Abhi- nav Bhatele. Performance-Alignee LLMs for Generating Fast Code, April 2024.
OCI. Open containers initiative. htttpss//peerconteiierssss
2025.
Gabriel Orlanski, Kefan Xiao, Xavier Garcia, Jeffrey Hui, Joshua Howland, Jonathan Malmaud, Jacob Austin, Rishabh Singh, and Michele Catasta. Measuring The Impact Of Programming Language Distribution, May 2023. URL
Guilherme Penedo, Anton Lozhkov Hynek Kydlíček, Loubna Ben Allal, Edward Beeching, Agustín Piqueres Lajarín, Quentin Gallouédec, Nathan Habib, Lewis Tunstall, and Leandro von Werra. Open-rl codeforces. https://hugginggee codeforces, 2025.
Baptiste Roziere, Jie Zhang. Francois Charton, Mark Harman, Gabriel Synnaeve, and Guillaume Lample. Leveraging Automated Unit Tests for Unsupervised Code Translation. In International Conference on Learning Representations (ICLR), October 2021.
Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song. Xiao Bi. Haowei Zhang, Mingchuan Zhang, Y. K. Li, Y. Wu, and Daya Guo. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. Technical Report 1oki::2402.033000 arXiv, April 2024. URL http: /awxivvvvvvv////a///aaa/eaaaavva org/
03300.
SmolLM3 Team. Smollm3. https: smol 1m3 com/, 2025.
15

---

Published as a conference paper at ICLR 2026
Ole Tange. GNU Parallel 20231122 ('Grindavik'). Zenodo, November 2023. URL https://
zenodo. wwtp:///eedd///oo./..oooo 11019005.
Yizhong Wang, Yeganeh Kordi, Swaroop Mishra, Alisa Liu, Noah A. Smith, Daniel Khashabi, and Hannaneh Hajishirzi. Self-instruct: Aligning language models with self self-generated instructions. In Anna Rogers, Jordan Boyd-Grabes and Naoaki Okazaki (eds.). Proceedings of the 6lst Anmual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 13484- 13508. Toronto, Canada, July 2023. Association for Computational Linguistics. doi: 10.18653/ v1/2023. aal.o23..c--oog.55505 URL https:::: / aal cow.haannoooooooo oog. wwt.orrg//222 aww-lllllgnno.ll 7 754/.
Yuxiang Wei, Federico Cassano, Jiawei Liu, Yifeng Ding, Naman Jain, Zachary Mueller, Harm de Vries, Leandro Werra, Arjun Guha, and Lingming Zhang. AeigCo Self-Alignment for Code Generation. CoRR, abs/2410,24198, 2024a. doi: 10:48550/ARXXY224002249988 URL
https://don org/10. 0tt///1...855001 arxiv. 2410. 24198.
Yuxiang Wei, Federico Cassano, Jiawei Liu, Yifeng Ding, Naman Jain, Zachary Mueller, Harm de Vries, Leandro Von Werra, Arjun Guha, and Lingming Zhang. Fully Transparent Self- Alignment for Code Generation. In Neural Information Processing Systems (NeurIPS), 2024b.
Yuxiang Wei, Zhe Wang, Jiawei Liu, Yifeng Ding, and Lingming Zhang. Magicoder: Empowering Code Generation with OSS-Instruce In International Conference on Machine Learning (ICML), June 2024c.
Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I. Wang. SWE-RL: Advancing LLM Reasoning via Reinforcement Learning Open Software Evolution, February 2025.
Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement Delangue, Anthony Moi, Pierric Cistac, Tim Rault, Rémi Louf, Morgan Funtowiez, Joe Davison, Sam Shleifer, Patrick von Platen, Clara Ma, Yacine Jernite, Julien Plu, Canwen Xu, Teven Le Scao, Sylvain Gug- ger, Mariama Drame, Quentin Lhoest, and Alexander M. Rush. Transformers: State-of-the-art natural language processing. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, pp. 38-45, Online, October 2020. As- sociation for Computational Linguistics. URL https: http://wwww/... aclweb. org org/anthology/ 2020. emnlp demos. 6.
Yiqing Xie, Atharva Naik, Daniel Fried, and Carolyn Rose. Data augmentation for code translation with comparable corpora and multiple references. In Findings of EMNLP, 2024.
Frank F. Xu, Uri Alon, Graham Neubig, and Vincent J. Hellendoom. A Systematic Evaluation of Large Language Models of Code. In Deep Learning for Code Workshop (DL4C), 2022.
An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, Chujie Zheng, Dayiheng Liu, Fan Zhou, Fei Huang, Feng Hu, Hao Ge. Haoran Wei, Huan Lin, Jialong Tang, Jian Yang. Jianhong Tu, Jianwei Zhang, Jianxin Yang, Jiaxi Yang, Jing Zhou, Jingren Zhou, Junyang Lin, Kai Dang, Keqin Bao, Kexin Yang, Le Yu, Lianghao Deng, Mei Li, Mingfeng Xue, Mingze Li, Pei Zhang, Peng Wang. Qin Zhu, Rui Men, Ruize Gao, Shixuan Liu, Shuang Luo, Tianhao Li, Tianyi Tang, Wenbiao Yin, Xingzhang Ren, Xinyu Wang, Xinyu Zhang, Xuancheng Ren, Yang Fan, Yang Su, Yichang Zhang, Yinger Zhang, Yu Wan, Yugiong Liu, Zekun Wang, Zeyu Cui, Zhenru Zhang, Zhipeng Zhou, and Zihan Qiu. Qwen3 Technical Report, May 2025.
Qiying Yu, Zheng Zhang, Ruofei Zhu, Yufeng Yuan, Xiaochen Zuo, Yu Yue, Weinan Dai, Tiantian Fan, Gaohong Liu, Lingjun Liu, Xin Liu, Haibin Lin, Zhiqi Lin, Bole Ma, Guangming Sheng, Yuxuan Tong, Chi Zhang, Mofan Zhang. Wang Zhang, Hang Zhu, Jinhua Zhu, Jiaze Chen, Jiangjie Chen, Chengyi Wang, Hongli Yu. Yuxuan Song, Xiangpeng Wei, Hao Zhou, Jingjing Liu, Wei- WeigYing Ma, Ya-Qin Zhang. Lin Yan, Mu Qiao, Yonghui Wu, and Mingxuan Wang. DAPO: An Open-Source LLM Reinforcement Learning System at Scale. Technical Report arXiv:2503. 14476, arXiv, May 2025. URL http: /aaiiv.iivv..///vv///aa///iiiavv www.iiioorr///oo abs///////// 2503. 14476.
Huaye Zeng, Dongfu Jiang, Haozhe Wang, Ping Nie, Xiaotong Chen, and Wenhu Chen. ACE- CODER: Acing Coder RL via Automated Test-Case Synthesis, May 2025.
16

---

Published as a conference paper at ICLR 2026
Yifei Zhou, Song Jiang, Yuandong Tian, Jason Weston, Sergey Levine, Sainbayar Sukhbaatar, and Xian Li. SWEET-RL: Training Multi-Turn LLM Agents on Collaborative Reasoning Tasks, March 2025.
17

---

Published as a conference paper at ICLR 2026
0.15
0.10
pass@11
0.08
0.03
Fortran
OCami
0.00
250
500
750
1000
1250
Training step
Figure 7: Rewards each step from training Qwen 4B on Fortran and OCaml. These are very low- resource languages, and rewards are for the first several steps.
A PREPARING DATASETS FOR AGNOSTICS
Ag-MBPP-X is a dataset of Mostly Basic Programming Problems, transformed from the MBPP (Austin et al., 2021) dataset. The source dataset contains problems asking to complete Python function from on its signature and a doestring, where the docstring specifies what result the function should return; our dataset contains equivalent programs which read/write the same data from/to standard input/output. Out of 974 problems, we are able translate 776 problems into Ag-MBPP-X (348 problems are in the sanitized subset of MBPP). We analyzed Ag-MBPP-X for data similarity against Ag-LiveCodeBench- using Decon (2025) and found no data overlap. The analysis was done based on 5-grams with no token sampling (see Decon documentation).
Processing the dataset with Qwen3-32B took less than hour using H100 GPUs. Figures 3a and 3b in the main body of the paper shows sample problem from the dataset, before and after the reformulation. We used the following prompt.
You are competitive programming expert.
You are given problem that asks you to implement function.
Your task to translate the description of the problem. into a form that accepts one set of function arguments as inputs and return the function return value as output.
Use programming compatition style input and outputs that is, priorize the use spaces and newlines to separate inputs and outputs over using connas and parentheses (or other delimiters). Specifically, for should print them as list of lists, where the outer separated by newlines and the clements of the inner lists are separated by spaces.
2d lists,
lists clements
For example, a 2d list like [[1, 21, [3, 4]] should printed as:
1 2
4
Do not any other delimiters.
If there are multiple 2d lists, you should use 2 newlines to separate
them.
for example, 2d list like [[1, 21, [3, 41] and [[5, 61, 17, 8]] should
printed as:
2
3 4
If the problem requi res outputing decimal numbers, make sure the output format specifies fies round all decimal numbers 4 decimal places.
18

---

Published as a conference paper at ICLR 2026
this case, you should also zound all the numbers in the output to decimal places.
Do not forget to specify the input and output format in the description.
Here is the problem description: (original mbpp problem descriptien)
Here are the test cases:
loriginal mbpp test cases)
You should return json object with the following fields:
"description"; the description of the problem formatt_ string describing the input format
"output__foratt": string describing the output format
"tests": list of test cases, each test case a json object with the following fields:
"iinput:: a string that represents the input of the test case, in the same format the input format in the description
"output": string that represents the output of the test case, in
the same format as the output format in the description
Place your respense in single "Yison block. Do not include any other text in your response.
Ag-Codeforces-X is a dataset of competitive programming problems, created from Codeforces problems in the open-rl peee-rr/codefore wwweeooooeeeeeoooooooooooo dataset. The source problems already specified pro- grams by their I/O behavior, hence only very minor changes were needed to build language- universal Agnostics problems out the fields the dataset: we only skipped the time and memory restrictions present in the original problems. To be precise, we used data from the open-ri/cooeffoo -ortssscots dataset, solut uu iotiionsan ons_pynssp...... spy_dccontmminn.
subset, which contains problems decontaminated using 8-gram overlap against multiple benchmarks, in particular LiveCodeBench. We used the auxilliary checker interactor subset to only keep the prob- lems which admit simple verifier for their solutions, i.e., problems where single output is correct for each input and where the solution only needs to read data from its input, compute the result, and write the standard output. We prepared both a train and a test split. The former contains 5369 problems and the latter contains 105 problems we held out from the source dataset, selected manually and 100 randomly. The manually-seless average, to make it easier to detect if a model can solve any problems at all in given programming language. In short, the problems are: "output number binary notation", "remove all digits from string", "check if the parentheses are balanced"', "parse two integers and add them", and the following longer problem: "Petr stands line of n people, but doesn't. know exactly which position he occupies. He can say that there are less than people standing in front of him and no more than b people standing behind him. Find the number different positions Petr can occupy."
problems were chosen be much easier than
The train split features randomized prompts, which we found help with generalizing the results of training on the dataset to other benchmarks. The prompts were randomly split into a number of types. 30% of the prompts use standard Markdown headings start different sections of the prompt, 35% use bold text instead, and the remaining 35% simply concatenate the prompt sections together. Most of the prompts follow the source dataset and feature I/O sample in the prompt, with other samples withheld as private. Half of the prompts of the final type do not feature any I/O sample.
AedeeveCoaeeeeech-X is also a dataset competitive programming problems, created from a subset of the LiveCodeBench dataset (Jain et al., 2024a). LiveCodeBench 5.0 has 880 problems, of which 381 have Python starter code and test cases. The remaining 499 problems do not use starter code and instead use standard I/O to specify and test solutions. Hence used these problems to transform LiveCodeBench into an Agnostics dataset. Ag-LiveCoodeBench only has a test split, like its source dataset.
19

---

Published as a conference paper at ICLR 2026
B AGNOSTICS CONFIGURATIONS
In this section, we list the configurations that we for our target languages. The configuration files use YAML. The prompts for OCaml and Fortran have instructions generated by OpenAl o3.
The Lua configuration:
prompt: Use Lua 5.1, targeting LuaJII.
install: apt-get install Luajit
filename: snippet. lua
execute: luajit snippet.lus lua
The Julia configuration:
prompt: Use Julia 1.11.
container:
base-image: 111.
type: debian
filename: snippet.
exccute: julia snippet. j1
The R configuration (unmodified, unlike Figure 4):
install: apt-get install -y r-cran-tidyverse filename: snippet.R
exccute: Rscript snippet.R
prompt:
Use R version 4, Use 'readLines (con file ("stdini)""))) to read input from stdin. Optionally, use the 'n" argument to read the first 'n lines. For example: ''
input readLines (con file ("stdin)), n 1)
n <- as as.integer (inputt
cat (n) # print the first line of input
Also, use 'cat" print output to stdout. For example: ''
cat (n)
Please do not use 'print' to print output.
The OCaml configuration:
prompt:
Use OCaml 5.
Numbers:
mod
/. (add dots!)
Casts:
iloat_of int int_of float int_of oat_of__ttee of_string refs (:= !) or pass new values recursively
Mutation:
Strings:
split on on_oon______a char, String.get => char, use Printf "$c"
Lists:
avoid List.nth; prefer pattern-match / folds / arrays
container:
base-image: "docker wwt.i////////aaaa/a 2ttp:////aaaagaama..uuuuaaa----0
type: debian
install:
container-instructiosss
RUN opam install base stdio utep
ENV OPAM_SWITCH BREEH__PEEFEE IX='
ENV CAML LD B.DDLIBBARY _
/home/ http://////1////////
ENV http://ww.wwww..a.oe/////////ors
ENV MANPATH"' h/t.m//opaa//cccccccoooo htt.:/amm..paa.......m
20

---

Published as a conference paper at ICLR 2026
ENV PATH=' usr/sbin: baal:::/ur///i://ee / filename: snippet.ml
execute: utop -require basc -require stdio snippet. .ml
The Fortran configuration:
prompt:
Use Fortran 90. Some tips:
Always begin each scope with implicit none, pick explicit kinds via selected_+_king and declare proper lengths-character (1ennt))
(1en=+) is legal only for dummy arguments, not locals. Strings are blank-padded: call len_trim before iterating, and store dynamic text in deferred- length allocatables (character (Len=:), allocatable :: s), List- directed read(*,*) arr does not auto-size arrays; read a count first, then allocate and read, or tokenize a line manually. When translating 0-based formulas (heaps, bit positions) remember Fortran arrays default to 1-based; you want C-based, declare lower bounds.
Use real literals (2.0d0, 1.0_rk) to avold silent intsger division, and guard against overflow when exponentiating integers. For frequency tables, allocate native dicts/sets, so you must implement search yourself. Prefer array intrinsics (sum, count, pack) over hand-rolled loops, and keep helper procedures inside a contains section or module so interfaces are explicit. return inside the main program is non-idiomatic; use structured blocks or stop. Never print interactivo ive prompts in batch solutions; just read, compute, and write. install: apt-get install -y gfortran
array or use findloc; Fortran lacks
filename: snippet.f90
compile: giortran snippet. snippet.f90
execute: //snippet.out
C TRAINING AND RESULTS
C.I CHOOSING HYPERPARAMETERS
Before picking the hyperparameters described in $3.3, we investigated other values by training the Qwen 3 4B model on previous version of Ag-Codeforces-X. We trained two models for each of Lua, Julia and R, using a linear learning rate schedule with the same learning rate. We decided against since some of the runs degraded the model's capabilities, unlike any of the with a cosine decay schedule.
did
We compared between GRPO group sizes of 16, 32 and 64 by training the same model Lua. In some runs with group size 16, we saw the model improved significantly less than at higher group sizes. We an experiment compared different temperature and group size settings (Table 6).
The models trained at group size 16 had slightly lower scores compared to other models, while the ones trained at group size 64 displayed scores comparable to other models. However, they took significantly longer to train. Two group size 64 models took ~ 20.5h to train on average (the third one was trained on different machine). In comparison, the group size 32 models trained the same time on the same machine took ~ 12h average. The models trained at temperatures other than the 0.7 recommended by the Qwen team performed similarly to the other models.
As we found no significant difference between the temperature settings and between group sizes 32 and 64, we chose the smaller group size due to limited resources, and used the recommended temperature settings.
C.2 TRAINING DYNAMICS
In this section we discuss the measurements we took while training the models. Figure shows the GRPO group batch p while training the Qwen3-4B-CF-X models. The scores of all the
21

---

Published as a conference paper at ICLR 2026
Table 6: Hyperparameter sweep, pass@1 score.
Model
Group size
Temperature
Ag-LaveCootRench-X
Qwen3-4B-CF-Lua
32
0.7
23.00
normal-rl
32
0.7
19.87
normal-r2
32
0.7
21.58
sizel6-rl
16
0.7
19.80
size16-r2
16
0.7
19.40
size16-r3
16
0.7
19.65
size16-r4
16
0.7
20.61
size64-r1
64
0.7
21.71
size64-12
64
0.7
21.21
sizc64-r3
64
0.7
20.87
tempOp2-rl
32
0.2
19.91
temp0p2-12
32
0.2
20.39
temp0p2-r3
32
0.2
21.98
templ-rl
32
1.0
21.22
temp1-r2
32
1.0
21.48
templ-r3
1.0
20.30
0.25
group batch pass@1
0.20
0.15
0.10
Lua Julia
0.05
R
OCaml
Fortran
0.00
250
500
750
1000
1250
Training step
Figure 8: Training Qwen3-4B-CF-X, GRPO group batch pass @ 1.
0.3
pass@1 accuracy
0.2
Lua
Julia
0.1
OCaml
Fortran
0.0
250
500
750
1000 1250
Training step
Figure 9: Training Qwen3-4B-CF-X,, test split pass@1 1,
22

---

Published as a conference paper at ICLR 2026
Lua training curves
0.3
0.2
Lasso
0.1
train test
250
500
750
1000
1250
Training step
Figure 10: Training Qwen3-4B-CF-Lua, GRPO group batch and test split pass @ass@)
Julia training curves
0.3
train
test
pass@1
0.2
0.1
0
250
500
750
1000
1250
Training step
Figure 11: Training Dowe3-4B-CF--Jlly GRPO group batch and test split pass @ 1.
R training curves
0.3
pass@1
0.2
0.1
test
0
500
750
1000
1250
Training step
Figure 12: Training Qwen3-4B-CF-R GRPO group batch and test split pass @ 1.
23

---

Published as a conference paper at ICLR 2026
OCaml training curves
train
0.15
test
pass@1
0.10
0.05
0.00
250
500
750
1000 1250
Training step
Figure 13: Training Qwen3-4B-CT-OCaml, GRPO group batch and test split pass @
Fortran training curves
train
0.15
test
pass@1
0.10
0.05
0.00
250
500
750
1000 1250
Training step
Figure 14: Training Qween3-4B-CF-Forttan GRPO group batch and test split pass @
24

---

Published as a conference paper at ICLR 2026
Table 7: Partial reward experiment, pass @ rates.
Model
Ag-LiveCCodeBench-X Ag-Codeforces-- X (test split)
Qwen3-4B-CF-Bn
23.00
24.76
partial-ri
18.57
13.33
partial-r2
20.16
15.62
models are broadly correlated with one another, which may at least in part be due to training them on the same permutation of the training data. Figures 10 to 14 compare the GRPO group pass@) scores with the pass@1 scores on the test split. We see that the scores on test split broadly correlated with the train split rewards. In most cases, until the end the epoch, together with the test split pass@ scores, indicating that the model keeps improving until the end of the dataset.
that the train scores keep increasing
C.3 REWARD FUNCTION
We investigated the results of partial rewards. We trained Qwen 4B-the base model of Qwen3- 4B-CF-X-on Ag-Codeforces-Lua, giving it a partial reward of 0.2 if generated code which failed one of the tests by producing wrong output but otherwise terminated without an error. The full reward for snippet passing all tests was still 1. Table 7 shows that the trained models score below Owen3-4B-CTF-Fortee both on Ag-LiveCooeBencch-lee (counting only the full-credit reward). The latter scores are particularly far lower, clearly showing that the models learned to abuse the partial-credit reward.
and on the test split ag-Codeforces-Lne
During training, we saw the models focus the partial reward. The average result from the partial reward component was clearly increasing more quickly than the result from the full reward compo- nent. In the training generations we inspected, the models also often claimed to generate "draft" answer and produced program which ignored the problem in the prompt, for instance by only printing hard-coded string such as "0".
C.4 SEAS--RRRRRAMMGG-AAAAANA
NEGATIVE TRANSFER
To demonstrate that Agnostics training does not lower performance on different programming lan- guages, we evaluated the models we trained on variants of gg-LiveCodeBench-XX (Table 8),
C.5 HARDWARE AND SOFTWARE USED
We used three machines while working on this paper: B, R1 and R2. R2 was only used to generate completions of trained models for evaluation, while B and RI were used to train models. Upon publication of the paper, will publicly release Wandb records of our training runs, which include the duration and the machine used.
B has 2 Intel Xeon Gold 6342 CPUs @ 2.80GHz, 1008 GB of RAM, 4 NVIDIA H100 80GB, and uses Ubuntu 22.04.5 LTS.
RI has 2 AMD EPYC 9454 48-Core CPUs, 8 NVIDIA H100 80GB (with NVLink connections), 2268 GB of RAM, and uses Ubuntu 22.04.5 LTS.
R2 has 2 Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz, 10 NVIDIA RTX A600, 504 GB of RAM, and uses Ubuntu 22.04.5 LTS.
When developing the Agnostics framework, used the following major Python libraries: ray v2.46.0, torch 62.6.0, transformers v4.54.1. vllm v0.8. postl, datasets v3.4 4. wandb 0.19.11.
25

---

Published as a conference paper at ICLR 2026
Table Cross-PL evaluation, pass rates.
Model
Ag-LiveCoodBench--
Python
Lua
Julia
R
Qwen 3 4B
34.34
11.00
10.00
10.00
Qwen3-4B-CF-
32.96
23.00
6.55
3.00
Qwen3-4B-CF-Jum
35.10
8.43
22.00
3.90
Owen3-4B-CF-R
31.58
9.08
7.92
15.00
Qwen 3 8B
33.51
11.00
9.00
9.00
Qwen3-8B-CF-Lua
34.29
25.00
7.44
5.96
Owen3-8B-CF-Julia
33.84
8.26
25.00
7.03
Qwen3-8B-CF-R
34.49
9.90
7.34
19.00
DSC 6.7B Ins
16.86
7.89
4.79
7.97
LSC-C.-B-In-CC--Luaa
17.63
8.60
DSC-6.7B-Ins-CF--
17.60
9.54
9.13
8.56
DSC-6.7B D1C-6.7B-Ins-C--
17.62
8.38
5.75
9.83
Phi4 mini ins
19.87
7.95
8.10
4.69
Phi4-mini-ins-CF-1
22.16
11.80
8.02
4.56
Phi4-mini-ins-CI
21.15
9.10
7.69
Phi4-mini-ins- CF-R
19.82
8.02
8,54
11.54
SmolLM3 3B
20.91
1.02
2.85
2.07
SmolLM3 -B- 1115-B-CFFLLAE CF-Lua
21.81
7.46
2.93
2.17
SmoILM3- -3--MB------ulla
21.58
1.53
7.83
2.39
SmolLMM33BB-CF-R
21.63
1.30
3.30
5.90
D BUG TAXONOMY
D.1 PROMPT FOR GENERATING TAXONOMY
We used the following instructions to generate the bug taxonomy, followed by a list of faulty R programs.
Input:
The attached file contains multiple failed programs (Version 4) with
their:
Source code
Expected output
Actual standard output
Error messages (where applicable)
Objective: Analyze these program failures systematically to create compre- hensive taxonomy of 10-12 bug themes that categorize the underlying causes failure.
Instructions:
Initial Analysis
Read through ALL program examples carefully
For each failure, identify the root cause (not just the symptom)
Note any patterns or commonalities across failures
2. Taxonomy Development
Create 10-12 distinct bug themes that collectively cover all observed fail- ures
Each theme should represent fundamental type of programming error or misconception
Themes should be mutually exclusive when possible, but comprehensive in coverage
Order themes from most to least frequent (or by logical grouping)
3. For Each Bug Theme, Provide:
26

---

Published as a conference paper at ICLR 2026
Theme Name: A concise, descriptive title
Description: 2-3 sentences explaining the nature of this bug type
Common Symptoms: How these bugs typically manifest (error messages, incorrect output, etc.)
Root Causes: The underlying programming mistakes misconceptions
Examples: Reference 2-3 specific programs from the file that exhibit this theme
Prevention Tips: Brief advice on how to avoid this type of bug
Constraints:
Focus on R-specific issues as well as general programming errors
Base your taxonomy ONLY on the provided examples
You may search online ONLY to understand specific R error messages function behavior, not for existing bug taxonomies
Ensure every failed program in the file can be classified under at least one theme
Deliverable Format: Present your taxonomy as numbered list with clear formatting and comprehensive coverage of all observed failure patterns. Sup- ply a short explanation for each theme in your taxonomy.
The prompt produced a taxonomy of 11 bug categories. We edited these categories and selected categories relevant us, shown in $D.2.
D.2 BUG TAXONOMY USED FOR ANALYSIS
The following categories represent the prevalent themes of programming errors we use in our anal- ysis of bugs in model-generated code. They cover the full spectrum of parse, runtime, and logical failures typically encountered in programming. The themes are not mutually exclusive; we allow program to have than one themes.
1. Syntax and Typographical Errors: Missing commas, mismatched parentheses, or other typos that cause compile-time parse errors.
2. Input Reading and Parsing Errors: Mis-reading or mis- mis-ppasing input, leading to empty or malformed variables and subsequent failures.
3. Uninitialized Variables: References to variables never defined, causing undefined behav- ior or runtime faults.
4. Data Type and Conversion Errors: Incorrect casting or type misuse that triggers type errors, warnings, or incorrect results.
5. Function Misuse and Missing Libraries: Invocations of non-existent or mis-paarameterized functions, or missing imports/libraries, causing errors.
6. Algorithmic Logic Flaws: Programs that compile and run but produce wrong answers due to faulty logic or conditions.
7. Output Formatting and Presentation Errors: Correct computational results, but incor- rect due to formatting issues (e.g. missing newlines/spaces or output spec violations).
D.3 RADAR CHARTS FOR ALL PROGRAMMING LANGUAGES
Figures 15, 16, 17, 18, 19 show the emror theme charts for all the programming languages trained a model on. Figure 18 is the same as Figure 6 from the main body; we repeated it here for conve- nience.
27

---

Published as a conference paper at ICLR 2026
and
Typographical Errons
Outout Form Presentation
and Parsing Enrons
Erons
40%
Algorihmmic Logic Flaws
Uninitalized Variables
Type
Missing Libraries
Errors
Qwen3-46
Qwenn
Figure 15: Radar chart of Lua error themes for Qwen3-4B and Qwen3-4B-CF-LB
Syntax and Woograppiicl Errors
Dutout Form and Presentation Erros
Reading and Parsing Errors
30%
Algorthmic Logic Flaws
Uninitalized Variables
Misuse Missing Libraries
Conversion Emers
Qwen8 4B
4B-CF-julio
Figure 16: Radar chart of Julia error themes for Qwen3-4B and Owwn3-4B-CF-JJu
28

---

Published as a conference paper at ICLR 2026
and
Typographical Errons
Outout
Form Presentation
and Parsing Errons
Erons
Algorthhmic Logic Flaws
Uninitalized Variables
Type
Missing Libraries
Errors
Qwena-48
Owera 4B-CF-R
Figure 17: Radar chart of R error themes for Qwen3-4B and Qwen3-4B-CF.
Syntax and Woograppiccl Errors
Dutout Form and Presentation Erros
Reading and Parsing Errors
Algorthmic Logic Flaws
Uninitalized Variables
Misuse Missing Libraries
Conversion Emers
Owen3 48
40 40-C0--0000 -T-OCmmm
Figure 18: Radar chart of OCaml error themes for Qwen3-4B and Swen3-4B-CF-OCC
29

---

Published as a conference paper at ICLR 2026
and
Vyoogaaphical Enrons
Dutput
Form Presentatin
and Parsing Errons
Errors
Algorithmic Logic Flaws
Uninitalized Variables
Missing Libranies
Conversion
Errors
Qwen3-48
Owen3-48-CT-fonee
Figure 19: Radar chart of Fortran error themes for Qwen3-4B and Qonrtran--CF-Fortann.
30


Reviews:
[{"review_id": "qbEub5gQ8x", "reviewer": "Reviewer_ZVFQ", "summary": "The paper introduces Agnostics, a language-agnostic RL pipeline that reformulates coding tasks into standard I/O problems and trains code LLMs using verifiable rewards in a containerized sandbox. With small per-language configs, the same verifier supports many languages. Applied to Lua, Julia, R, OCaml, and Fortran, Agnostics boosts small open models to match/exceed larger baselines.", "questions": "•\tCan you elaborate more on what is the contribution of the paper? Can you clarify the fundamental, theoretical or algorithmic level contributions?\n\n•\tDid you perform any ablation studies related to KL term and partial-credit reward?", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "•\tConsistent gains across five low-resource languages with small models.\n\n•\tNew multi-language benchmark and dataset.", "weaknesses": "1.\tWhile the contribution is clearly useful and highly practical, my main concern with the paper is that the contribution is more of an engineering improvement rather than a fundamental scientific contribution grounded in theoretical or algorithmic insights.\n\n2.\tAppendix A argues that rejection sampling is prohibitively expensive on hard tasks. A direct empirical comparison would clarify efficiency and quality trade-offs\n\n3.\tThe paper would benefit from a more detailed ablation study: (i) reintroduce a KL term and show effects on stability/generalization; (ii) quantify partial credit reward pitfalls; (iii) temperature/group size sweeps beyond the brief D.1 notes. This would strengthen the methodological contribution beyond the system build.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "Z6XATLxxMq", "reviewer": "Reviewer_oRWA", "summary": "This paper introduce Agnostics, a programming language-agnostic LLM post-training pipeline. The main idea is to rewrite the coding questions into a question that are programming agnostic and only works on standard input/output. Then, these questions can be further rewritten into programming language specific questions. Experiment results show that Agnostic can significantly improve the model performance in low resource programming languages.", "questions": "My main concern is that the training is not performed on data from all languages mixing together. Can you show such results? We would like to verify that there are no negative transfer across programming languages and the approach is indeed pushing the frontier.", "limitations": "", "rating": 4, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "1. The proposed idea is quite simple and elegant. With the proposed approach, we can theoretically turn coding problems in any programming languages into other languages.\n2. It achieves promising results on single language training, showing that models trained with such data achieves much better performance in low resource languages. What's more interesting here is that the improvement generalizes beyond standard I/O problems.", "weaknesses": "1. The number of programming languages tested are limited (5 of them). Moreover, it is only trained on data from a single programming language in each experiment. This is not a usual setup. Ideally, we would like to mix data from all programming languages together (high and low resources), and see how the performance of high/low resource languages change.\n2. Unfortunately the model scale is also limited (up to 8B). So we cannot verify if this approach can scale well with model size.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "FVTfaEI2v8", "reviewer": "Reviewer_pRJF", "summary": "The paper proposed a training pipeline that can be used in any programming language with only a small configuration file by describing the input and output specification in pure text format.\n\n* The proposed method does not require a language-specific verifier to verify and provide the rewards but rather evaluate the model on the observable behavior, in this paper, the text output.\n* It provides several datasets that have only I/O description and a suite of tests with only input and output. in text format.\n* It provides a high optimized GRPO training framework with code execution sandbox.\n* It provides a SOTA open-weight 4B model on low resource language under 16B size.", "questions": "* Line 240, miss the definition of the $r_{i,t}(\\theta)$\n* Line 255, please explain OCI\n* Line 335. how is the score defined?\n* Line 420, can you clarify the $96.\n* Line 424, what’s the epochs used in table 2 for Qwen3-4B-CF-Fortran.\n* Line 916, what's the 7 manually selected problems and how is it selected?\n* Do you have a analysis on the data similarity between CF-X and LCB-X, same for the MBPP-X and LCB-X. This is important to exclude the factor from data similarity in the score improvement.", "limitations": "", "rating": 8, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "* The training pipeline address the task from a different direction where only evaluating on the input and output, so it can be applied to any language without a language specific verifier. And specifically, reward on the format is offloaded into a prompt prefix instead to instruct the model to follow the format.\n* In low resource languages, the claimed method shows good improvement on small models and even beating bigger models trained specifically on the code task.\n* The paper is well written, it constructs a clear flow from problem to method to the final evaluation. The experiments, setup and training hyperparameters are described clearly.\n* The paper does a thorough analysis on the approach, including the impact on the different model architecture, model size, training data and fine grained analysis on models’ error types.", "weaknesses": "* Given the importance that a good prefix helps avoid the **most common** errors and if the model barely knows a programming language per line 199, and you select several faulty generation for generating the verbatim, I image this has to be representative so that the model can generate a verbatim that can avoid the **most common** errors, so I think it’s necessary to include a description on how to select the faulty generations. \n* Line 76 claims the paper provides a small and highly-optimized training framework, but there is no analysis/experiments/comparison to demonstrate.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)