Coding agents learn to fix real bugs through reinforcement learning (RL): they read an issue, explore the repository, edit code and run tests, and they are rewarded when the fix holds. Results are improving fast, but the recipes behind them are hard to reproduce. New algorithms and data sets are often measured against baselines that were never fully tuned, much as claimed speedups over AdamW shrink once AdamW itself is tuned.

Snowflake AI Research is introducing Arctic-SWE, a fully asynchronous RL framework for software-engineering agents, built on Cortex-Training Backend Prime-RL. None of its components are new on their own; what has been missing is the foundation they form together. We found it by treating modeling and systems as one design problem, and checked it with a simple test: can the training pipeline overfit a small set of tasks and stay there?

A strong baseline also lets us ask the question, “What does better data add?” So we audited three public SWE data sets, filtered and repaired their tasks, and tested each change in runs where only the data differs. Here is what the two steps add up to:

• The recipe alone: 62.0% on SWE-bench Verified from unchanged R2E-Gym data. Arctic-SWE trains Qwen3.5-4B from 47.4% to 62.0% pass@1, comparable to concurrent FrogNano (61.5%), which synthesizes tasks online, after about one-sixth as many training rollouts.
• The data: Nearly a third of SWE training tasks accept a wrong patch. Filtering such tasks, or strengthening their tests, improves held-out accuracy in controlled comparisons.
• Recipe plus curated data: 65.0% / 38.3% at 4B and 65.7% / 39.6% at 9B on SWE-bench Verified / Pro, up from 47.4% / 25.0% and 56.2% / 31.9%.

Figure 1 puts the idea in one picture: first make the recipe fit a small pool of solvable tasks and hold it, then scale it.

Figure 1. Left: on 160 solvable R2E-Gym tasks, two public recipes adapted to our model and task pool crash or collapse, while Arctic-SWE fits the pool and holds it. Right: the same recipe on held-out SWE-bench Verified, first on unchanged R2E-Gym data and then with curated data. The 9B was trained on curated data only.

The stress test: If a pipeline can't overfit 160 tasks, don't trust it on 20,000

In supervised fine-tuning, a model that can't overfit a small training set points to a bug. RL for long agent tasks has no such routine check, and an early reward curve can hide a recipe that later loses what it learned. So we made overfitting our stress test: 160 R2E-Gym tasks that Qwen3.5-4B solves at least once in four attempts, trained for up to hundreds of epochs.

Two public recipes, adapted to our model and task pool, both climb to about 70% reward, and neither holds it (Figure 1, left). The asynchronous Prime-RL SWE example collapses by epoch 11. The synchronous SkyRL Mini-SWE example falls from 70% to 36% within two updates, then recovers.

This matters beyond the testbed. If a recipe keeps losing tasks it has already solved, it never gets to 100%, even on tasks it can solve. And a full data set still contains such tasks. More data or a bigger model won't fix a leaky recipe.

Fixing the feedback: Don't let the harness launder bad turns into reward

Gated reward: Harnesses often help a model past a malformed turn with a hint and let the rollout continue. If the rollout then succeeds, the invalid turns share its reward. We instead end a rollout at the first invalid format, duplicate tool call or exhausted budget, with zero reward, and require an explicit submission. Training climbs steadily to a 74.5% plateau, then starts to collapse at epoch 42 as format problems appear (Figure 2).

Raw format check: That gate checks each tool call after the parser has read it, and parsers are forgiving: they repair many malformed calls, which then run and can earn reward. When we fed 13 deliberately malformed tool calls through the training paths of four public RL frameworks, most still ran. So we also check the raw tokens the model produced. Training no longer collapses, but reward now holds around 80%. The rest was to fix the system.

Fixing the system: In async RL, the system is part of the optimizer

In synchronous RL, system efficiency only changes how fast training runs. In asynchronous RL, it also changes what the optimizer learns from, and three fixes mattered:

• Match the numerics: Qwen3.5 carries a recurrent state that is rewritten at every token, and by default the inference engine stores it at lower precision than the trainer. Keeping it in FP32 on both sides more than halves the disagreement between their token probabilities, at no cost in speed.
• Rebuild caches after every weight update: Otherwise a rollout that spans an update keeps generating from caches computed by the old weights. We recompute them, so every token comes from the current model.
• Place work by load: Our router pinned each rollout to one of six inference engines to reuse its cache, and one engine ended up with 186 requests while the others had eight. Work stuck behind it went stale and was thrown away. Sending work to the least-loaded engine cut discarded rollouts from 27 to under one per update and nearly halved the time per update, from 22 to 11.6 minutes.

Together, these fixes make up our full recipe, which fits the pool at about 96% and holds it (Figure 2).

Figure 2. Our fixes on the 160-task pool, one layer at a time. The first two lines are smoothed, with their raw values faint behind them.

The payoff: on par with concurrent work’s quality on raw data, with one-sixth the rollouts

