QwenGyre Explained: How Alibaba Qwen Trains AI Agents That Work for Hours
Alibaba's Qwen team has published QwenGyre, a training framework built for long-horizon agents, meaning AI agents whose single task can run for hours. The problem it addresses has a name: xlong-horizon work, meaning one execution that spans several hours, hundreds of interactions with tools and environments, and close to a million tokens. Training long-horizon agents on work like that is where the hard engineering sits, because the usual reinforcement learning setup starts to fall apart when a single attempt takes longer than the training step waiting for it. QwenGyre is the team's answer, a form of elastic RL in which the hardware follows the work instead of being fixed in advance.
The short answer
QwenGyre is not a model. It is a training system, the machinery that surrounds a model while that model learns to finish long jobs. According to the paper's abstract, QwenGyre was scaled to Qwen 3.8 2.4T and produced a 6.0 percentage point gain on NL2RepoBench, from 52.5 percent to 58.5 percent, in 48 training steps, with reported speedups of up to 1.85 times over the Colocate baseline and 1.78 times over the Async baseline.
If you use AI tools rather than train them, the practical meaning is simple. The frontier of agent quality is moving from the model alone to the harness and the training loop around it, and frameworks like this one are part of why agents keep getting better at long, multi-step work.
Why agents that run for hours break normal RL
Reinforcement learning for long-horizon agents works roughly like this. The model takes actions, the environment responds, and a reward arrives at the end to tell the model whether the attempt was any good. Short tasks keep this loop tight. An agent that spends two minutes on a job can be trained on thousands of attempts per day.
Stretch the same loop to multi-hour work and two specific problems appear.
Problem one, the long tail of rollouts. Execution times vary wildly between attempts. The training step cannot proceed until enough rollouts have returned, so the fastest configuration leaves GPUs idle while it waits for the slowest execution. Splitting rollout and training into separate pools helps, but fixed pools cannot lend spare capacity to each other, so one side sits idle while the other is overloaded.
Problem two, branching histories. Modern coding harnesses do not follow a straight line. They compact context, spawn sub-agents, and retry failed steps. Context management of this kind is the same problem we examined in Claude's long context window, now applied inside a training loop. One execution therefore becomes a tree of attempts rather than a single trajectory. Expanding every branch for training duplicates the shared prefix over and over, which inflates the cost of training without adding information.
QwenGyre attacks both, and each one gets its own subsystem.
Idea one: the QwenGyre elastic scheduler that never lets GPUs sit idle
QwenGyre divides the cluster into cells that share one training layout. Any cell can either serve rollouts or host a complete training replica. One core cell owns the authoritative weights and optimizer state, and satellite cells join training later, mid-batch.
The QwenGyre scheduler tracks what the write-up calls a rollout waterlevel, meaning the queued and running executions. As executions finish, cells switch over to training, but only once the cells that remain can still serve all the live work. Model calls are rerouted through a proxy so running agents never notice that the hardware underneath them changed.
Three mechanics make the switch cheap rather than disruptive:
- KV-cache migration. Cache blocks move between cells over RDMA, which avoids recomputing the shared prefixes of long conversations.
- Weight transfer. Satellite cells pull the current weights through Mooncake's Transfer Engine and join the batch already in progress.
- Streaming training. Cells claim micro-steps as data becomes ready instead of waiting for a full synchronized batch.
The reported cost of a role change is small in context, at an average of 8.52 seconds to move from rollout to training and 3.46 seconds to move back. Over a run measured in hours, those switches are noise.
Idea two: the QwenGyre trajectory processor that stops paying twice for the same path
The second QwenGyre subsystem deals with the branching problem. A proxy records every call in token-in, token-out form, capturing exact token identifiers and the behaviour log-probabilities that training needs, and stores the calls as prefix-shared trajectory trees.
Four design choices follow from that structure.
- Partial scoring. An execution that hits the timeout is still scored on the workspace it preserved. Evaluator failures are excluded rather than counted as a zero reward, which prevents a broken grader from teaching the model that a good attempt was bad.
- Bounded sampling. At most five trajectories are kept per execution, ranked in the order main, main-summary, sub-agent, sub-agent-summary.
- Deduplication. Shared targets are counted once, and only tokens generated by the policy itself are trained on.
- Fair weighting. Losses are averaged within each execution, so an execution that spawned many branches does not gain extra influence over the update.
The cap is the part worth remembering. According to the write-up, keeping five trajectories matched the training quality of keeping all of them while cutting forward and backward time by 25.2 percent. QwenGyre's training uses an adapted GSPO with 16 rollouts per group, which belongs to the same family of group-based policy optimisation behind the GRPO training in the NVIDIA Polar experiment we covered earlier.
What the benchmarks actually show
All runs used Claude Code 2.1.220 as the harness, with equal GPU budgets and matched staleness across the compared setups. The headline speedups vary considerably by workload.
| Workload | Model | Versus Async | Versus Colocate |
|---|---|---|---|
| NL2RepoBench, 48 steps | Qwen 3.6 122B | 1.42x to 1.53x | 1.36x to 1.47x |
| DeepSWE, 24 steps | Qwen 3.6 122B | 1.569x to 1.572x | 1.610x to 1.824x |
| TerminalBench, 24 steps | Qwen 3.6 122B | 1.383x to 1.430x | 1.809x to 1.849x |
| NL2RepoBench, 48 steps | Qwen 3.8 2.4T | 1.78x | 1.21x |
The weak spot is visible in the last row. On the largest model, where many queries ran near the timeout, the gain over Colocate falls to 1.21 times. The 1.85 times figure in the marketing comes from TerminalBench on the smaller model, and it is a ceiling rather than a typical result.
Wall clock tells a clearer story for the flagship run. Forty-eight steps took 75.42 hours with QwenGyre, against 134.55 hours on the Async setup and 91.47 hours on Colocate.
Where the evidence stops
Several things are worth stating plainly rather than smoothing over.
- It is a preprint. The paper was submitted on 27 September 2026 and has not been peer reviewed.
- The numbers are vendor run. The source write-up itself notes that speedups from different projects are not directly comparable, because each uses its own setup.
- One harness was tested. Every run used Claude Code 2.1.220. Whether the same gains hold with a different harness is untested in the published material.
- Hardware disclosure is thin. Node counts are given, at 24 to 32 nodes for the 122B runs and 192 nodes in four cells of 48 for the flagship run, but the GPU model is not disclosed.
- Code availability is unresolved. The paper listing shows no linked repository and no disclosed license, and the source write-up states that the paper links to no public code release. One other outlet has described QwenGyre as open sourced. Those two claims cannot both be correct as written, so treat the release status as to be verified before you plan anything around it.
How to read an agent training benchmark
Numbers like these travel as marketing, so it helps to carry a reusable set of questions. Applied to QwenGyre, they show what the work does well and where a reader should stay skeptical.
What was held constant? The runs matched GPU budgets and staleness across the compared setups, and every one of them used the same harness, Claude Code 2.1.220. That is more control than many training reports offer, and it also bounds the claim, because nothing here proves the gain survives a different harness.
Is the speedup end to end or per component? QwenGyre reports wall clock for the whole schedule, at 75.42 hours against 134.55 hours for the Async baseline on the flagship run. A component figure, such as the 25.2 percent cut in forward and backward time from the trajectory cap, is a narrower claim and should not be added to the end to end number.
Which workload produced the headline? The best published figure, 1.85 times over Colocate, comes from TerminalBench on the smaller model. The largest model managed 1.21 times, because many of its queries ran close to the timeout. A single headline hides that spread, and the spread is the honest part.
Do the scores hold while the clock improves? Speed without quality is worthless. Here the score moved in the right direction, with NL2RepoBench rising from 52.5 to 58.5 percent over the same 48 steps, which is what makes the scheduling claim interesting rather than merely fast.
Does the benchmark resemble your own work? Every result depends on a third party coding harness and on repository level tasks of the kind NL2RepoBench measures, where a model builds a working project from a specification. That is a structured and checkable class of work, and performance on it does not automatically transfer to the looser requests most teams put in front of an agent. A team running a different framework, or a different class of task, should treat these numbers as a hypothesis about its own stack rather than a promise.
Can you reproduce it? The paper lists no public repository and no license, so the release status remains open. Until that changes, the practical options are to wait for independent replication or to adopt the ideas when they surface in frameworks you can already install.
Used this way, a training paper becomes a checklist instead of a claim. The strongest signal in the QwenGyre work is not the top speedup figure, which belongs to one workload on one model, but the fact that the framework treats GPU idling and trajectory redundancy as first class problems. Both problems are real for anyone training long-horizon agents, and the fixes outlive the benchmark table. A year from now these specific speedups will look modest next to whatever hardware and frameworks have arrived, while the scheduling idea is likely to have been absorbed into the tools that train agents. That is the usual fate of infrastructure work, and it is a compliment rather than a criticism.
How it compares with other agentic RL frameworks
QwenGyre is not the only framework aimed at training agents with long trajectories. The ones most often named in the same conversation take different approaches to the same bottleneck.
| Framework | Developer | License | Black-box harness support | Public code |
|---|---|---|---|---|
| QwenGyre | Alibaba Qwen | Not disclosed | Yes, through a proxy | Not disclosed |
| veRL | ByteDance Seed and community | Apache-2.0 | Not disclosed | Yes |
| AReaL | Tsinghua IIIS and Ant Group | Apache-2.0 | Yes, by swapping the base URL | Yes |
| Agent Lightning | Microsoft | MIT | Yes, with near-zero code change | Yes |
Each project reports speedups against its own baseline, so the numbers in those columns should not be compared side by side. What the table does show is a pattern: black-box harness support has become table stakes, and elastic GPU placement is QwenGyre's distinguishing bet.
What this means if you use AI tools
You will not install QwenGyre, and it is not a product. Three consequences still reach you.
Agents that work for hours are becoming normal. Once the training loop can handle multi-hour executions, the products built on top can attempt longer jobs without the economics collapsing. Expect more tools that promise to finish a task rather than start it, in the way that browser agents already handle multi-step online work.
Training efficiency is now a competitive feature. The interesting research has moved from model architecture to the loop around the model: how rollouts are scheduled, how branching is scored, how much of the work is wasted. That is where the next round of capability gains is likely to come from.
The frontier stays expensive. A 192 node run for 48 training steps is not a weekend project. Progress at this scale concentrates in a handful of labs, while everyone else inherits the results through hosted models and open weights.
What to watch next
- A code or weights release, together with a license that says what you are allowed to do with it.
- Independent replication, particularly on smaller clusters, since the elastic scheduler is exactly the kind of idea that should help there too.
- Evidence from other harnesses than Claude Code, which is the largest open question in the current results.
- Whether QwenGyre's elastic scheduling shows up in the other frameworks, since that is the point where a paper stops being a paper and becomes a default.
FAQ
Is QwenGyre a model I can download?
No. It is a training framework, not a model. What it produces is a better trained model, and the models mentioned in the paper belong to Qwen's own line.
What does elastic mean in this context?
In QwenGyre, the GPU allocation is not fixed for the duration of a run. Cells move between serving rollouts and running training as demand shifts, so capacity follows the work instead of being locked in advance.
Does this change what I can do with AI today?
Not directly, because nothing here is a product you can turn on. The indirect effect is that long, multi-step agent tasks should keep getting better and cheaper to produce, which shows up in the tools you already use.
Why does a cap of five trajectories matter so much?
Because branching is where long-horizon training quietly wastes money. Every duplicated prefix costs compute and teaches the model nothing new. Bounding the sample while keeping quality is the difference between a training run that finishes and one that does not.
The short version
QwenGyre trains long-horizon agents on tasks that run for hours, and it does so with two ideas: move GPUs between rollout and training without stopping live agents, and turn branching histories into a bounded, deduplicated set of training samples. The reported results, a 6.0 percentage point gain on NL2RepoBench and speedups between 1.21 and 1.85 times depending on workload, come from a preprint with vendor run benchmarks, a single coding harness, and an unresolved question about whether the code will be released at all.
It is worth following for one reason. It shows where agent progress now comes from: not just a bigger model, but a better loop around it.
Sources
- QwenGyre paper, arXiv:2609.33848, submitted 27 September 2026: https://arxiv.org/abs/2609.33848
- Qwen announcement post: https://x.com/Alibaba_Qwen/status/2109633085658808515
- Technical write-up and benchmark tables on Marktechpost: https://www.marktechpost.com/2026/10/12/alibaba-qwen-introduces-qwengyre-elastic-reinforcement-learning-rl-for-xlong-horizon-agents/