Envs-FORGE Reaches 49.2% on Code by Rewriting Tasks, Not Models
Envs-FORGE improves Qwen 3.5 35B from 40.0% to 49.2% on tb-core by using a verifier to dynamically rewrite each training task's difficulty, not by scaling the model itself.
Why it earned a slot
The paper came out on August 14. Envs-FORGE does something almost nobody is doing: it treats the training environment as a first-class optimization target instead of a fixed recipe. Most RL systems for code agents use the same prompting strategy on every seed—few-shot, Self-Instruct, Evol-Instruct, whatever—and assume that if the policy is good enough, the task difficulty will sort itself out. Envs-FORGE inverts that. It estimates which seeds are close to the model's current capability boundary, then rewrites the instruction, test fixtures, oracle solution, and Docker environment for each one individually. The rewrite is chosen by solving a per-seed mixed-integer linear program. The results are concrete. On tb-core, the jump is from 40.0% to 49.2% on Qwen 3.5 35B. On tb-2.0, from 23.0% to 29.4%. The paper also reports 77.1% on SWE-bench Verified versus 73.4% for the baseline. All of this happens at the same operational scale—2.27M to 2.88M synthesis tokens across all methods, so you're not buying the win by spending 10x more on generation. I think this matters because it's a direct attack on a real bottleneck in agent RL: most papers assume the environment is solved, the model is the variable. But in practice, if your task is too easy, the agent learns nothing useful. If it's too hard, the agent fails and the trajectory is wasted. The crossover point is different for every seed and every checkpoint. Fixed recipes can't find it. Envs-FORGE can. The mechanism is also worth noting. It's not magic—it's a verifier that measures seed pass rates, then scores six different rewriting actions (harder, easier, different framing, etc.) and picks the one that drives the seed toward a target learning frontier. The MILP is just a way to formalize the tradeoff between bringing seeds to the frontier and maintaining soft skill coverage across the portfolio. That's engineering, not luck. What I don't know: whether the improvement holds on domains outside code. The paper tests on code benchmarks; it's not clear if the same approach works for reasoning, tool use, or embodied tasks where the environment semantics are totally different. I also can't tell if the verifier itself is the constraint—if you're running a verifier on every candidate task rewrite, you're burning cycles that might be better spent on forward passes. The other thing that's unclear is deployment latency. The paper measures end-to-end training improvement, which is real. But if you're running this in production—where you want to train once and ship—the per-seed MILP solve might be a deal-breaker. I'd want to see the wall-clock breakdown. But the core claim is solid and specific: you can squeeze more capability out of a fixed-size model by optimizing the task distribution, not the model weights. That's a different variable than everyone else is turning. On 35B parameters, it buys you 9.2 points on a real benchmark. That's the kind of result that changes what people optimize for.