On 3,606 R2E-Gym tasks with their original issues and tests, the full recipe trains Qwen3.5-4B from 47.4% to 62.0% on SWE-bench Verified pass@1 (mean success over four attempts) after 340 updates, on a single 8-GPU B200 node. The same checkpoint scores 38.3% on SWE-bench Pro. On the larger pool we add one thing: tasks the model solves on every attempt, or keeps failing at, are retired from training, so the budget goes to tasks that still teach it something.

Concurrent work, FrogNano, reports 61.5% on Verified and 37.6% on Pro with the same base model. Its central contribution is online task synthesis; trained on real tasks instead, its own recipe reaches 48.0–53.4%. FrogNano's training budget is 256,000 rollouts, and our best checkpoint came after 43,520. A solid recipe, before any data work, already reaches this level. One setting stood out on full data: length penalties lift the early peak, then collapse the run from 60.0% to 20.3% within 100 updates.

Fixing the data: A third of SWE training tasks accept a wrong patch

A good recipe can't fix a bad reward. Every SWE task has an issue, tests that compute the reward and a gold patch. Existing data sets check only that the tests fail before the gold patch and pass after it; they never ask whether the tests also accept a wrong fix. Take this issue from SWE-rebench, in full:

Its tests only check that a symbol named EnumType can be imported, so the one-line alias EnumType = EnumMeta, which renames nothing, passes all 20 of them.

We audited 21,099 tasks from R2E-Gym, SWE-rebench V2 and Scale-SWE. For each one, an agent powered by Qwen3.8-27B and given the gold patch, the tests and a shell tries to write a plausible wrong fix and runs the tests on it. Of the 17,861 tasks that pass standard validation, 5,351, nearly a third, reward such a wrong fix. Keeping only tasks whose issue, tests and gold patch agree, and rewriting the issue where it leaves out what the tests check, leaves 7,500.

Both repairs pay off in runs where only the data changes (Figure 3):

• Curation: Against 7,500 tasks that pass standard validation but fail our audit, matched in size and data set mix, the curated tasks lead at all five checkpoints, by 1.3 to 7.5 points.
• Stronger tests: Rather than drop the loose-test tasks, the same agent strengthened their tests, and we trained on 4,889 of them twice: once with the original tests and once with the stronger ones. The stronger tests win at every checkpoint, and after 200 steps they beat anything the original tests reach in 350. They also let the model "master" fewer tasks, solving every attempt on 29.0% of them by step 250 against 40.9%. With identical tasks, that gap is mastery that was never real: the original tests passed fixes that didn't fix the bug. The run that masters less transfers better.

Figure 3. Only the training data changes in each comparison. Left: the 7,500 curated tasks against 7,500 that pass standard validation but fail our audit, matched in size and data set mix. Right: the same 4,889 tasks, graded by their original or their strengthened tests.

Lock the doors: Agents will find the answer key

Weak tests are not the only way to earn reward without a fix. Training images usually ship the repository's full git history, so git log --all leads straight to the fix, and an open network offers the upstream patch. Under RL the shortcut spreads fast: in a 9B run without history pruning, the share of rollouts digging into the git history rose from about 5% to 99% within 200 steps. In an audit of 60 SWE-bench Pro trials, a Qwen3.8-27B agent took one of these shortcuts 19 times, lifting its score by 15 points. We remove the history and block the network for training and evaluation alike. A few SWE-bench Verified tasks can't be graded without the network, so we score a fixed 483-problem subset, and our numbers run lower than those measured without these controls.

Scaling up: Eviction hides forgetting

On the 7,500 curated tasks, the 4B peaks at 65.0% / 38.3% and the 9B at 65.7% / 39.6% on SWE-bench Verified / Pro (Figure 4).

Figure 4. SWE-bench Verified and Pro pass@1 of Qwen3.5 agents. Arctic-SWE and base-model scores use our harness under the isolation above; the others are as reported by their authors, with different scaffolds and budgets (FrogNano: Leaf; Dockerless: OpenHands), so the comparison is indicative rather than controlled. Three more agents report Verified only: Polar-4B (40.4), AxiaoDBL-4B (55.0) and AgentLightning-9B (56.4).

The 4B then declines, to 55.6% by step 450 (Figure 5, left), while its training reward barely moves. The training reward can't see why, because it counts every retired task as solved. Rescored with frozen weights, the 4B's mean reward on its retired tasks falls from 0.95 at step 350 to 0.85 at step 500, while the 9B's changes by at most 0.013 (Figure 5, right). Our hypothesis is capacity: the 4B can't keep a growing set of mastered tasks while it fits the hard remainder. Either way, long runs with eviction should keep rechecking what they retire.

Figure 5. Left: on the same curated tasks, the 4B peaks at step 250 and then declines, while the 9B keeps improving, then holds high. Right: tasks that each run had retired as mastered by step 350, rescored with frozen weights at steps 350 and 500.

What's next

Arctic-SWE doesn't claim that better algorithms, data or environments don't matter. It gives them a strong, documented baseline to be measured against, and we hope it helps other small teams train long-horizon agents in sandboxes. For this stage, we kept to one minimal harness, Mini-SWE-Agent-Plus. Future directions include training on production-grade harnesses such as our own Cortex Code, and scaling the recipe to larger mixture-of-experts base models. The paper has the full recipe, the ablations and their caveats.