FireFlash Opens the Recipe for Long-Horizon Agentic RL
By Mr.Xu Community Post
Published:
Summary:The FireFlash team has published an open recipe for training long-horizon terminal and coding agents around a 300B-scale model. The system reportedly reaches 46.2% on Terminal-Bench 4.0 and was trained in under five days on 64 NVIDIA B300 GPUs, according to the authors. They also report transferring the gains to DeepSWE v1.1 and SWE-Bench Pro Verified. The engineering contribution is broader than the benchmark scores: carefully curated agentic RL environments provide reliable learning signals,
FireFlash Brings Long-Horizon Agentic RL to a Hundred-GPU-Scale Workflow
The FireFlash team has published a reinforcement-learning recipe for long-horizon terminal and coding agents. According to the authors, its 300B-scale model reaches 46.2% on Terminal-Bench 4.0, comparable to Fable 5 and GPT-6 Sol. The training run reportedly took less than five days on 64 NVIDIA B300 GPUs, while costing more than 30 times less per task than Fable 5 at maximum inference effort.
The central contribution is not simply a larger model. It is a redesigned agentic RL loop in which tasks produce reliable rewards at an appropriate difficulty, long-running rollouts can become stale or run at reduced precision, and training and evaluation share a coding harness optimized for the model.
Three Components of the Training Loop
1. Curating Agentic Environments for Reliable Learning Signals
The first challenge in long-horizon RL is environment quality. If a task is too easy, it provides little learning signal. If it is too difficult, failures may originate from broken tooling, nondeterministic containers, or faulty tests rather than from the policy. FireFlash focuses on selecting agentic tasks that consistently yield useful rewards without making the environment itself the dominant source of noise.
This extends reward design into environment supply-chain management. Reproducible rewards, deterministic state resets, correct attribution of tool failures, and consistent results across randomized configurations all become essential for long-horizon credit assignment.
2. Handling Long, Stale, and Low-Precision Rollouts
FireFlash treats rollout handling as part of the recipe rather than as an implementation detail. Long agent trajectories may run for minutes or longer, while generation, tool execution, and reward computation cannot always be fully synchronized. A trajectory may also become stale if the policy changes before it finishes and is verified.
Discarding stale samples wastes expensive long-running computation, while accepting every sample can introduce behavior produced by an outdated policy. Low-precision rollouts reduce memory and bandwidth pressure during large-scale generation, but they can amplify gradient noise when rewards are sensitive to small errors.
The available summary does not explain how stale trajectories are corrected, whether importance sampling is used, or which numerical-precision settings are applied. Those details will be essential for assessing training stability and reproducibility.
3. A Model-Specific Coding Harness for Training and Evaluation
FireFlash also uses a customized coding harness so that training and evaluation share the same tool protocol, terminal abstraction, context organization, and completion criteria. This reduces train–deployment mismatch: the model learns a stable tool-call format, error-handling pattern, and output contract that carries directly into evaluation.
The harness can also influence measured capability. Lenient reward checks may reward test exploitation, while overly strict checks may classify environment defects as model failures. A sound evaluation should therefore include executable patch rates, test contamination checks, retry counts, and performance on unseen tools and repositories.
Interpreting the Benchmark Claims
The authors report a 46.2% score on Terminal-Bench 4.0 and transfer to DeepSWE v1.1 and SWE-Bench Pro Verified. These results suggest that the recipe was not optimized for a single terminal setup, but the public information is still insufficient for a rigorous apples-to-apples comparison.
The model architecture, active parameter count, context length, and inference budget are not disclosed. Whether “300B-scale” refers to total or active parameters materially affects deployment memory and serving cost. Per-task cost must also account for failed retries, tool services, code-execution sandboxes, context caching, and evaluation orchestration rather than comparing model API invoices alone. Finally, train-set leakage, shared task templates, and common prompt or test infrastructure could inflate benchmark results.
A stronger validation would rerun baselines under identical inference budgets and tool permissions, break performance down by task difficulty, report tool steps, retry rates, and timeout rates, and evaluate on unseen repositories and heterogeneous tool interfaces.
Practical Value for Developers
The most useful part of FireFlash is the end-to-end recipe: environment preparation, rollout generation, reward verification, policy updates, and evaluation. Teams can adapt the structure to their own domains while preserving the principles for long-horizon agent training. Even without reproducing the 300B-scale run, smaller experiments can test difficulty calibration, asynchronous reward handling, stale-trajectory treatment, and unified harnesses.
The recipe is not yet equivalent to low-cost reproduction. Sixty-four B300 GPUs remain a substantial resource, and a 300B-scale MoE model would add routing, expert-parallel communication, and checkpoint-I/O pressure. Open weights are also still forthcoming. Until the weights, data, environment definitions, and training scripts are available, FireFlash is best viewed as a technically promising long-horizon agentic RL recipe that still requires independent validation.
— END —Source: Reddit r/LocalLLaMA (2026-11-05)
Tags: #FireFlash #Agentic Reinforcement Learning #Long-Horizon Agents #Coding Agents #MoE
Editorial & Fact-Checking Note: This article is compiled from primary research, official release documentation, and source papers by the ZICQ Newsroom pipeline with automated entity verification and human editorial review. If you notice any technical inaccuracy, please submit a correction via our corrections policy or email our editorial desk directly.
Community Comments