In one coding-agent training setup, learner GPUs sat idle for 49.5% of each step while they waited for the slowest task. ThunderSync RL reported 1.91 times baseline throughput by processing completed work sooner.
That result says something specific about training. The other tests in the script measure different things: how quickly a model writes tokens, whether it finishes coding tasks, how much memory it needs, and how many tokens it uses for a job. Those numbers answer different questions.
The Slowest Agent Kept the GPUs Waiting
A coding agent may edit code, run tests, fail, and try again. In the paper’s setup, the learner GPUs waited for the slowest of those trajectories before processing the batch. Even when other trajectories had finished, their results sat waiting too.
ThunderSync RL changes when that work enters processing. It starts on each trajectory as soon as its test reward arrives, while still waiting for the full batch before updating the model’s weights. The authors describe the result as equivalent to synchronous batch training.
On eight B200 GPUs running the 27 billion parameter Qwen 3.8, the paper reports 1.91 times the baseline GRPO throughput. It also reports reaching its stated SWE-bench Verified target in 121.3 GPU hours instead of 233.5.
The extra throughput came with higher memory use. Peak memory per learner GPU went from 117.0 GB to as much as 122.8 GB. The test used one eight-GPU node, so its performance at larger scale remains open.
Flint Wrote Quickly, but Missed the Harder Runs
Recursive says Flint writes more than 125 tokens a second on an M4 Pro MacBook Pro. The model stores about 40 billion weights but uses about two and a half billion for each token. Reading fewer weights helps it write quickly, though the full set still has to fit somewhere.
An independent test on an RTX 5090 measured 145.7 tokens a second and about 27 GB of memory use. Across six coding tasks, Flint passed 12 of 18 runs. All six failures came from two harder tasks.
That is fast writing in the RTX 5090 test, alongside an incomplete task result. The token rate says how quickly Flint produced output. The pass count says what happened when that output had to solve the coding tasks.
Another setup shows how much the hardware arrangement can matter. Anthropic’s Frontier Red Team spread Gemma 4 across 15 Android TV boxes costing about $55 each and got 0.39 tokens a second. Anthropic says 14 boxes sit idle while one works. Fitting the model across the boxes did not make this setup fast.
K3 1 Pro Changed Places When the Test Changed
Moonshot’s Terminal Bench table puts Opus 5.5 ahead of K3 1 Pro by less than a point. Artificial Analysis used a different setup and favored K3 1 Pro at 67.2%. In these two tests, the setup changed which model came out ahead.
Artificial Analysis’s overall index adds another measure: 58 for Opus 5.5 at max and 55 for K3 1 Pro. The Terminal Bench result and the overall index should each be read as the result of its stated test.
Price needs the same care. K3 1 Pro’s input and output rates are half of Opus 5.5’s. Artificial Analysis also reports that K3 1 Pro used about 1.7 times the median model’s output tokens. That token figure compares K3 1 Pro with the median model, but it still shows why a rate per token alone cannot tell you the cost of a job.
The Clean Source Tag Was Not the Installed Release
LightLLM disclosed a distributed release containing credential-stealing malware. Its official source tag was clean, but the release contained malicious files. A team looking only at that tag could miss what its machine installed.
For an affected release, the investigation has to start with what actually executed. The next question is which credentials that code could reach. The clean source tag cannot answer either question on its own.