Alibaba's QwenGyre: Elastic RL for XLong-Horizon Agent Training, 1.85x Faster

If 2025 was the year of the "agent model," the second half of 2026 is becoming the year of the infrastructure that trains agents. On October 12, Alibaba's Qwen team announced QwenGyre on its official X account — an elastic online reinforcement learning framework for extreme-long-horizon (XLong) agent training. Its goal is concrete: make agent rollouts that run for hours and burn close to a million tokens trainable without "waiting for the slowest one."

This story deserves a full piece not just because the numbers are striking (48 training steps on Qwen 3.8 2.4T cut from 134.55 hours to 75.42 hours, up to 1.85x end-to-end speedup), but because it echoes the Anthropic Scion piece we published two days ago: the frontier of agent quality is moving from the model itself to the harness and the training loop around it. Anthropic is building source-level controllable harnesses for RL training; Alibaba is making GPUs follow long-running work elastically. Two top teams putting "training infrastructure" on stage in the same week is no coincidence — it's the signal that the second half of the agent arms race has begun.

Why XLong is hard: a single rollout runs for hours

First, the scale, because every design in QwenGyre is forced by it. The paper defines "XLong-horizon" as single agent executions spanning hours, hundreds of model-environment interactions, and nearly 1M tokens per rollout. A canonical example: generating an entire code repository from a spec (tasks like NL2Repo-Bench).

At this scale, conventional online RL training pipelines hit two walls at once:

• Huge execution variance leaves GPUs idle. On the 122B Qwen 3.6, a single rollout averaged 1.93 hours and a single query 2.96 hours; on the 2.4-trillion-parameter Qwen 3.8 2.4T, 61.1% of queries with complete duration records ran for over 4 hours. Training can only wait while the slowest task finishes.
• Branching executions generate massive redundant trajectories. Modern agent harnesses (Claude Code, for example) compact context, spawn sub-agents, and retry on failure — one execution becomes a branching tree, not a straight line. Expanding every path into training samples recomputes shared prefixes countless times, and training cost explodes.

The two standard industry setups each have an unsolvable knot. Colocate switches the entire GPU pool between "running rollouts" and "training": training is forever blocked by the slowest rollout. Async statically splits GPUs into two pools: one side idles while the other can't borrow its spare capacity. The paper puts it bluntly: under Colocate, training waits for the slowest execution; under Async, fixed pools leave both sides unable to lend idle capacity to each other.

In other words, the problem isn't too few GPUs — it's that the allocation is static, and static allocation is exactly what long-horizon tasks with huge duration variance punish most.

The Elastic Scheduler: hardware follows the work

QwenGyre's first core design, the Elastic Scheduler, can be summarized in one line: GPUs no longer have fixed roles assigned in advance; they flow in real time with unfinished work.

Concretely: the GPU cluster is divided into "cells," each sharing the same training layout and able to independently serve rollouts or host a complete training replica. One core cell holds the authoritative weights and optimizer state; satellite cells join training later. The scheduler continuously tracks a "rollout waterlevel" — queued plus running executions — and switches freed cells to training once the remaining cells can still serve all live work.

The key engineering detail: live agent executions are never interrupted during a switch. Model calls are rerouted through a proxy to engines still serving rollouts, and the harness itself notices nothing; KV-cache blocks migrate over RDMA to avoid prefix recomputation. Satellite cells pull the authoritative weights from the core cell through Mooncake's Transfer Engine and join an ongoing data-parallel training batch — no restart from scratch. Combined with streaming training (cells claim micro-steps as data becomes ready), group progress stays synchronized across the cluster.

How fast is a switch? The paper's measured numbers: 8.5 seconds on average from rollout to training, 3.5 seconds back. Against rollouts lasting hours, that overhead is essentially negligible — and that's precisely the premise that makes elastic scheduling work in the XLong regime. If tasks ran for minutes, an 8.5-second switching tax would hurt; when tasks run for hours, the tax rounds to zero.

The diagram below sketches QwenGyre's two core designs (homemade, all numbers per the paper):

QwenGyre's two core designs: the Elastic Scheduler (left) flows GPU cells between rollout execution (SGLang) and training (Megatron) on demand, with role switches taking seconds; the Trajectory Processor (right) converges branching execution trajectories into bounded training samples. Diagram: homemade from the paper.

The Trajectory Processor: compressing a tree into bounded training samples

The second core design, the Trajectory Processor, attacks the other wall: branch explosion.

Its premise is refreshingly pragmatic: don't touch the agent's black-box harness. Every experiment in the paper ran on unmodified Claude Code 2.1.220 — the training framework leaves the agent's "cockpit" alone and adds a proxy around it. The proxy records exact token IDs and behavior log-probabilities for every model call via token-in/token-out (TITO). All calls are stored as prefix-shared trajectory trees: repeated prefixes are stored once, killing redundancy at the root.

Then come four processing rules, each answering "what in this tree is worth training on":

• Partial scoring: timed-out executions aren't scored zero — they're scored on their preserved workspace; samples where the evaluator itself failed are excluded entirely, never recorded as zero reward. This matters: in long-horizon tasks, "almost finished" and "did nothing" carry vastly different training signals.
• Bounded sampling: at most 5 trajectories are kept per execution, ranked main > main-summary > sub-agent > sub-agent-summary. The paper's experiments show a cap of 5 matches uncapped training scores while cutting forward-backward time by 25.2%.
• Deduplication: shared targets count once, and only tokens generated by the policy itself are trained — harness-injected templates and tool outputs don't get gradients.
• Fair weighting: losses are averaged within each execution, so executions with more branches don't inflate their weight just by having more samples.

