I am also curious! The inner-RL-loop models are only trained once, then disgarded. But the outer-RL-loop model is trained on the same tasks over and over again. I imagine it would overfit after many more steps, but perhaps with a larger set of diverse tasks, the model would simply improve.
AI trains AI already, agents are happy to spin up real training pipelines for deep learning or regression models or whatever you want right? I guess the advantage to your project is that it provides a framework to allow the agent to access extra compute?
Yes I'd heard the labs (Anthropic mostly) speaking about LLMs training LLMs, so I wanted to make things a little more concrete and test it out myself! Essentially you are correct though, my framework allows the agent access to compute, but also the agent itself is being trained to become better at training models with that compute.
Yes exactly, and also there is auto-research by Karpathy, Fable-5 on parameter golf etc which point to the direction of highly-assisted / autonomous AI training as the future. Wild.
“The Anthropic team for their incredible coding models (Fable-5 wrote every line of code in this project), and the Claude Code harness.”
Source: the repo
When you vibe code a system in a complex area like RL, you basically have zero understanding of what its actually doing, whether its actually any good or not, what you're actually benchmarking, and when the system would fail.
I chose the key technical decision and direction (such as the system architecture, the tasks to train on, the stack of Tinker, Prime-RL & Runpod - all of which I know well) etc.
The problems it would do well on are training small agentic (multi-turn, tool use) task based models using the prime-rl stack, which are close to the distribution trained upon. It would likely not transfer to other training frameworks such as SLIME, ART or ROLL, it would also likely not transfer well to RL for complex agents such as coding agents etc.
It is limited due to its scale. As a single person, the resources required to train this on a more diverse dataset, with more complex tasks on a larger variety of models, is outside my abilities! I believe there are many avenues to explore to improve performance for this to be genuinely valuable. For now, this just a proof of concept to show the possible.
I would like to think I have a good understanding of RL, evaluations, and agentic systems after a few years of working on these areas. However, I will always have gaps. I use Fable to help accelerate me, and fill those gaps at the same time, from which I can learn from too.
I think the counter point for these projects is that you may not need a deep understanding if you can measure the outcome. While this may not be true every time today, it plausibly will be in the future - making the activity worthwhile.
Yes I do agree with this. I believe we are shifting from "make the model good" (prompt/context engineering, etc) to "define good for the model" (success criteria/rubrics). Over time I believe this will become increasingly obvious (as long as model capabilities continue to increase).
Well, you say that, but when "measuring" anything in RL, that measurement itself is not always obvious.
That is, creating the scoring system/judge models etc for RL is not easy at all. You can easily create an RL loop which is getting better and improving its scores, but actually the result is totally garbage, because you're measuring the wrong thing.
I RL-trained an agent whose job is to write RL training jobs for smaller models, and open-sourced the whole thing.
The setup is two nested RL loops:
- Outer loop: the trainer agent (Qwen3.6-35B-A3B, LoRA) is handed a task spec ("teach a small model to do X"). It works in a sandboxed workspace with file tools and writes a complete prime-rl training job: a verifiers environment + rubric, a dataset, and a hyperparameter config. Submitting triggers a validation probe with capped retries.
- Inner loop: each validated job is dispatched to a warm pool of up to 16 Runpod GPU pods, where prime-rl GRPO-trains a small Qwen (0.6B or 1.7B). The checkpoint is scored pre/post on a hidden eval the agent never sees.
- The inner model's improvement flows back up as the outer loop's reward (plus a validation-efficiency term and a small train-speed tie-breaker). The outer loop is tinker-cookbook's importance-sampling GRPO, run async off-policy so one slow episode doesn't stall a batch.
Results, over 54 outer-loop steps (~1,750 real GPU training jobs):
- Episode reward went from ~0.0 to a ~0.63 peak.
- Learning came in two distinct rungs: first "stop failing validation and dying on GPUs", then "make better models". GRPO took the steepest gradient first — the entire early gain was process reliability, and only once that saturated did the hidden-eval scores of the trained models start climbing.
- It transferred to a held-out task family that the agent never trained on: mean reward 0.399 untrained → 0.545 at step 34, easing to 0.49 by step 54 (n=10 per arm, so noisy — a rise then a plateau/dip).
- The agent learned to stop picking the weaker 0.6B base model (1.7B share of its jobs: 42% → 95%) and started actually using the hyperparameter surface (21% → ~78% of episodes).
Cost: the headline arc was ~$1.3k all-in (~$810 Runpod, ~$465 Tinker). Each inner training job cost ~$0.13–0.30 — a benchmark matrix over GPU × base-model picked cheap pairs (mostly A40s in practice, since the cost-winner was rarely in stock).
Two honesty notes: the outer loop runs through Tinker's managed API rather than local GPUs — the inner loop is all open-source stack on rented pods. And ~$1.3k is the headline arc, not the project; the pilots and blind alleys that got me there cost a few hundred more, and every one of them is written up in the retros in the repo, including the failures.
I did this because I think agents that improve other AI systems are going to be a big part of the next few years, and I wanted to know what it actually takes to get the reward moving. Turns out: way more debugging of the process than the policy, and it's all more accessible than it looks.
Happy to answer questions about the reward design, the GPU orchestration, or the things that didn't work.
I'm curious to whether the recursively trained models degenerate to troglodytes after a couple of generations.
I am also curious! The inner-RL-loop models are only trained once, then disgarded. But the outer-RL-loop model is trained on the same tasks over and over again. I imagine it would overfit after many more steps, but perhaps with a larger set of diverse tasks, the model would simply improve.
AI trains AI already, agents are happy to spin up real training pipelines for deep learning or regression models or whatever you want right? I guess the advantage to your project is that it provides a framework to allow the agent to access extra compute?
Yes I'd heard the labs (Anthropic mostly) speaking about LLMs training LLMs, so I wanted to make things a little more concrete and test it out myself! Essentially you are correct though, my framework allows the agent access to compute, but also the agent itself is being trained to become better at training models with that compute.
i remeber reading in one of the release blog posts that that version was the "first that codex helped train"
Yes exactly, and also there is auto-research by Karpathy, Fable-5 on parameter golf etc which point to the direction of highly-assisted / autonomous AI training as the future. Wild.
Lots of emoji in that readme. Was it mainly codex?
Mainly Fable, but It was me who wanted to emojis added hah. I also of course edited the README by hand (crazy I know), but the code is entirely fable
why...?
I guess we found the target audience for models that slather READMEs in emojis.
The thing we must keep in mind with any of the AI-slop style writing is that it was reinforced behavior because humans wanted it.
“The Anthropic team for their incredible coding models (Fable-5 wrote every line of code in this project), and the Claude Code harness.” Source: the repo
What is RL?
Reinforcement Learning.
No idea why you got downvoted into oblivion with the context post. Cool idea!
Because HN detects AI comments and automatically makes them dead. I vouched for it as it's important for this post as context.
Thank you!
Can you explain how it works?
What problems would it do well on and why?
Where would it start to fail/break?
What are the limitations of a system like this?
When you vibe code a system in a complex area like RL, you basically have zero understanding of what its actually doing, whether its actually any good or not, what you're actually benchmarking, and when the system would fail.
It's the blind leading the blind.
I chose the key technical decision and direction (such as the system architecture, the tasks to train on, the stack of Tinker, Prime-RL & Runpod - all of which I know well) etc.
The problems it would do well on are training small agentic (multi-turn, tool use) task based models using the prime-rl stack, which are close to the distribution trained upon. It would likely not transfer to other training frameworks such as SLIME, ART or ROLL, it would also likely not transfer well to RL for complex agents such as coding agents etc.
It is limited due to its scale. As a single person, the resources required to train this on a more diverse dataset, with more complex tasks on a larger variety of models, is outside my abilities! I believe there are many avenues to explore to improve performance for this to be genuinely valuable. For now, this just a proof of concept to show the possible.
I would like to think I have a good understanding of RL, evaluations, and agentic systems after a few years of working on these areas. However, I will always have gaps. I use Fable to help accelerate me, and fill those gaps at the same time, from which I can learn from too.
I think the counter point for these projects is that you may not need a deep understanding if you can measure the outcome. While this may not be true every time today, it plausibly will be in the future - making the activity worthwhile.
Yes I do agree with this. I believe we are shifting from "make the model good" (prompt/context engineering, etc) to "define good for the model" (success criteria/rubrics). Over time I believe this will become increasingly obvious (as long as model capabilities continue to increase).
Well, you say that, but when "measuring" anything in RL, that measurement itself is not always obvious.
That is, creating the scoring system/judge models etc for RL is not easy at all. You can easily create an RL loop which is getting better and improving its scores, but actually the result is totally garbage, because you're measuring the wrong thing.
What do you see wrong with the OPs reward design?
Did you read the README?
The AI generated README?
I RL-trained an agent whose job is to write RL training jobs for smaller models, and open-sourced the whole thing.
The setup is two nested RL loops:
- Outer loop: the trainer agent (Qwen3.6-35B-A3B, LoRA) is handed a task spec ("teach a small model to do X"). It works in a sandboxed workspace with file tools and writes a complete prime-rl training job: a verifiers environment + rubric, a dataset, and a hyperparameter config. Submitting triggers a validation probe with capped retries. - Inner loop: each validated job is dispatched to a warm pool of up to 16 Runpod GPU pods, where prime-rl GRPO-trains a small Qwen (0.6B or 1.7B). The checkpoint is scored pre/post on a hidden eval the agent never sees. - The inner model's improvement flows back up as the outer loop's reward (plus a validation-efficiency term and a small train-speed tie-breaker). The outer loop is tinker-cookbook's importance-sampling GRPO, run async off-policy so one slow episode doesn't stall a batch.
Results, over 54 outer-loop steps (~1,750 real GPU training jobs):
- Episode reward went from ~0.0 to a ~0.63 peak. - Learning came in two distinct rungs: first "stop failing validation and dying on GPUs", then "make better models". GRPO took the steepest gradient first — the entire early gain was process reliability, and only once that saturated did the hidden-eval scores of the trained models start climbing. - It transferred to a held-out task family that the agent never trained on: mean reward 0.399 untrained → 0.545 at step 34, easing to 0.49 by step 54 (n=10 per arm, so noisy — a rise then a plateau/dip). - The agent learned to stop picking the weaker 0.6B base model (1.7B share of its jobs: 42% → 95%) and started actually using the hyperparameter surface (21% → ~78% of episodes).
Cost: the headline arc was ~$1.3k all-in (~$810 Runpod, ~$465 Tinker). Each inner training job cost ~$0.13–0.30 — a benchmark matrix over GPU × base-model picked cheap pairs (mostly A40s in practice, since the cost-winner was rarely in stock).
Two honesty notes: the outer loop runs through Tinker's managed API rather than local GPUs — the inner loop is all open-source stack on rented pods. And ~$1.3k is the headline arc, not the project; the pilots and blind alleys that got me there cost a few hundred more, and every one of them is written up in the retros in the repo, including the failures.
I did this because I think agents that improve other AI systems are going to be a big part of the next few years, and I wanted to know what it actually takes to get the reward moving. Turns out: way more debugging of the process than the policy, and it's all more accessible than it looks.
Happy to answer questions about the reward design, the GPU orchestration, or the things that didn't work.