Papers
arxiv:2610.28027

From RL Papers to Framework Code: Inclusion and Review in Seven Open-Source Training Frameworks

Published on Oct 20
· Submitted by
Pantaiheng
on Oct 22
Authors:

Abstract

Most proposed reinforcement learning training methods for language models are not adopted by open-source frameworks, with adoption rates remaining low despite growing publication volumes.

Practitioners use reinforcement learning methods for language models through training frameworks, so a method that a framework includes is one configuration change away for its users. We measure how often this happens. We trace seven open-source frameworks for RL post-training through their commit histories and link them to 6,939 screened arXiv papers from January 2025 to June 2026. Of 1,598 papers that propose a general RL training method, 37 reached at least one framework. Across five quarterly cohorts of papers, the number included within 180 days stayed between 5 and 7 while the cohorts grew from 72 to 386 papers. Compared with papers from the same quarters, included papers more often trained policies of 30B parameters or more, at 41 against 10 percent, and more often changed a coefficient, clip, mask or weight in the existing loss, at 29 against 9 percent. Both gaps hold without papers from the companies that maintain the frameworks, while code release was equally common in both groups. The frameworks' issues and pull requests show that few methods are turned away in public. More than nine in ten of the general methods no framework included have no thread there that cites or names them, and many proposals that do appear stay open without a reply. Two further records, the frameworks' issues and the technical reports of 13 large open-weight models, show that users rarely report training failures in public and that the reports state 8 of the 13 widely included methods. We release the data as a tracker that links training failures to framework implementations and lists each framework's contribution rules and earlier proposals.

Community

Paper author Paper submitter

We trace seven open-source RL training frameworks (verl, TRL, OpenRLHF, NeMo-RL, ROLL, slime, AReaL) through their commit histories. Of 1,598 arXiv papers that propose a general RL training method, 37 reached at least one framework. The tracker updates weekly, and you can search any method to see which framework offers it, under which setting, and the pull request that added it.

The flat 5–7 merges per cohort is the number worth arguing about, and I don't read it as a discovery ceiling — that's maintainer throughput. Seven frameworks landing in the same band, year after year, looks like a review-capacity constant, not a verdict on which methods deserved to land. The gate that actually decides adoption is earlier than review: can the method be expressed as a config diff on an existing trainer, or does it need a new training loop? A loss swap plus a dataloader flag gets reproduced in a weekend by someone who never opens a PR. Meanwhile the thing people actually run is the unmerged fork with forty stars and a half-broken README, not the blessed merge six months downstream. I'd put time-to-first-working-reproduction on the x-axis instead — time-to-merge mostly measures how busy the maintainers are. Happy to be wrong, but then show me a cohort where the merge rate tracked something other than reviewer headcount.

·

Thanks, this is a useful push. One clarification first: the 5 to 7 is the total across all seven frameworks for each of the five quarterly cohorts, counting papers whose method reached at least one framework within 180 days.

I agree that review capacity shows up in the data. Of the 28 pull requests that proposed methods no framework included, 17 were still open at the snapshot after a median of 196 days, and no prior merger had replied in 13 of them.

It cannot explain the flat count alone, though, because most methods never reach review. Only 40 of the 1,561 methods no framework included have a proposal we could find, and 96% have no issue, pull request or discussion that cites them. A throughput limit would leave a growing queue of proposals, and the queue we see is small.

Your config-diff gate matches what we found: included papers more often changed a coefficient, clip, mask or weight in the existing loss (29% vs 9%). And yes, inclusion is not use. The tracker measures what a framework offers on its main branch, not what people run. Time to first working reproduction would be a better axis for use. The hard part is a public signal that a fork works. If you have one in mind, I'd like to add it.

Sign up or log in to comment

Get this paper in your agent:

hf papers read 2610.28027
Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash

Models citing this paper 0

No model linking this paper

Cite arxiv.org/abs/2610.28027 in a model README.md to link it from this page.

Datasets citing this paper 0

No dataset linking this paper

Cite arxiv.org/abs/2610.28027 in a dataset README.md to link it from this page.

Spaces citing this paper 0

No Space linking this paper

Cite arxiv.org/abs/2610.28027 in a Space README.md to link it from this page.

Collections including this paper 0

No Collection including this paper

Add this paper to a collection to link it from this page.