Training uses an adapted GSPO with 16 rollouts per group. None of these details is glamorous on its own, but together they answer a very concrete question: when one agent execution produces a tree instead of a line, what should the RL training data pipeline look like? QwenGyre's answer: let the tree grow, but only bounded, deduplicated, fairly-weighted samples ever reach training.

The numbers: 48 steps on 2.4T, 134.55 hours → 75.42 hours

The paper's measured results. All comparisons use equal GPU budgets and matched staleness, with Claude Code 2.1.220 as the harness throughout:

• NL2RepoBench (Qwen 3.6 122B, 48 steps): 1.42x–1.53x vs Async, 1.36x–1.47x vs Colocate.
• DeepSWE (Qwen 3.6 122B, 24 steps): 1.569x–1.572x vs Async, 1.610x–1.824x vs Colocate.
• TerminalBench (Qwen 3.6 122B, 24 steps): 1.383x–1.430x vs Async, 1.809x–1.849x vs Colocate — the headline 1.85x appears here.
• NL2RepoBench (Qwen 3.8 2.4T, 48 steps): 1.78x vs Async, 1.21x vs Colocate. Absolute times: QwenGyre 75.42 hours, Colocate 91.47 hours, Async 134.55 hours.

Note the 2.4T row: just 1.21x over Colocate, the lowest in the table. The paper doesn't hide it — MarkTechPost's reading is that on 2.4T, many queries ran near the timeout, and the execution-variance structure itself compressed the room elastic scheduling had to maneuver. An honest footnote: the upside of elastic scheduling is bounded by the structure of task-duration variance, not unlimited.

The quality side has numbers too: Qwen 3.8 2.4T's NL2RepoBench pass rate rose from 52.48% to 58.54% — a +6.0 percentage-point absolute gain in 48 steps. In other words, the speedup didn't cost score: "at matched scores" is the premise behind every speedup in the paper.

On scale: the 122B runs used 24–32 nodes; the 2.4T run used 192 nodes (4 cells of 48). Megatron trains, SGLang serves rollouts. The paper does not disclose the GPU model — the one missing piece of hardware information.

Side-by-side: agentic RL frameworks are already a multi-front war

QwenGyre wasn't published in a vacuum. Placing it next to the three other mainstream agentic RL frameworks is revealing:

• veRL (ByteDance Seed + community, Apache-2.0): flexible device mapping, HybridEngine resharding, open source.
• AReaL (Tsinghua IIIS + Ant Group, Apache-2.0): fully asynchronous, black-box harness support (base_url swap), open source.
• Agent Lightning (Microsoft, MIT): near-zero-code-change black-box harness, open source.
• QwenGyre (Alibaba Token Hub + USTC + Tsinghua): elastic mid-rollout cell switching + proxy black-box; license and code-release status undisclosed.

A few judgments: first, three of the four are open source — QwenGyre is the exception, which is currently its biggest weakness and the only obstacle to the community verifying its numbers. Second, Chinese teams hold three of the four seats (ByteDance, Alibaba, Ant + Tsinghua) — in the agent-training-framework race, Chinese teams are already de facto lead players. Third, every speedup comes from its own experimental setup and the numbers aren't directly comparable — but the direction is consensus: nobody believes static allocation can feed long-horizon agent training anymore.

On the record: the "open source" discrepancy

One discrepancy must be stated plainly: some outlets (StartupFortune) headlined "open sources QwenGyre," but the paper page links no public code, and MarkTechPost explicitly notes the paper links no public code release. So the accurate statement is: Alibaba released the QwenGyre framework and paper; whether the code is public is currently unclear. We won't write "open-sourced" just because a headline did.

Two more sourcing notes: the news date is October 12, the day of Qwen's official X announcement (the paper itself went up on arXiv September 27 as arXiv:2609.33848); the original X post couldn't be opened directly due to domain restrictions, but its copy and date were cross-verified across multiple October 12/13 reports. And a side data point: the experiments ran on Qwen 3.8 2.4T (A95B active) — indirect confirmation that the Qwen 3.8 family exists.

Why this matters to vibe coders

A final word on "what does this have to do with me." Frameworks like QwenGyre will never appear in your toolbar, but they decide whether the coding agent you use every day can chew through "a task that runs for hours." Today's Claude Code and Codex handle tens-of-minutes tasks; the next generation — "drop a spec Friday evening, collect a repo Monday morning" — is bottlenecked not on model smarts but on the cost of training long-horizon behavior itself, which is exactly what QwenGyre compresses.

The more direct lesson is methodological: when you run agents on long tasks or big refactors in your own projects, remember the paper's two truths — long-tail tasks eat your entire parallel budget (the slowest one decides everything), and most tokens in branching trajectories are duplicates (prefix dedup is always first principles). QwenGyre solves this with 192 nodes, but the diagnosis holds just as well on your single machine.

The agent arms race: the first half was about "how smart the model is"; the second half is about "how cheap training is and how controllable the harness is." QwenGyre and Scion landing in the same week means the second half has kicked off.