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.
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.
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.
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.