GLM-5: from Vibe Coding to Agentic Engineering

🎯 Pitch

GLM-5 shows that decoupling action generation from model training in reinforcement learning lets AI agents learn from hours-long software engineering tasks without grinding to a halt. This asynchronous design, combined with a new sparse attention mechanism, produces an open-weight model that finally matches proprietary GPT-5.2 and Claude Opus 4.5 on real-world coding benchmarks like Vending Bench 2.

1. Executive Summary

This paper introduces GLM-5, a next-generation 744B-parameter Mixture-of-Experts foundation model that transitions from "vibe coding" to agentic engineering — a paradigm where AI agents autonomously plan, implement, and iterate on complex software tasks rather than requiring human prompting at each step. The model is evaluated across agentic, reasoning, and coding (ARC) benchmarks — including SWE-bench Verified, BrowseComp, Terminal-Bench 2.0, and Humanity's Last Exam — as well as a new internal long-horizon suite called CC-Bench-V2 that assesses frontend, backend, and chained multi-step development. The core technical innovations span three interconnected mechanisms: DeepSeek Sparse Attention (DSA) (a dynamic, content-aware sparse attention that replaces dense O(L²) computation with fine-grained token selection trained via continued pre-training from a dense checkpoint), a fully asynchronous agentic reinforcement learning infrastructure (decoupling rollout generation from training across separate GPU fleets with a central Multi-Task Rollout Orchestrator to eliminate synchronization bubbles during long-horizon agent trajectories), and new asynchronous Agent RL algorithms (employing a Token-in-Token-out gateway to preserve exact action-level correspondence and a Direct Double-sided Importance Sampling strategy with token-level clipping to stabilize off-policy training without tracking historical policy checkpoints). GLM-5 achieves state-of-the-art among open-weight models — scoring 50 on the Artificial Analysis Intelligence Index v4.0, reaching 77.8% on SWE-bench Verified, 75.9 on BrowseComp with context management, and $4,432 on Vending-Bench 2 — while demonstrating that test-time strategies can compensate for model scale, establishing that open-weight models can rival proprietary systems on complex real-world coding tasks only when the underlying base model possesses non-trivial capability on the target difficulty tier, as evidenced by GLM-5 remaining competitive with Claude Opus 4.5 on backend engineering and frontend check-item success rate yet still trailing on long-horizon chained tasks where errors compound across sequential commits.

2. Context and Motivation

The Core Problem: LLMs Are Stuck in "Vibe Coding" Mode

The central gap this paper addresses is deceptively simple to state but profound in its implications: current LLMs, even frontier ones, operate primarily in what the authors call "vibe coding" mode—a paradigm where a human developer prompts the model for each discrete coding action, inspects the output, and iterates manually. The model generates code reactively, one turn at a time, without maintaining coherent agency across extended workflows. This is fundamentally different from agentic engineering, where an AI system autonomously plans a multi-step development task, implements across multiple files and commits, debugs its own failures, and iterates toward a complete solution without continuous human intervention at each step.

This gap matters for several concrete reasons the paper highlights (Section 1, Introduction):

Real-world software engineering is inherently long-horizon. Fixing a bug in a production codebase rarely involves a single isolated edit. It requires navigating unfamiliar repositories to locate relevant files, understanding cross-file dependencies, making coordinated changes across multiple modules, writing and running tests, and iterating when tests fail—all while maintaining consistency across the codebase. Single-turn code generation benchmarks like HumanEval, while useful, capture almost none of this complexity.
The economic bottleneck is shifting from model capability to task endurance. As models become more capable at individual reasoning tasks (competitive math, short-form coding), the limiting factor becomes their ability to sustain coherent, goal-directed behavior over extended horizons. The paper frames this explicitly in Section 1: "Coding agents can now write code autonomously for hours, and the length and breadth of tasks AI models are able to complete are likely to increase." A model that can solve a competition programming problem in 50 lines but cannot navigate a 100,000-file repository to fix a real bug has limited practical value for software engineering.
Static benchmarks have saturated, but real-world utility has not. The paper notes in Section 6.2.4 that SWE-bench Verified has been public for over two years, creating contamination risks. More importantly, even strong performance on SWE-bench doesn't guarantee success on genuinely novel, multi-step development tasks because those benchmarks reduce software engineering to isolated, single-commit edits. The authors' new CC-Bench-V2 suite specifically targets chained tasks where errors compound across sequential commits—a regime where GLM-4.7 achieved only 43.0% pass@1 compared to GLM-5's 52.3%, and even Claude Opus 4.5 reached only 61.6% (Table 8), showing the problem remains far from solved.

The Training Infrastructure Barrier: Long-Horizon RL Is Computationally Broken

Beyond the capability gap itself, the paper identifies a critical infrastructure bottleneck that prevents models from learning agentic behavior effectively. The problem is that naively applying reinforcement learning to long-horizon agent trajectories creates enormous GPU idle time due to synchronization requirements (Section 4.1.1).

In a standard synchronous RL pipeline, the training engine must wait for ALL rollout trajectories in a batch to complete before computing gradient updates. When trajectories vary wildly in length—as they do in agentic tasks where some rollouts may terminate in 20 steps while others require 200+ steps—the system stalls on the slowest sample. The paper quantifies this implicitly: agentic tasks involve "severely imbalanced generation" that causes "large GPU idle time" during the rollout stage. This isn't merely an engineering inconvenience; it fundamentally limits how much agentic RL training can be performed within practical compute budgets, creating a self-reinforcing cycle where models can't learn long-horizon behavior because they can't be trained on enough long-horizon data.

This infrastructure challenge connects directly to the broader tension in LLM development: scaling models bigger (GLM-5 has 744B parameters, double GLM-4.5's 355B) makes the GPU cost of idle synchronization proportionally more expensive, not less. The paper's adoption of DSA (Section 2.1.1) isn't just about inference efficiency—it's about making RL training itself tractable by reducing per-step attention cost for the long contexts (up to 202,752 tokens) that agentic rollouts inevitably generate.

Where Prior Approaches Fall Short

The paper identifies specific limitations across multiple axes of existing work:

1. Open-weight models lag severely on real-world coding tasks, not just benchmarks.

This isn't the usual "open models are catching up to proprietary ones" narrative. The paper presents evidence (Figure 1, Table 7) that prior open models—including GLM-4.7, DeepSeek-V3.2, and Kimi K2.5—show a qualitatively different failure pattern on long-horizon agentic tasks compared to short-form benchmarks. While DeepSeek-V3.2 achieves 73.1% on SWE-bench Verified (only ~7 points behind GLM-5's 77.8%), it scores just $1,034 on Vending-Bench 2 compared to GLM-5's$ 4,432—a 4.3× gap. This suggests that prior open models can handle isolated bug fixes but collapse on sustained business management tasks requiring dozens of sequential decisions. The gap isn't merely about raw reasoning capability; it's about the ability to maintain coherent goal-tracking and avoid compounding errors over long horizons.

2. Synchronous RL training is fundamentally incompatible with agentic learning.

The paper's critique of existing RL infrastructure is specific and technical (Section 3.3, 4.1.1). Standard approaches like GRPO (Shao et al., 2024) and PPO assume relatively uniform rollout lengths, which holds for reasoning tasks (math proofs, code generation) where the model produces a single response per prompt. Agentic tasks break this assumption: a software engineering rollout might involve 50+ tool calls, environment interactions, file reads/writes, and test executions, with enormous variance in length depending on whether the agent finds the right files quickly or gets lost in the repository. The synchronization bottleneck means that even if aggregate throughput is high, wall-clock training progress is gated by the slowest sample in every batch.

The paper also notes a subtlety that prior work largely ignored: the off-policy problem in asynchronous training (Section 4.1.2). When rollout engines and training engines are decoupled across separate GPU fleets, trajectories may be generated by slightly different model versions depending on synchronization frequency. Tracking exact behavior probabilities π_θold for importance sampling becomes "computationally prohibitive" because it would require maintaining "an extensive history of model checkpoints." Existing off-policy RL methods for LLMs (e.g., offline RL, ReST; Singh et al., 2024) don't address this because they assume a static dataset, not a continuously updating policy.

3. Efficient attention mechanisms sacrifice quality for speed in long-context settings.

The paper provides a systematic ablation (Section 2.1.2) of efficient attention variants that reveals a sharp trade-off prior work hadn't fully characterized. Sliding window attention with naive layer interleaving causes "catastrophic degradation" on retrieval tasks—dropping from 75.28 to 6.51 on RULER@128K (Table 4)—because it blindly discards long-range dependencies that are critical for agentic navigation of large codebases. Linear attention variants like Gated DeltaNet recover some quality but still lose 8-11 points on RULER@128K (Table 5: GDN drops 11.28 points at 128K). Even the paper's improved SimpleGDN, which maximally reuses pre-trained weights, loses 8.25 points at 128K.

The crucial finding is that ALL efficient attention variants that reduce computation (as opposed to sparsifying it selectively) incur "an inherent accuracy gap on fine-grained retrieval tasks" due to "unavoidable information loss" during continual-training adaptation. This is particularly damaging for agentic coding, where the model must frequently retrieve specific function definitions, variable declarations, or error signatures from tens of thousands of tokens of context. The paper positions DSA as qualitatively different: "DSA is lossless by construction" because its lightning indexer achieves token-level sparsity without discarding any long-range dependencies, enabling application to all layers with no quality degradation. The small-scale DSA experiment on GLM-4.7-Flash (Table 6) supports this—after full joint training, DSA surpasses the dense baseline at 16K, 32K, and 64K context lengths, with only a 0.35-point deficit at 128K.

4. Existing multi-turn agent training conflates tool-calling with genuine agency.

The paper implicitly critiques approaches that train agents through supervised fine-tuning on tool-calling trajectories (as in GLM-4.5's pipeline) without addressing the sequential dependency problem. The key issue, revealed in Section 3.1's discussion of Interleaved Thinking and Preserved Thinking, is that models trained on static tool-use demonstrations learn to call tools correctly in isolation but fail to maintain reasoning coherence across multiple turns. When a model encounters a novel error during agentic execution, it can't effectively incorporate that feedback into its subsequent decisions because its training taught it to follow fixed patterns, not to dynamically replan.

The paper's solution—training with retained thinking blocks across turns (Preserved Thinking) and interleaving reasoning between tool calls (Interleaved Thinking)—represents a specific architectural response to this limitation. Prior models either discarded reasoning context between turns (forcing re-derivation and causing information loss) or failed to think before tool calls (producing mechanically correct but strategically poor action sequences). The infrastructure to support this training—the Token-in-Token-out gateway that preserves exact action-level correspondence and the Direct Double-sided Importance Sampling that stabilizes off-policy updates—didn't exist in prior open-source RL frameworks.

5. Context management for search agents is treated as an afterthought.

The paper identifies a specific failure mode in long-horizon search agent evaluation: "model accuracy degrades substantially under extremely long contexts (e.g., beyond 100k tokens)" (Section 4.2.4). Prior work like DeepSeek-V3.2 employed a simple "discard-all" strategy that resets context entirely when it grows too large, but the paper shows that this is unnecessarily destructive. Their proposed keep-recent-k strategy—folding observations older than k rounds while preserving the most recent context—improves BrowseComp performance from 55.3% to 62.0%, a 6.7-point gain from a purely inference-time change. The hybrid Hierarchical Context Management combination with discard-all reaches 75.9, establishing that context management isn't just a deployment detail but a first-class factor in agent performance.

How This Paper Positions Itself

The paper frames its contribution not as a single architectural breakthrough but as a system-level integration of advances that jointly enable the transition from vibe coding to agentic engineering. This positioning is careful: individual components (DSA, asynchronous RL, agentic training environments) aren't entirely novel in isolation, but their combination—and the specific engineering required to make them work together at the GLM-5 scale—represents a distinct contribution.

The paper draws three explicit contrasts with prior work:

Versus GLM-4.5: GLM-4.5 established the ARC (Agentic, Reasoning, Coding) capability unification but was bottlenecked by synchronous training and MLA attention. GLM-5 doubles total parameters (744B vs 355B), extends context to 200K with DSA-based efficiency (vs 128K with dense attention), and introduces the fully asynchronous agentic RL pipeline. The improvements are framed as architectural—not just more data or compute—with the 20% average benchmark improvement (Section 1, Results) attributed to these specific changes.

Versus other open-weight models: The paper positions GLM-5 against DeepSeek-V3.2 and Kimi K2.5 on real-world coding tasks, not just academic benchmarks. The key differentiator isn't raw reasoning (Kimi K2.5 matches or exceeds GLM-5 on AIME and GPQA) but sustained agentic performance on long-horizon tasks like Vending-Bench 2 ( $4,432 vs$ 1,034 for DeepSeek-V3.2 and $1,198 for Kimi K2.5) and BrowseComp (75.9 vs 67.6 and 74.9). This suggests that GLM-5's training pipeline—specifically the asynchronous agentic RL with environment scaling—provides a capability that reasoning-focused RL alone doesn't develop.

Versus proprietary models: The paper is notably pragmatic about the gap to Claude Opus 4.5 and GPT-5.2 (xhigh). On short-form coding and reasoning, GLM-5 is competitive (77.8% on SWE-bench Verified vs Claude's 80.9%). On long-horizon chained tasks in CC-Bench-V2, a "significant gap" remains (Table 8: 52.3% vs 61.6% for Claude). The paper attributes this to error compounding across sequential commits and frames it as an active research direction rather than something solved. The "Pony Alpha" Easter egg (Section 8) serves as a positioning device: by releasing GLM-5 anonymously on OpenRouter and having the community guess its origin, the authors argue the model's capabilities stand on their own merits, detached from brand or origin biases.

Positioning on training infrastructure: The paper's emphasis on full-stack adaptation to Chinese GPU ecosystems (Section 5) is not merely an implementation detail but a strategic positioning claim. By successfully deploying across seven domestic chip platforms (Huawei Ascend, Moore Threads, Hygon, Cambricon, Kunlunxin, MetaX, Enflame), the authors argue that GLM-5 demonstrates that frontier AI development is possible outside the NVIDIA-CUDA ecosystem, reducing deployment costs in long-sequence scenarios by 50% through hardware-level co-optimization. This positions GLM-5 as not just a technical achievement but an infrastructure independence milestone.

The implicit thesis: Throughout the paper, there's an unstated but consistent argument: the next frontier for LLMs isn't raw reasoning capability (which is approaching saturation on many benchmarks) but agentic endurance—the ability to maintain coherent, self-correcting behavior over extended horizons. The paper's architectural choices (DSA for efficient long-context processing, asynchronous RL for training on long trajectories, Preserved Thinking for cross-turn reasoning coherence) all serve this thesis. The evaluation strategy reinforces it: success on SWE-bench is treated as table stakes, while Vending-Bench 2, CC-Bench-V2 chained tasks, and BrowseComp with context management are presented as the more discriminating measures of actual agentic capability.

3. Technical Approach

3.1 Reader Orientation

GLM-5 is a large language model system — specifically a 744-billion-parameter Mixture-of-Experts transformer — designed to autonomously complete complex, multi-step software engineering tasks rather than requiring a human to prompt it for every code edit. The core problem it solves is the transition from "vibe coding" (human-in-the-loop at every step) to "agentic engineering" (AI-driven planning, implementation, debugging, and iteration over extended horizons), and the shape of the solution spans three interconnected mechanisms: (1) a sparse attention architecture (DSA) that makes processing 200K-token contexts computationally feasible for long agent trajectories, (2) a fully asynchronous reinforcement learning infrastructure that eliminates GPU idle time during agent training, and (3) specialized RL algorithms that stabilize off-policy learning when rollouts and training are decoupled across separate hardware.

3.2 Big-Picture Architecture (Diagram in Words)

The GLM-5 system has five major phases, arranged sequentially in a training pipeline:

Pre-Training (Base Model) — A 744B-parameter MoE transformer with Multi-latent Attention (MLA) and Multi-token Prediction (MTP) is trained on 28.5 trillion tokens across web, code, math, and science corpora. This phase produces a general-purpose language model with broad reasoning and coding capabilities.
Mid-Training (Long Context + Agentic Data) — The context window is progressively extended from 4K to 200K tokens using continued training on long documents, synthetic long-range dependency data, and software engineering trajectories (issue-PR pairs, repository-level code). A DSA indexer is then trained via continued pre-training to replace dense attention with sparse, content-aware token selection, reducing attention computation by 1.5–2× for long sequences without quality loss.
Supervised Fine-Tuning (SFT) — The base model is fine-tuned on multi-task data covering general chat, reasoning, and coding/agent scenarios. This phase introduces three thinking modes: Interleaved Thinking (reasoning before every tool call), Preserved Thinking (retaining reasoning blocks across multi-turn conversations), and Turn-level Thinking (per-turn reasoning control). Erroneous segments in agent trajectories are retained in training data but masked from the loss to teach error correction.
Reinforcement Learning (Staged) — The SFT model undergoes three sequential RL stages: Reasoning RL (math, science, code, and tool-integrated reasoning with GRPO-based optimization), Agentic RL (coding and search agent tasks using the fully asynchronous, decoupled infrastructure), and General RL (human-style alignment with multi-dimensional objectives covering correctness, emotional intelligence, and task-specific quality). A final On-Policy Cross-Stage Distillation stage recovers capabilities that may have regressed during sequential optimization.
Inference Deployment — The trained model is deployed with INT4 quantization-aware training, speculative decoding via MTP, and hardware-specific kernel optimizations (Lightning Indexer, Sparse Flash Attention, MLAPO) for seven Chinese GPU platforms. Context management strategies (keep-recent-k, hybrid hierarchical context management) are applied at inference time for search and coding agents.

Information flows sequentially through these phases: pre-training data → base model → mid-training data → context-extended model → SFT data → instruction-tuned model → reasoning RL data → reasoning-augmented model → agentic RL data → agentic-augmented model → general RL data → fully aligned model → on-policy distillation → final GLM-5 checkpoint.

3.3 Roadmap for the Deep Dive

First, the pre-training architecture (Section 2.1): the MoE design, the Muon Split optimizer adaptation for MLA, the MTP parameter-sharing scheme, and the DSA continued pre-training procedure — since the base model's capabilities constrain everything downstream.
Second, the pre-training data and mid-training pipeline (Sections 2.2–2.3): because the composition of the 28.5T-token corpus and the progressive context extension directly shape which capabilities the model acquires and how it handles long sequences.
Third, the training infrastructure innovations (Section 2.4): memory efficiency techniques, parallelism strategies, and quantization-aware training — since these are what made training a 744B model feasible at this scale.
Fourth, the SFT phase and thinking modes (Section 3.1): the three thinking characteristics and the data construction pipeline, because these define the agentic interaction patterns that RL will later optimize.
Fifth, the RL algorithms and infrastructure (Sections 3.2–3.6): the IcePop-based reasoning RL objective, the fully asynchronous agentic RL design with TITO gateway and Direct Double-sided Importance Sampling, and the slime framework — since these are the core innovations enabling agentic learning.
Sixth, the agentic environment scaling (Section 4.2): the SWE, terminal, search, and slide generation environments — because RL can only optimize what the environments can verify.
Seventh, the inference-time context management strategies (Section 4.2.4): keep-recent-k and hybrid hierarchical context management — because these are critical for deployment performance but not part of training.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a systems and training methodology paper whose core idea is that combining sparse attention, asynchronous RL infrastructure, and carefully designed agentic training environments enables LLMs to transition from single-turn code generation to sustained autonomous software engineering.

3.4.1 Pre-Training Architecture: MoE, MLA, and MTP

Mixture-of-Experts Scaling

GLM-5 scales the MoE architecture from GLM-4.5's 160 experts (32B active parameters out of 355B total) to 256 experts (40B active parameters out of 744B total), while reducing the layer count from 92 (89 MoE + 3 dense) to 78 (75 MoE + 3 dense). The layer reduction is a deliberate engineering tradeoff: fewer layers mean less communication overhead in expert parallelism, since each MoE layer requires an all-to-all communication step to route tokens to the correct experts across GPU nodes. The total parameter count approximately doubles (744B vs 355B), but the active parameter count increases only modestly (40B vs 32B), meaning the model becomes sparser — a larger fraction of its parameters sit idle for any given token. This design choice reflects the paper's philosophy that scaling total capacity while keeping per-token computation roughly constant is the most efficient path to improved performance.

Table 10 provides the detailed architectural comparison. The hidden dimension increases from 5120 to 6144, MoE intermediate dimension from 1536 to 2048, and the attention mechanism shifts from Grouped-Query Attention (GQA-8, 8 key-value heads, QK head dim 128, V head dim 128) to Multi-latent Attention (MLA, QK head dim 192, V head dim 256, with a 2048-dimension Q LoRA and 512-dimension KV LoRA). The vocabulary expands from 151,552 to 154,880 tokens.

Multi-Latent Attention and the Muon Split Fix

MLA is a memory-efficient attention variant that compresses keys and values into low-dimensional latent vectors, reducing the KV-cache memory footprint during inference. Instead of storing full-dimensional key and value vectors for every token in the cache, MLA stores compressed representations and decompresses them on-the-fly during attention computation. This is critical for long-context agentic workloads where the KV-cache can dominate GPU memory.

However, the paper encountered a specific performance gap: with the Muon optimizer (which uses matrix orthogonalization, i.e., periodically enforcing orthogonality constraints on weight matrices to stabilize training dynamics), standard MLA with a 576-dimension latent KV-cache could not match GQA-8 with a 2048-dimension KV-cache on downstream benchmarks. Table 1 shows this clearly: GQA-8 scores 53.3 on BBH and 38.5 on HumanEval, while standard MLA scores 48.9 and 33.5 respectively — meaningful drops on both reasoning and coding metrics.

The root cause lies in how Muon's orthogonalization interacts with MLA's weight matrices. In the original Muon recipe, matrix orthogonalization is applied to the full up-projection matrices W_UQ (query projection), W_UK (key projection), and W_UV (value projection) — these are the matrices that project from the latent space back to the full attention head dimension. However, these matrices are conceptually block-structured: they project to multiple attention heads, each of which should learn different features. Orthogonalizing the entire matrix as one unit forces all heads' projection weights to update at the same scale, which is the wrong inductive bias — different heads benefit from different learning rates.

The solution, called Muon Split, is elegantly simple: instead of orthogonalizing the full up-projection matrix, the matrix is split into per-head blocks, and matrix orthogonalization is applied to each head's sub-matrix independently. This enables projection weights for different attention heads to update at different scales, preserving the heterogeneity that makes multi-head attention effective. Table 1 shows that MLA + Muon Split recovers the gap: BBH improves to 51.8 (from 48.9), HumanEval improves to 36.7 (from 33.5), and MMLU actually exceeds GQA-8 (62.5 vs 61.2). The paper also notes a practical benefit: with Muon Split, "the scale of attention logits of GLM-5 remains stable during pre-training without any clipping strategy" — meaning no gradient clipping or attention logit clamping was needed, simplifying the training recipe.

Decoding Efficiency and the MLA-256 Variant

MLA introduces a secondary problem during inference: the per-token decoding step performs a 576-dimensional dot product between query and key, compared to GQA's 128-dimensional computation. In transformer decoding, each new token must compute attention against all previous tokens' cached keys — this is the dominant cost of autoregressive generation. A higher-dimensional dot product means more FLOPs per attended token, slowing down generation.

The paper's solution, MLA-256, exploits the fact that MLA during training and prefilling behaves like standard Multi-Head Attention (MHA) — it processes all tokens in parallel with full matrix multiplications. By increasing the per-head dimension from 192 to 256 and proportionally reducing the number of attention heads by 1/3, the total training computation and parameter count remain constant (192 × 96 heads = 18,432 total dimension, 256 × 64 heads = 16,384 total dimension — slightly different but the paper states they remain constant, likely due to other architectural adjustments not fully enumerated). However, during decoding, the reduced head count means fewer parallel dot products, and the increased per-head dimension is amortized across the reduced number of heads. Table 1 confirms MLA-256 matches the performance of standard MLA under Muon Split (e.g., BBH 51.3 vs 51.8, GSM8K 47.5 vs 45.0 — actually slightly better on GSM8K).

The design choice reflects a hardware-aware optimization: the head count in DeepSeek-V3 was chosen according to the roofline of H800 GPUs (balancing compute and memory bandwidth), but this roofline is different for the GPUs used in GLM-5 training. The paper doesn't specify which GPUs, but the adaptation principle is clear: architectural hyperparameters should be tuned to the specific hardware's compute-to-memory-bandwidth ratio, not blindly copied from prior work.

Multi-Token Prediction with Parameter Sharing

Multi-token prediction (MTP) is a technique where the model predicts the next n tokens simultaneously rather than just the next single token. During training, this requires n additional MTP layers — one for each future token position — each with its own parameters and KV-cache overhead. The memory cost scales linearly with n, which is prohibitive for large models.

DeepSeek-V3's solution was to train with a single MTP layer (predicting only the next 2 tokens) and then use it for speculative decoding at inference time. Speculative decoding works by using a small, fast "draft" model to propose multiple future tokens, then having the main model verify them in parallel. The problem is that this creates a training-inference discrepancy: the MTP layer was trained to predict the very next token (position +1), but during inference it's also used to predict position +2 (and beyond, via chaining). This reduces the acceptance rate — the fraction of drafted tokens that the main model actually agrees with — because the MTP layer's predictions at position +2 are operating out-of-distribution.

GLM-5's innovation is parameter sharing across MTP layers during training. Instead of training separate MTP layers for each future position, three MTP layers are trained, but they share parameters. During inference, a single MTP layer (with the shared parameters) can be applied sequentially to draft multiple tokens, but because it was trained on positions +1, +2, and +3 (via the shared parameters), it performs better at each position than a single-position-trained MTP layer. Table 2 confirms this: GLM-5 achieves an acceptance length of 2.76 tokens compared to DeepSeek-V3.2's 2.55, evaluated on a private prompt set with 4 speculative steps. A longer acceptance length means the draft model proposes more tokens that the main model accepts, reducing the total number of main-model forward passes needed and speeding up generation.

The parameter sharing is what makes this feasible: training three separate MTP layers would triple the draft model's memory cost, but sharing parameters keeps the memory cost constant (same as DeepSeek-V3's single MTP layer) while providing multi-position training signal.

3.4.2 DeepSeek Sparse Attention (DSA): Continued Pre-Training from Dense

DSA is the architectural centerpiece that makes long-context agentic training economically viable. The core idea is that for long sequences (128K tokens and beyond), the vast majority of attention connections between tokens are unnecessary — most tokens only need to attend to a small, content-dependent subset of other tokens. DSA replaces the standard dense O(L²) attention with a learned sparsification mechanism: a lightweight "indexer" network predicts which token pairs are worth attending to, and attention is computed only over the selected pairs.

What makes DSA different from other sparse attention methods: Unlike fixed sparsity patterns (sliding windows, dilated attention, block-sparse patterns), DSA's sparsity is content-aware and dynamic. The indexer looks at the actual query and key representations and decides which keys are relevant. This is critical because agentic programming contexts have irregular attention patterns: a function call needs to attend to its definition (possibly thousands of tokens away), a test failure needs to attend to the specific line that caused it, and these dependencies can't be captured by fixed window sizes or static block patterns. Section 2.1.2's ablation study (Tables 4–6) demonstrates that even sophisticated learned patterns (SWA Pattern via beam search, SimpleGDN linear attention) lose 1.6–8.3 points on RULER@128K compared to dense attention, while DSA loses only 0.35 points — essentially matching dense attention quality while reducing computation by 1.5–2×.

The continued pre-training procedure is what makes DSA practical. Training a sparse attention model from scratch would be "astronomically" expensive because the model must simultaneously learn when to attend (the indexer) and what to do with the attended information (the transformer layers), with no good initialization for either. Instead, GLM-5 takes an already-trained dense base model (trained with MLA attention through mid-training) and continues training it with DSA in two stages:

Stage 1: Dense warm-up (1000 steps). Each training step processes 14 sequences of 202,752 tokens each (batch size of ~2.8M tokens per step). The maximum learning rate is 5×10⁻³, which is extremely high — 25× higher than the pre-training peak of 2×10⁻⁴. This is because only the newly introduced indexer parameters are being trained at this stage; the rest of the model remains frozen. The high learning rate enables rapid adaptation of the indexer to the model's existing representations.

Stage 2: Sparse adaptation (20B tokens). Both the indexer and the base model are jointly trained on 20 billion tokens of mid-training data, using the same hyperparameters as the mid-training phase. The learning rate is constant at 1×10⁻⁵ (from Table A's description: "For DSA sparse adaptation stage, we use a constant learning rate of 1e-5"). This is relatively small because the base model is already well-trained, and the goal is to fine-tune it to work with the sparse attention patterns, not to relearn from scratch.

A critical finding is that this 20B-token adaptation budget, while "much smaller than that of DeepSeek-V3.2 (943.7B tokens)," is sufficient. Table 3 confirms that the DSA model matches the MLA model on long-context benchmarks: both achieve 100.0 on MQ-NIAH-128k and similar scores on MV-NIAH-128k (97.0 vs 95.5), SQuAD-128k (86.0 vs 79.7 — DSA actually better), and HotpotQA-128k (63.0 vs 66.3). The authors further validate this by fine-tuning both models with the same SFT data and observing that "the two models tie in training loss and evaluation benchmarks" — meaning the DSA model generalizes as well as the dense model on downstream tasks.

Why DSA is "lossless by construction": The key insight is that DSA's indexer performs a selection operation, not a compression operation. It chooses which key-value pairs to keep, but the attention computation on the selected pairs is exact — the same mathematical operation as dense attention, just on a subset of tokens. This contrasts with linear attention methods like Gated DeltaNet, which approximate the full attention matrix with a low-rank factorization. The approximation error in linear attention increases with sequence length (since more information must be compressed into a fixed-size state), while DSA's selection accuracy can be maintained regardless of sequence length by choosing an appropriate sparsity ratio k.

The indexer mechanism in detail (as used during RL, Section 3.2): The indexer computes a relevance score for each query-key pair, selects the top-k keys (with k=2048), and attention is computed only over these k keys. The paper notes that k=2048 "is much larger than the k typically used in MoE" — in MoE routing with 256 experts, typically k=8 experts are selected per token. This means the indexer's top-k selection is an order of magnitude more expensive to store and communicate than MoE routing, which is why the paper cannot use the standard MoE trick of "routing replay" (storing the selected expert indices to ensure training-inference consistency).

DSA RL stability and the top-k determinism issue (Section 3.2): During RL training, a critical problem emerges. The inference engine (generating rollouts) and the training engine (computing gradients) may run on different hardware with different top-k implementations. The SGLang inference framework uses a CUDA-based top-k operator that is non-deterministic — it may select different top-k keys on different runs even given identical inputs, due to floating-point tie-breaking and parallel reduction order. When the training engine receives a rollout trajectory, it must recompute the model's forward pass to get log-probabilities for gradient computation. If the recomputed forward pass uses different top-k selections than the original rollout (due to non-determinism), the log-probability mismatch creates a training signal that is essentially noise — the gradient doesn't correspond to the action that was actually taken.

The paper's solution is to use torch.topk, PyTorch's default top-k implementation, which is deterministic (it uses a stable sorting algorithm and consistent tie-breaking). The tradeoff: torch.topk is "slightly slower" than CUDA-optimized or TileLang implementations, but the speed penalty is negligible compared to the RL performance gain. The paper reports that "other non-deterministic top-k operators (e.g., CUDA or TileLang implementations) caused drastic performance degradation during RL after only a few steps, accompanied by a sharp drop in entropy" — meaning the model essentially collapses, losing the diversity of its output distribution because the noisy training signal drives it toward degenerate solutions.

Additionally, the indexer parameters are frozen by default during RL. This is both a speed optimization (fewer parameters to update) and a stability measure: since the indexer is small and the base model is large, updating the indexer based on RL rewards could cause it to overfit to the RL training distribution, breaking its ability to generalize to new contexts during deployment.

3.4.3 Efficient Attention Ablation Study (Section 2.1.2)

While DSA is the chosen architecture, the paper provides a systematic ablation of alternatives to justify the choice. These experiments use GLM-9B, a smaller model from the GLM-4 series, with a 128K context window.

Sliding Window Attention (SWA) variants:

SWA Interleave: A fixed alternating pattern of full-attention and windowed-attention layers applied uniformly across all 40 layers. Each windowed layer only attends to the 4096 most recent tokens. Table 4 shows catastrophic degradation: on RULER at 128K, accuracy drops from 75.28 (full attention) to 6.51. The failure mode is that long-range retrieval tasks — where the answer depends on a piece of information at the very beginning of the context — become impossible because the windowed layers cannot "see" beyond 4096 tokens.
SWA Pattern (Search-Based): Inspired by PostNAS, this uses beam search to find the optimal subset of layers to convert to SWA while keeping others as full attention. The search is conducted at 16K context length (to keep it computationally tractable) and uses beam size 8, optimizing two layers per step over approximately 10 steps (for 40 layers). At each step, candidate patterns are evaluated on the RULER benchmark at 16K. The final pattern is SFSSFFSSSFFFFSSFSFFFFFFSFSFSSFSSFSFSSFSSS (where S=SWA, F=Full attention), which is highly irregular — it's not a simple alternating pattern but a complex distribution that likely concentrates full-attention layers at positions where long-range dependencies are most critical.

The performance improvement is dramatic: on RULER@128K, SWA Pattern achieves 53.95 vs 6.51 for interleaved SWA (Table 4). However, after continual training on 190B tokens (Table 5), SWA Pattern still loses 5.69 points at 128K relative to full attention (69.59 vs 75.28). The gap exists because even with optimal layer placement, the SWA layers are blind to tokens beyond the 4096 window, and some queries simply need information from outside that window, regardless of which layer they're in.

Linear attention variants:

Gated DeltaNet (GDN): This replaces the quadratic softmax attention with a gated linear recurrence. Instead of computing softmax(QK^T)V directly, it maintains a recurrent state that summarizes past information and updates it via a delta rule (adding new information while decaying old information based on a learned gate). The computational cost is linear in sequence length rather than quadratic, enabling efficient processing of very long contexts. Table 5 shows GDN loses 8.59 points at 64K and 11.28 points at 128K on RULER relative to full attention — better than SWA Interleave but worse than SWA Pattern.
SimpleGDN: The paper's improved linear attention variant that "maximally reuses pre-trained weights." It removes GDN's Conv1d and explicit gating modules entirely, directly mapping the pre-trained Query, Key, and Value projection weights into the linear recurrence formulation. This eliminates the need for additional parameters that would need to be learned from scratch during continual training. Table 5 shows SimpleGDN achieves the best results among efficient attention variants: on RULER, it loses only 3.59 points at 64K and 8.25 points at 128K; notably, on HELMET-ICL, it actually improves over full attention at 128K (81.84 vs 77.36, a 4.48-point gain), likely because the linear recurrence's implicit compression acts as a form of regularization that helps on certain types of long-context tasks.

The key finding across all variants: Even with half the layers retaining full attention, all efficient attention mechanisms incur an accuracy gap on fine-grained retrieval tasks (RULER, RepoQA) due to "unavoidable information loss." The gap is smallest for SimpleGDN (3.59 points at 64K RULER) but still present. DSA avoids this gap entirely because it doesn't compress or truncate information — it selectively attends to the most relevant tokens while mathematically preserving the exact attention computation on those tokens. The tradeoff is that DSA requires training an additional indexer network and uses a non-trivial amount of compute for the top-k selection, but for agentic coding tasks where precise retrieval from long contexts is critical, this tradeoff is clearly worthwhile.

Small-scale DSA verification (Table 6): To validate the lossless claim, a DSA indexer is trained on top of GLM-4.7-Flash (a smaller model with MLA). After only the warmup phase (indexer trained for 1000 steps, base model frozen), performance at 64K RULER drops only slightly (84.05 vs 85.34 baseline), though 128K drops more (71.35 vs 79.21). After the full joint-training phase (150B tokens), the DSA model surpasses the baseline at 16K (96.69 vs 95.83), 32K (93.45 vs 92.96), and 64K (87.06 vs 85.34), with only a 0.35-point deficit at 128K (78.86 vs 79.21). This effectively confirms that DSA matches dense attention quality while providing the 1.5–2× computation reduction.

3.4.4 Pre-Training Data Composition (Section 2.2)

The 28.5-trillion-token pre-training corpus is organized into four categories with specific quality-improvement techniques:

Web data: Building on GLM-4.5's pipeline, the paper introduces a new DCLM classifier based on sentence embeddings to identify high-quality web documents beyond what standard classifiers catch. This is motivated by the observation that existing quality classifiers (typically trained to distinguish Wikipedia-like text from low-quality text) miss genuinely informative content that doesn't fit the encyclopedia style — technical forums, detailed tutorials, documentation with code examples. A separate "World Knowledge classifier," optimized via Wikipedia entries and LLM-labeled data, specifically targets long-tail knowledge that would otherwise be filtered out by quality-based heuristics. This classifier identifies documents that, while not meeting standard "high-quality" criteria (they might have formatting issues, informal language, or mixed content types), contain valuable factual information that improves the model's knowledge coverage.

Code data: The code corpus is expanded by refreshing snapshots from code hosting platforms (GitHub-like repositories) and collecting more code-containing web pages, yielding a 28% increase in fuzzily deduplicated unique tokens. "Fuzzily deduplicated" means near-duplicate files are removed using approximate matching (e.g., files that differ only in whitespace, comments, or minor variable names are treated as duplicates), which is important for code because the same library or algorithm implementation appears in thousands of repositories with minor variations.

Two specific quality improvements are notable. First, metadata alignment issues in Software Heritage code files — where file-level metadata (language, license, repository) was incorrectly associated with source code — are fixed, reducing noise in the training signal. Second, dedicated classifiers are trained for low-resource programming languages (Scala, Swift, Lua, and others), improving the sampling quality for these languages. Without such classifiers, rare languages would be under-sampled (since a global quality classifier trained primarily on Python/JavaScript would not recognize high-quality code in less common languages) and, when sampled, might contain lower-quality examples because the global classifier can't distinguish good from bad code in unfamiliar syntax.

Math & Science data: The paper emphasizes that content extraction pipelines for webpages and PDF parsing mechanisms for books and papers are "refined to increase data quality." This is a non-trivial challenge for math content because LaTeX equations, chemical formulas, and specialized notation are frequently mangled by standard text extraction tools. The paper uses LLMs to score candidate documents, retaining only those with "the most educational content" — meaning documents that systematically explain concepts rather than merely presenting solutions or results.

A notable technique is the "chunk-and-aggregate scoring algorithm" for long-context documents. When a document is too long to fit in the scoring LLM's context window (e.g., a 500-page textbook), it is split into chunks, each chunk is scored independently, and the scores are aggregated to produce a document-level quality estimate. Filtering pipelines explicitly avoid synthetic, AI-generated, or template-based data — a precaution against the now-common problem of training on model-generated content, which can cause distributional collapse.

3.4.5 Mid-Training: Progressive Context Extension and Agentic Data (Section 2.3)

Mid-training is where the base model acquires the ability to handle long contexts and understand software engineering workflows. The process is organized into three stages of increasing context length, each with specific data emphases:

Stage 1: 32K context, 1T tokens. The context window is extended from the pre-training default (likely 4K or 8K, though not explicitly stated) to 32,768 tokens. This stage uses a mixture of long documents, concatenated repository code files, and synthetic agent trajectories, with the specific up-sampling ratios varying across stages.

Stage 2: 128K context, 500B tokens. The context window extends to 131,072 tokens. Long documents and synthetic agent trajectories are up-sampled at this stage to ensure the model learns to utilize the extended context.

Stage 3: 200K context, 50B tokens. The final extension to 202,752 tokens. The paper notes that this additional stage (beyond GLM-4.5's 128K maximum) "substantially improves the model's ability to process ultra-long documents and complex multi-file codebases." An interesting empirical finding is that "a subsequent 200K mid-training stage, building upon the initial 128K phase, further bolstered the model's performance even within the 128K context window" — meaning the model's ability to use context up to 128K improves from being trained on even longer sequences, likely because the training signal at position 128K in a 200K sequence requires attending across the full range, creating a more challenging and informative learning problem.

Software engineering data: The paper retains GLM-4.5's paradigm of concatenating repository-level code files, commit diffs, GitHub issues, pull requests, and relevant source files into unified training sequences. The sequence might look like: [issue description] → [relevant source files] → [commit diff showing the fix] → [pull request discussion], all concatenated into a single training example. This teaches the model the relationship between natural language task descriptions and code changes.

Two changes from GLM-4.5 are significant:

Repository filtering criteria are relaxed to broaden the pool (yielding approximately 10 million issue-PR pairs), but quality filtering at the individual issue level is strengthened. This tradeoff — more data, more carefully filtered — reflects the observation that strict repository-level filtering (e.g., requiring a minimum number of stars, specific CI configurations) eliminates many valid software engineering examples from smaller or less polished repositories.
A larger set of relevant files is retrieved for each issue-PR pair, resulting in "richer development contexts and broader coverage of real-world software engineering scenarios." This addresses a common failure mode in coding agents: when the training data only includes the exact files that were changed, the model never learns to identify which files are relevant from a larger codebase. By including a broader set of files (some of which are not directly modified), the model learns to distinguish relevant from irrelevant context.

The issue-PR portion of the dataset comprises approximately 160B unique tokens after filtering.

Long-context data: Natural data is curated from books, academic papers, and documents using multi-stage filtering: perplexity-based filtering (removing text that is too repetitive or too random), deduplication, length filtering, and upsampling of knowledge-intensive domains. The paper specifically mentions "inspired by NextLong and EntropyLong" for synthetic data construction, where diverse techniques are used to build long-range dependencies. The key technique is "interleaved packing" — concatenating highly similar texts to produce sequences where the model must track which information came from which document. This specifically targets the "lost-in-the-middle" phenomenon where models attend well to the beginning and end of long contexts but ignore the middle.

At the 200K stage, "MRCR-like data" is introduced. MRCR (Multi-Round Coreference Resolution) involves extended multi-turn dialogues where later turns refer to entities introduced much earlier, requiring the model to maintain coreference chains across very long distances. Multiple variants are designed to "extend OpenAI's original paradigm" — likely meaning variations in the type of references (pronouns, definite descriptions, named entities), the distance between mentions, and the number of intervening distractors.

3.4.6 Training Infrastructure: Memory and Parallelism Efficiency (Section 2.4)

Training a 744B-parameter model on 28.5T tokens requires extreme engineering to fit within GPU memory constraints and maintain high throughput. The paper describes six specific techniques:

Flexible MTP placement: Under interleaved pipeline parallelism (where different model stages are assigned to different GPUs, and microbatches are pipelined through them), the MTP module spans multiple components — embedding, transformer layers, and output projection. The MTP output layer incurs "substantially higher memory usage than other modules" because it projects to the full vocabulary (154,880 tokens). This creates a stage-level imbalance: the final pipeline stage (which contains the output layer) uses much more memory than earlier stages, becoming the bottleneck.

The solution is to co-locate the MTP output layer with the main output layer on the final stage, enabling parameter sharing (since both output layers project to the same vocabulary with similar weight shapes). The MTP's embedding and transformer components are placed on the preceding stage. This reduces memory pressure on the final stage and "improves balance across pipeline ranks" — meaning all GPUs in the pipeline can use larger batch sizes because no single GPU is memory-constrained.

Pipeline ZeRO2 gradient sharding: In standard pipeline parallelism, each pipeline rank maintains multiple stages (i.e., processes multiple consecutive layers), and each stage requires a full gradient buffer for accumulation and optimizer updates. Naively, this means each GPU stores full-precision gradients for all parameters in its stages, which can be enormous.

The paper applies ZeRO2-style gradient sharding: gradients are partitioned across data-parallel ranks, so each rank (GPU within a data-parallel group) stores only a 1/dp fraction of the full gradients, where dp is the number of data-parallel replicas. Additionally, the paper uses double buffering: full accumulation buffers are retained for only two stages at a time and reused. While one stage buffer accumulates gradients over consecutive microbatches, gradient synchronization for the previous stage buffer is performed in parallel (overlapping communication with computation). The persistent gradient memory is thus reduced to per-stage sharded buffers plus only two full buffers for rolling accumulation, with "no additional synchronization overhead in practice."

Zero-redundant communication for the Muon optimizer: The Muon optimizer requires all-gathering full model parameters on each data-parallel rank during orthogonalization (since orthogonalization is a global operation over a weight matrix). The naive implementation causes "transient memory spikes and redundant communication" because each rank temporarily holds a full copy of the parameters.

The paper restricts all-gather to parameter shards owned by each rank and overlaps local computation with shard communication. This means each rank only all-gathers the subset of parameters it is responsible for orthogonalizing, performs the orthogonalization, and then scatters the result, all while overlapping communication of other shards. This "eliminates redundant communication and significantly reduces optimizer-related peak memory overhead."

Pipeline activation offloading: During pipeline warmup, forward execution advances ahead of backpropagation (creating a "bubble" where some GPUs are idle while waiting for the backward pass to catch up). This prolongs the lifetime of intermediate activations, which must be kept in GPU memory for the backward pass.

The solution: activations are offloaded to host (CPU) memory after forward execution and reloaded prior to backward execution, applied at per-layer granularity. Offloading and reloading are scheduled to overlap with computation while avoiding contention with peer-to-peer communication and MoE token routing (dispatch and combination — the all-to-all operations that send tokens to their assigned experts). Combined with fine-grained recomputation (recomputing some activations during the backward pass rather than storing them), this "largely eliminates the need to keep activations resident in GPU memory" with "near-zero overhead."

Sequence-chunked output projection: The output projection (mapping from hidden dimension to vocabulary) and cross-entropy loss computation incur transient memory overhead from two sources: storing activations for backpropagation (the large vocabulary-size output tensor) and promoting activations to higher precision during loss computation (FP32 vs BF16/FP16).

The paper partitions the input sequence into smaller chunks and computes projection and loss independently on each chunk, completing both forward and backward passes and releasing activations before moving to the next chunk. Peak memory usage decreases as the number of chunks increases. The tradeoff is that chunking introduces a small computational overhead (recomputing some parts of the output projection multiple times), but with an appropriate chunk count, this approach "alleviates output-layer memory pressure while maintaining performance comparable to unchunked execution" — meaning the overhead is small enough to be worthwhile.

Efficient deferred weight gradient computation: To reduce pipeline bubbles (idle time when some GPUs are waiting for others), "some weight gradient computation of the critical path" is deferred. The critical path is the sequence of operations that determines the total training step time — any delay on the critical path directly slows down training. By deferring gradient computation that isn't on the critical path, the pipeline can overlap it with other operations. Fine-grained deferral with "optimized storage and communication overlap improves throughput while keeping memory overhead bounded."

Efficient long-sequence training: Long sequences (128K-200K tokens) create specific parallelism challenges. "Workload-aware sequence reordering" groups sequences of similar length together to minimize padding waste. "Dynamic redistribution of attention computation" likely means adjusting which GPUs compute attention for which parts of the sequence based on load. "Flexible partitioning of data parallel ranks into context-parallel groups of varying sizes" enables sequences to be split across multiple GPUs for attention computation, with the partition size adapting to sequence length. A hierarchical all-to-all communication pattern overlaps intra-node and inter-node communication for QKV tensors to reduce latency.

INT4 Quantization-aware training (QAT): Applied in the SFT stage, INT4 QAT trains the model to be robust to 4-bit quantization during deployment. The paper developed a quantization kernel "applicable to both training and offline weight quantization, which ensures bitwise-identical behavior between training and inference." This means the quantization function used during training (simulating 4-bit precision in the forward pass) is exactly the same function used when quantizing the final model for deployment, eliminating the quantization error mismatch that often causes accuracy degradation when deploying quantized models.

3.4.7 Supervised Fine-Tuning and Thinking Modes (Section 3.1)

The SFT phase transforms the base model into an instruction-following assistant with specific interaction patterns optimized for agentic tasks. The SFT corpus covers three categories: General Chat (question answering, writing, role-playing, translation, multi-turn dialogue, long-context interactions), Reasoning (mathematical, programming, and scientific reasoning), and Coding & Agent (frontend and backend engineering code, tool calling, coding agents, search agents, general-purpose agents).

The maximum context length is extended to 202,752 tokens during SFT, and a new chat template supports three thinking characteristics, each addressing a specific limitation of prior models:

Interleaved Thinking: Before every response and every tool call, the model generates a reasoning block (the "thinking" process). This is not the same as chain-of-thought prompting, which adds reasoning only at the beginning. Interleaved thinking means the model reasons before each action throughout a multi-turn interaction — for example, before deciding what file to read, before deciding what search to perform, before deciding what code to write. The benefit is that each action is grounded in fresh reasoning that incorporates the latest observations, rather than being based on a plan made at the start that may be stale. The paper cites this as "first introduced by Claude's extended thinking" and notes it improves "instruction following and the quality of generation."

Preserved Thinking: In coding agent scenarios, the model automatically retains all thinking blocks across multi-turn conversations. Without this, standard chat interfaces either discard thinking blocks between turns (forcing the model to re-derive its reasoning from scratch) or include them in the context (consuming valuable context window space without guarantee of coherence). Preserved thinking means the model can reference its own previous reasoning — "I already determined that the bug is in the authentication module because the error trace shows..." — without re-analyzing from scratch. The paper notes this was "also adopted by Claude since Opus 4.5" and it "reduces information loss and inconsistencies, and is well-suited for long-horizon, complex tasks."

Turn-level Thinking: The model supports per-turn control over reasoning within a session — thinking can be disabled for lightweight requests (e.g., "summarize this paragraph") to reduce latency and cost, and enabled for complex tasks (e.g., "debug this distributed systems failure") to improve accuracy and stability. This is implemented through API-level control, not a model-internal decision, avoiding the risk of the model incorrectly deciding when to think.

Data construction for Coding & Agent SFT: Compared to GLM-4.5, GLM-5 constructs "a large number of execution environments to obtain high-quality trajectories, with particular emphasis on real-world scenarios and long-horizon tasks." The SFT data is further improved using "expert reinforcement learning and rejection sampling" — meaning the training trajectories are generated by a stronger model (possibly an earlier RL-trained version or a teacher model) and filtered to retain only successful trajectories.

A subtle and important training detail: "Erroneous segments within trajectories are retained but masked out in the loss function, allowing the model to learn error correction behaviors without reinforcing incorrect actions." This means the training data might show: [correct action 1] → [incorrect action 2] → [error message] → [corrective action 3], where the model sees the error message and the corrective action in context (learning that errors happen and should be corrected) but the loss is only computed on the corrective action's tokens, not the erroneous action's tokens. Without masking, the model would be trained to produce the incorrect action (since it appears in the training data) which would be actively harmful; with masking, it learns to observe errors and respond appropriately.

3.4.8 Reasoning RL: The IcePop-Based Objective (Section 3.2)

The reasoning RL stage uses a variant of GRPO (Group Relative Policy Optimization) enhanced with the IcePop technique. The core idea of GRPO is group-based advantage normalization: for each prompt, the model generates G responses, computes a reward for each, and normalizes the rewards within the group to compute advantages. This eliminates the need for a separate value function (as in PPO) by using the group statistics as a baseline.

The paper's innovation is incorporating IcePop to handle the training-inference mismatch: when the model used to generate trajectories (the inference policy π_infer) differs from the model being updated (the training policy π_train). This mismatch is inherent in any training setup where generation is decoupled from gradient computation — for example, when rollouts are generated by a slightly older checkpoint or when different sampling parameters are used.

The full optimization loss is:

$L(\theta) = -\mathbb{E}_{x \sim \mathcal{D}, \{\mathbf{y}_i\}_{i=1}^G \sim \pi_{\text{infer}}^{\theta_{\text{old}}}(\cdot|x)} \left[ \frac{1}{G} \sum_{i=1}^G \frac{1}{|\mathbf{y}_i|} \sum_{t=1}^{|\mathbf{y}_i|} \text{pop}(\rho_{i,t}, 1/\beta, \beta) \cdot \min\left( r_{i,t} \hat{A}_{i,t}, \text{clip}(r_{i,t}, 1 - \epsilon_{\text{low}}, 1 + \epsilon_{\text{high}}) \hat{A}_{i,t} \right) \right]$

where:

$x$ is a prompt sampled from the training distribution $\mathcal{D}$
$\{\mathbf{y}_i\}_{i=1}^G$ are $G$ responses (trajectories) generated by the inference policy $\pi_{\text{infer}}^{\theta_{\text{old}}}$ , where $\theta_{\text{old}}$ denotes the policy parameters at the time of generation (not necessarily the current parameters)
$|\mathbf{y}_i|$ is the length of the $i$ -th response in tokens
$\rho_{i,t} = \frac{\pi_{\text{train}}^{\theta_{\text{old}}}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})}{\pi_{\text{infer}}^{\theta_{\text{old}}}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})}$ is the training-inference mismatch ratio at token $t$ of response $i$
$\text{pop}(\rho, 1/\beta, \beta) = \rho$ if $1/\beta \leq \rho \leq \beta$ , and $0$ otherwise
$r_{i,t} = \frac{\pi_{\text{train}}^{\theta}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})}{\pi_{\text{train}}^{\theta_{\text{old}}}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})}$ is the standard PPO importance ratio
$\hat{A}_{i,t} = \frac{R_i - \text{mean}(R_1, \ldots, R_G)}{\text{std}(R_1, \ldots, R_G)}$ is the group-normalized advantage, where $R_i$ is the scalar reward for response $i$
$\epsilon_{\text{low}} = 0.2$ , $\epsilon_{\text{high}} = 0.28$ , and $\beta = 2$ are hyperparameters

What this loss computes, in operational terms:

For each prompt, the model generates G=32 complete responses (the group). Each response receives a scalar reward $R_i$ from a domain-specific judge (e.g., correctness for math, test pass/fail for code). The rewards are normalized to produce advantages $\hat{A}_{i,t}$ — responses better than the group average get positive advantages, worse ones get negative advantages. For each token in each response, the algorithm computes (1) whether the token's probability under the training policy vs inference policy is "reasonable" (within a factor of $\beta=2$ ), (2) the ratio of the current training policy's probability to the old training policy's probability for that token, and (3) clips the ratio to $[0.8, 1.28]$ (asymmetric clipping) to prevent too-large updates. Tokens where the training-inference mismatch is too extreme ( $\rho$ outside $[0.5, 2]$ ) are masked out entirely. The final loss is the average of the clipped importance-weighted advantages over all tokens in all responses in the batch, with a batch size of 32 (so 32 × 32 = 1024 responses per batch).

Why this form:

The pop function suppresses extreme training-inference mismatches. If the training policy would have assigned a very different probability to a token than the inference policy did (e.g., 4× higher or lower), that token's training signal is unreliable because the trajectory was generated under a substantially different distribution than what the training policy represents. Masking these tokens out prevents the model from being optimized based on out-of-distribution data. The choice of $\beta=2$ means the model tolerates up to a 2× difference in probability — a practical threshold that the paper doesn't rigorously ablate but that balances between being too permissive (allowing noisy gradients) and too restrictive (discarding too much data).
The asymmetric clipping ( $\epsilon_{\text{low}}=0.2$ , $\epsilon_{\text{high}}=0.28$ ) provides a slightly wider trust region for increasing probabilities than for decreasing them. This is motivated by the observation that in RL for language models, policy collapse (where the model stops exploring and produces only high-reward but low-diversity outputs) is a more severe failure mode than slow improvement. By allowing slightly larger increases in probability (up to 1.28×) than decreases (down to 0.8×), the algorithm biases toward maintaining diversity while still constraining updates to prevent catastrophic forgetting.
The group-normalized advantage eliminates the need for a learned value function. Standard PPO requires training a separate value network to estimate the expected reward of a state, which is then subtracted from the actual reward to compute advantage. GRPO sidesteps this by using the group mean as the baseline — responses better than average get positive advantage, worse get negative. This is valid because all responses in the group are for the same prompt, so the prompt's inherent difficulty is a shared confound that gets subtracted out. The standard deviation normalization ensures that advantage magnitudes are consistent across groups regardless of reward scale.
Comparison to the original IcePop formulation: The paper removes the KL regularization term — a penalty that discourages the policy from deviating too far from the reference (pre-RL) policy. This is a deliberate choice to "accelerate RL improvement" at the cost of potentially higher risk of reward hacking or capability regression. The paper compensates for this risk through the subsequent On-Policy Cross-Stage Distillation stage (Section 3.5) rather than through KL regularization during RL.

DSA-specific RL considerations: As discussed in the DSA section above, the paper finds that using torch.topk (deterministic) rather than CUDA/TileLang top-k (non-deterministic) is critical for RL stability, and the indexer parameters are frozen during RL to prevent unstable learning.

Mixed domain reasoning RL: The RL training covers four domains — mathematics, science, code, and tool-integrated reasoning (TIR) — in a roughly balanced mixture. For mathematics and science, difficulty filtering is applied to focus on problems that GLM-4.7 "solves correctly only rarely or fails consistently, while remaining solvable by stronger teacher models (e.g., GPT-5.2 xhigh and Gemini 3 Pro Preview)." This ensures that RL provides a meaningful learning signal: the problems are hard enough that the model needs to improve, but not so hard that even optimal behavior can't solve them (which would provide no gradient).

For TIR, a subset of mathematics and science problems is annotated to be solvable with external tools (calculators, symbolic solvers, search), and additional STEM questions are co-built with annotation vendors to explicitly require tool use. The paper reports "stable and significant gains in each domain under the mixed RL setting" — meaning training on all four domains simultaneously is not harmful (no negative transfer) and improves all domains.

3.4.9 Agentic RL: Asynchronous Infrastructure and Algorithms (Section 4.1)

This is the most technically innovative section of the paper, describing the infrastructure that enables RL on long-horizon agent trajectories.

The Group-Wise Policy Optimization objective:

As in reasoning RL, the agentic RL uses group-wise policy optimization. For each problem $x$ , $K$ agent traces $\{\mathbf{y}_1, \ldots, \mathbf{y}_K\}$ are sampled from the previous policy $\pi_{\text{old}}$ . The optimization objective is:

$L(\theta) = \mathbb{E}_{x \sim \mathcal{D}} \left[ \frac{1}{K} \sum_{i=1}^K (r(x, \mathbf{y}_i) - \bar{r}(x)) \right]$

where $\bar{r}(x) = \frac{1}{K} \sum_{i=1}^K r(x, \mathbf{y}_i)$ is the mean reward of the sampled responses, and $r(x, \mathbf{y}_i)$ is the reward for trajectory $i$ .

What this computes: The expected group-normalized reward, averaged over prompts. For each prompt, the model generates $K$ trajectories, each receives a scalar reward (e.g., test pass/fail for coding tasks, answer correctness for search tasks). The mean reward of the group is subtracted from each trajectory's reward, and the difference is used to weight the gradient. Trajectories better than average get positive weight; worse ones get negative weight.

Why this form: The formulation is simpler than the IcePop-based reasoning RL because there's no explicit importance sampling or clipping. The reason is that the agentic RL operates in an off-policy setting (the rollout policy may be different from the current training policy), and the importance sampling corrections are handled separately via the Direct Double-sided Importance Sampling mechanism (described below). Only model-generated tokens are used for optimization — environment feedback (tool outputs, error messages, test results) is not part of the gradient computation, only the reward signal. This avoids the problem of differentiating through non-differentiable environment interactions.

Fully Asynchronous RL Architecture:

The key infrastructure insight is that synchronous RL (where training waits for all rollouts in a batch to complete) creates "substantial bubbles during the rollout stage because of the severely imbalanced generation of agentic tasks." Agentic trajectories can range from tens of tokens (simple tool calls that succeed immediately) to hundreds of thousands of tokens (complex multi-file edits with multiple test-debug cycles). Waiting for the slowest trajectory in every batch means the GPUs generating faster trajectories sit idle.

The solution decouples the training engine and inference engine onto different GPU devices:

Inference engines continuously generate trajectories, running across multiple GPU nodes. Each trajectory is a complete agent interaction: the model receives a task description, makes a series of tool calls (reading files, running commands, editing code), receives environment feedback, and eventually produces a final answer or times out.
A central Multi-Task Rollout Orchestrator coordinates multiple task-specific services, each implementing its own rollout and reward logic as an independent microservice. The orchestrator controls per-task rollout ratios and generation speed to ensure balanced data collection across tasks. Crucially, all trajectories are standardized into a "unified message-list representation," enabling joint training across heterogeneous agent frameworks (software engineering, terminal tasks, search tasks) within a single training run.
When the number of generated trajectories reaches a predefined threshold, the batch is sent to the training engine for gradient computation and model update. The training engine processes the batch and updates model parameters.
Every $K$ gradient updates, the training engine pushes new weights to the inference engines, and the optimizer state is reset. This is because the weight update now considers a "different optimization problem" — the policy generating trajectories has changed, so the old optimizer state (momentum, Adam moments) is no longer valid for the new policy's loss landscape.

This architecture supports "over 1k concurrent rollouts and enables automated, dynamic adjustment of task sampling ratios, as well as fine-grained monitoring of task progress."

Token-in-Token-out (TITO) Gateway:

In standard RL training pipelines, the inference engine produces text output, which the training engine re-tokenizes before computing losses. This "text-in-text-out" paradigm creates subtle but consequential problems:

Re-tokenization mismatches: Different tokenizers, different tokenizer versions, or even different whitespace handling can cause the training engine's tokenization of a response to differ from the exact token sequence the model actually generated during rollout. Even a single token mismatch corrupts the alignment between actions and rewards, since the advantage for a token is computed based on the reward of the response it came from.
Step alignment corruption: In multi-turn agent trajectories, the boundaries between model actions and environment observations must be precisely tracked. If re-tokenization shifts these boundaries (e.g., merging a newline character differently), the training engine might associate a reward with the wrong token, or attempt to compute probabilities for environment-observed tokens (which the model didn't generate).
Streaming complications: Agentic rollouts are often streamed — tokens are generated, executed as tool calls, and results are observed incrementally. Text-in-text-out requires waiting for the complete text to be finalized, losing this temporal structure.

The TITO Gateway solves this by intercepting all generation requests from rollout tasks and recording each trajectory's token IDs and metadata directly. The training engine receives the exact token ID sequence that the inference engine produced, along with metadata about where model-generated tokens begin and end, where environment observations occur, and where tool calls are made. This "isolates the cumbersome token ID processing from downstream agent rollout logic, while avoiding re-tokenization mismatches during RL training."

Direct Double-sided Importance Sampling (DDIS):

In the asynchronous setting, the inference engines may undergo multiple updates during a single trajectory generation. This means the policy that started generating a trajectory may be different from the policy that finished it — and both may differ from the current training policy. Tracking the exact behavior probability $\pi_{\text{old}}$ for importance sampling would require maintaining "an extensive history of model checkpoints $\{\pi_{\theta^{(1)}_{\text{old}}}, \ldots, \pi_{\theta^{(N)}_{\text{old}}}\}$ , which is infeasible in practical implementation."

The DDIS approach makes two simplifications:

Reuse rollout log-probabilities as the behavior proxy. Instead of maintaining a separate old-policy checkpoint, the log-probabilities recorded during rollout are used directly. The importance ratio becomes:

$r_t(\theta) = \exp(\log \pi_\theta(a_t|s_t) - \log \pi_{\text{rollout}}(a_t|s_t))$

where $\pi_{\text{rollout}}$ is whatever policy version happened to be active when that specific token was generated. This introduces off-policy bias — the behavior distribution is not a single clean policy but a mixture over multiple checkpoints — but avoids the computational cost of separate old-policy inference.

Double-sided calibration masking. Instead of PPO's asymmetric clipping (which clips ratios above 1+ε differently from ratios below 1-ε), DDIS applies a symmetric trust region $[1 - \epsilon_\ell, 1 + \epsilon_h]$ and entirely masks tokens whose ratio falls outside this interval:

$f(x; \epsilon_\ell, \epsilon_h) = \begin{cases} x, & \text{if } 1 - \epsilon_\ell < x < 1 + \epsilon_h \\ 0, & \text{otherwise} \end{cases}$

The full optimization objective is:

$L(\theta) = \mathbb{E}_t \left[ f(r_t(\theta), \epsilon_l, \epsilon_h) \hat{A}_t \log \pi_\theta(a_t|s_t) \right]$

Why this form: The symmetric masking is simpler than PPO-style clipping and "shares similarities with the IcePop mechanism" but is further simplified by removing the old-policy $\pi_{\theta_{\text{old}}}$ . The key insight is that in asynchronous training, the "correct" old-policy probability is fundamentally ambiguous (multiple policies contributed), so trying to compute exact importance ratios is both expensive and potentially misleading. Instead, the DDIS approach accepts a controlled degree of off-policy bias and uses aggressive masking to discard tokens where the policy has diverged too far from whatever generated them.

Dropping off-policy and noisy samples:

Two additional filtering mechanisms improve training stability:

Version-based off-policy filtering: For each trajectory, the rollout engine records the sequence of model versions involved. If the oldest version in a trajectory is too stale (more than $\tau$ updates behind the current policy), the entire trajectory is discarded. This removes trajectories generated by policies that have drifted too far from the current policy.
Environment failure filtering: Coding-agent sandboxes can fail for reasons unrelated to the model — environment crashes, Docker build failures, network timeouts. These failures produce noisy rewards (zero reward for reasons the model couldn't control). The paper records the failure reason for each sample and excludes samples that fail due to environment collapse. For group-based methods (GRPO), if removing failed samples leaves an incomplete group, the group is padded by repeating valid samples if more than half the group survived; otherwise, the entire group is dropped.

DP-aware routing for KV-cache reuse:

In multi-turn agentic workloads, sequential requests from the same rollout share an identical prefix (the conversation history up to the current turn). To maximize KV-cache reuse under data parallelism, the paper introduces rollout-level affinity: all requests from a given agent instance are routed to the same data-parallel rank using consistent hashing on the rollout ID.

This "eliminates cross-rank cache misses" — without it, each turn's request might be routed to a different GPU, which would need to recompute the entire prefix from scratch. As rollout length increases, the prefill cost is proportional only to incremental tokens (the new turn's content) rather than the total context length. The paper reports "improved end-to-end latency and higher effective throughput for long-context agentic inference."

To prevent long-term imbalance (some GPUs handling consistently longer rollouts than others), the consistent hashing is combined with "lightweight dynamic load rebalancing over the hash space" — meaning the mapping from rollout IDs to GPUs can be adjusted periodically to redistribute load, but adjustments are infrequent enough to preserve KV-cache locality for most interactions.

3.4.10 General RL: Multi-Dimensional Reward System (Section 3.4)

The General RL stage optimizes the model for human interaction quality across three dimensions:

Foundational correctness targets instruction-following failures, logical inconsistencies, factual inaccuracies, knowledge hallucinations, and language disfluencies. The paper frames this as a prerequisite: "a response containing factual errors or misinterpreting the user's intent can actively mislead the user, no matter how polished it may appear."

Emotional intelligence optimizes for "empathetic, insightful, and stylistically close to natural human communication" responses. This is distinct from correctness — a factually correct response can still be cold, formulaic, or tone-deaf.

Task-specific quality targets fine-grained optimization within specific task categories: writing, text processing, subjective and objective question answering, role-playing, and translation. Each requires distinct reward signals.

Hybrid reward system: The paper integrates three types of reward signals, each with distinct properties:

Rule-based rewards: Deterministic functions that provide precise, interpretable signals for aspects that can be specified as rules (e.g., response length within a range, presence of required sections, adherence to formatting constraints). These are "limited to aspects expressible as deterministic rules" but are immune to reward hacking (since they have no learnable parameters to exploit).
Outcome Reward Models (ORMs): Learned models that predict the quality of a complete response. They offer "low-variance signals and high training efficiency" because they provide a single scalar per response, but are "more susceptible to reward hacking" — the policy can learn to exploit superficial patterns that the ORM associates with high quality without genuinely improving.
Generative Reward Models (GRMs): Language models that produce scalar or structured evaluations. They are "more robust to exploitation" (harder to hack because they understand language at a deeper level) but "tend to exhibit higher variance" (their evaluations are noisier).

By blending these three signal types, the paper claims to "balance precision, efficiency, and robustness, mitigating the weaknesses of any single component" — though exactly how they are blended (weights, ensembling method) is not specified in detail.

Human-in-the-loop style alignment: A distinctive aspect is the explicit incorporation of high-quality human-authored responses as "stylistic and qualitative anchors." The motivation is that "purely model-generated optimization tends to converge toward recognizably 'model-like' patterns — often verbose, formulaic, or lacking the nuance of skilled human writing." By exposing the model to human-written exemplars during RL (presumably as positive examples with high reward or through some form of behavioral cloning auxiliary loss), the model is encouraged to adopt more natural patterns.

3.4.11 On-Policy Cross-Stage Distillation (Section 3.5)

The multi-stage RL pipeline (Reasoning RL → Agentic RL → General RL) sequentially optimizes for different objectives, which can cause "cumulative degradation of previously acquired capabilities." For instance, optimizing for agentic performance might cause the model to lose some reasoning depth, or optimizing for conversational style might degrade coding accuracy.

The solution is a final distillation stage that uses checkpoints from earlier training stages as teachers:

$\hat{A}_{i,t} = \text{sg}\left[ \log \frac{\pi_{\text{infer}}^{\theta_{\text{teacher}}}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})}{\pi_{\text{train}}^{\theta}(\mathbf{y}_{i,t} | x, \mathbf{y}_{i,<t})} \right]$

where sg is the stop-gradient operation (the teacher's log-probability is treated as a constant, not differentiated through), $\theta_{\text{teacher}}$ is the checkpoint from an earlier stage (e.g., the Reasoning RL checkpoint), and $\theta$ is the current model being trained.

What this computes: The log-ratio of the teacher's probability to the student's probability for each token — treating the teacher as the target distribution. When the student assigns lower probability than the teacher to a token, the ratio is large and positive, creating a gradient that pushes the student's probability upward. When the student assigns higher probability, the ratio pushes it downward.

Why this form: This is essentially a distillation loss framed as an advantage in the GRPO objective. The key difference from standard distillation (which minimizes KL divergence) is that it operates on-policy: the student generates its own responses, and the teacher provides probabilities for those same responses. This ensures the student learns from its own output distribution rather than from the teacher's preferred outputs, which is important for maintaining the diversity and style developed during later RL stages.

The group size is set to 1 (no group normalization needed since advantages come from the teacher comparison, not from within-group ranking) and batch size to 1024 to "increase data throughput." Training prompts are sampled from the corresponding teachers' RL training sets and mixed in appropriate proportions. The paper notes that they currently use the inference engine to fetch teacher logits but plan to migrate to using the training engine directly with Multi-Query Attention (MQA) mode of MLA for inference ( $\pi_{\text{infer}}$ → $\pi_{\text{train}}$ ), which would simplify the infrastructure.

3.4.12 The slime RL Training Infrastructure (Section 3.6)

The slime framework is the software infrastructure underlying GLM-5's RL training. Rather than introducing new components, GLM-5 fully leverages slime's capabilities across three dimensions:

Scaling out: flexible rollouts. slime provides a customizable rollout interface that supports multi-turn interaction loops, tool invocation, environment feedback handling, and verifier-guided branching — without requiring task-specific infrastructure forks. The rollout servers and inference router are exposed through standard HTTP APIs, enabling external agent frameworks and environments to interact with slime as they would with any inference engine. This decoupling means the same optimization backend handles both short-horizon single-turn training (reasoning RL) and long-horizon multi-turn trajectories (agentic RL) identically.

Scaling up: tail-latency optimization. For RL rollouts, the optimization target is end-to-end latency — specifically tail latency, since a single slow trajectory stalls the entire batch. The paper describes four specific optimizations:

No-queue serving via multi-node inference with DP-attention. To avoid queuing delays during bursty traffic, rollout requests must be served immediately, requiring substantial KV-cache capacity. Multi-node inference deployment (e.g., EP64 and DP64 over 8 nodes) provisions sufficient distributed KV-cache. DP-attention is introduced "primarily to prevent copying KV across different ranks" — meaning each data-parallel rank maintains its own KV-cache rather than broadcasting it, reducing communication overhead.
FP8 rollouts. Using 8-bit floating point for rollout inference reduces per-token latency, particularly for long trajectories where the compute cost of attention dominates.
MTP for small-batch decoding. Multi-Token Prediction is "especially effective under the small-batch decoding regime typical in RL rollouts." RL rollouts typically involve many independent trajectories generated in parallel, each with batch size 1 at decode time (generating one token at a time). In this regime, MTP's ability to predict multiple future tokens in one forward pass provides "disproportionately large benefits on the long tail" — reducing the completion time of the slowest samples.
Prefill-Decode (PD) disaggregation. In multi-turn agentic settings, long-prefix prefills are frequent (conversation history, tool traces, code context). Mixing prefill and decode on the same GPUs creates interference: a computationally heavy prefill can preempt or slow down ongoing decodes, causing some trajectories to stall. PD disaggregation runs prefills and decodes on dedicated resources, ensuring decodes "remain stable and uninterrupted, enabling long-horizon samples to progress continuously."

Rollout robustness: heartbeat-driven fault tolerance. At scale, transient failures (server crashes, network issues, performance degradation) are inevitable. slime's rollout servers periodically emit heartbeats monitored by the orchestration layer. Unhealthy servers are proactively terminated and deregistered from the inference router, and retries are automatically routed to healthy servers. This prevents single-server incidents from interrupting rollouts — a critical feature when training runs may last days or weeks across hundreds of GPUs.

3.4.13 Agentic Environment Scaling (Section 4.2)

RL for agentic tasks requires environments that provide verifiable, executable feedback. The paper constructs environments across four domains:

Software Engineering (SWE) Environments:

The pipeline begins with collecting real-world Issue-Pull Request pairs, applying rule-based and LLM-based filtering to ensure "authentic, high-quality issue statements." Instances are categorized into task types: bug fixing, feature implementation, refactoring, and others.

The RepoLaunch framework automates environment construction: analyzing a repository's installation and dependency setup to build an executable Docker environment, generating test commands, and using LLMs to "generate language-aware log-parsing functions from test outputs, enabling the extraction of Fail-to-Pass (F2P) and Pass-to-Pass (P2P) test cases." F2P tests are those that fail before the fix and pass after; P2P tests pass both before and after, serving as regression checks.

The pipeline constructs "over 10k verifiable environments across thousands of repositories spanning 9 programming languages: Python, Java, Go, C, CPP, JavaScript, TypeScript, PHP, and Ruby." The scale and language diversity are critical: if the training environments are too similar (e.g., only Python web frameworks), the model overfits to specific patterns and fails to generalize to new languages or project structures.

Terminal Environments:

Two synthesis pipelines produce terminal tasks:

Seed-based synthesis: Starting from seed tasks (real-world software engineering and terminal-based computer-use scenarios), an LLM brainstorms a large pool of task drafts. A construction agent instantiates them into Harbor format (structured task descriptions, Dockerized environments, test scripts). A refine agent iteratively improves tasks according to manually defined rubrics, ensuring Docker images build reliably and tests are consistent with specifications. The pipeline yields "thousands of diverse and verifiable terminal-agent environments with Docker construction accuracy exceeding 90%."
Web-corpus synthesis: A scalable pipeline mines code-relevant web pages, filters for quality, and identifies pages amenable to terminal-style task formulation. A coding agent is prompted with the Harbor specification and each source page, synthesizing a complete terminal task, executing the Harbor validation script against its own output, and iteratively diagnosing and revising until all automated checks pass. Only tasks that clear this self-verification loop are admitted — a design that "uses a closed-loop design where the constructing agent also serves as its own first-pass evaluator."

Search Tasks:

The data synthesis pipeline produces challenging multi-hop question-answering pairs requiring evidence aggregation from multiple web sources:

Web Knowledge Graph (WKG) construction: From early-stage search agent trajectories, all encountered URLs are collected and deduplicated, retaining over two million high-information web pages. An LLM performs entity recognition, noise filtering, and structured information extraction, producing a knowledge graph. The WKG is continuously updated with new pages and refined using downstream verification signals — entity alignment, attribute normalization, relation consolidation, and semantic-consistency corrections.
Question generation: Low- to mid-frequency entities are sampled as seed nodes, and their multi-hop neighborhoods are expanded to form complete subgraphs. Using prompts targeting high-difficulty, multi-domain reasoning, each subgraph is converted into a question that implicitly encodes multi-entity relational chains.
High-difficulty filtering and verification: A three-stage pipeline ensures difficulty and correctness: (a) remove questions solvable by a tool-free reasoning model in at least one of eight independent attempts, (b) filter out questions solvable by an early-stage search agent within a few steps, and (c) apply a verification agent for bidirectional validation — collecting candidate answers from search trajectories and independently verifying question-answer consistency, rejecting samples with non-unique answers, inconsistent evidence, or incorrect labels.

Slide Generation:

A self-improving pipeline trains a specialized slide-generation expert using RL and rejection sampling fine-tuning. The model is initialized with SFT and then optimized using a multi-level reward formulation:

Level-1 (Static markup attributes): Rules grounded in professional design principles regulate positioning, spacing, color, typography, saturation, and other stylistic attributes. Hallucinated-image and duplicate-image detection mechanisms suppress redundant figures.
Level-2 (Runtime rendering properties): A distributed rendering service evaluates geometric properties (element dimensions, bounding boxes) at runtime, catching issues invisible to static analysis. The paper notes they discovered reward hacking behaviors where the model "hard truncates overlong content" or "excessively manipulates spacing" to satisfy geometric constraints without genuine aesthetic quality. The renderer is refined to eliminate these loopholes.
Level-3 (Visual perceptual features): Auxiliary signals from abnormal whitespace detection and similar heuristics improve compositional balance beyond what geometric metrics can capture.

Training employs dynamic sampling (dropping a fraction of structurally trivial samples to focus on challenging pages), token-level policy gradient loss, and a balancing strategy that distributes different rollout outcomes of the same sample across multiple batches.

After RL, rejection sampling filters trajectories: at the page level, filtering for code validity and compilation feasibility; at the trajectory level, enforcing tool execution correctness and global content diversity. A Best-of-N selection strategy retains the highest-quality sample from multiple candidates. Masking-based refinement preserves trajectories with isolated defects by masking defective pages while retaining the rest.

The paper reports that the proportion of generated pages strictly complying with the 16:9 aspect ratio increases from 40% to 92%, and human evaluation shows GLM-5 achieving win rates of 60% in content quality, 57.5% in layout rationality, and 65% in visual aesthetics over GLM-4.5, with an overall win rate of 67.5%.

3.4.14 Inference-Time Context Management for Search Agents (Section 4.2.4)

Beyond training, the paper identifies context management as a critical inference-time factor for search agent performance.

The problem: Model accuracy "degrades substantially under extremely long contexts (e.g., beyond 100k tokens)" — common in search agents that browse dozens of web pages, accumulating observation tokens.

Keep-recent-k strategy: When the interaction history exceeds k rounds, the content older than the most recent k rounds is folded. The trajectory has the form: question q, followed by rounds of reasoning r_i, action a_i, and observation o_i. For observations earlier than n-k (where n is the current round), the observation is replaced with a placeholder "Tool result is omitted to save tokens." This preserves the model's own reasoning and the most recent context while freeing space by compressing old observations.

With k=5, BrowseComp performance improves from 55.3% to 62.0% — a 6.7-point gain purely from inference-time context management, no model retraining needed.

Hybrid Hierarchical Context Management (HCM): building on keep-recent, if total context length exceeds a threshold T=32k, the entire tool-call history is discarded (discard-all) and the agent restarts with a fresh context, while continuing to apply keep-recent. This addresses cases where even compressed history becomes too long. T=32k was selected via parameter search.

Figure 8 shows this strategy consistently outperforms discard-all alone across all compute budgets, reaching 75.9 on BrowseComp — the highest among all models with context management. The strategy works because it frees context space, enabling the model to execute more browsing steps before hitting context limits, which directly translates to more thorough information gathering.

4. Key Insights and Innovations

Innovation 1: Agentic Endurance, Not Raw Reasoning, Is the Real Bottleneck for LLM Utility

The paper's most fundamental intellectual contribution is not any single architectural trick but a reframing of what constitutes meaningful LLM progress. The field has largely converged on reasoning benchmarks (AIME, GPQA, HLE) and short-form coding (HumanEval, LiveCodeBench) as the primary yardsticks of improvement. GLM-5 challenges this framing by arguing—through its evaluation design rather than explicit claims—that the true bottleneck has shifted from capability per token to capability sustained over time.

This reframing is not merely rhetorical. The evidence in Table 7 shows that GLM-5, Kimi K2.5, and Claude Opus 4.5 cluster tightly on reasoning metrics: AIME 2026 I scores of 92.7, 92.5, and 93.3 respectively; GPQA-Diamond scores of 86.0, 87.6, and 87.0. These differences are marginal and likely within statistical noise for single-run evaluations. Yet on Vending-Bench 2—where models run a simulated business over a year of sequential decisions—the gaps are categorical: GLM-5 achieves $4,432, Kimi K2.5 achieves$ 1,198, and Claude Opus 4.5 achieves $4,967. The 3.7× gap between Kimi K2.5 and GLM-5 on this metric cannot be explained by reasoning ability, since Kimi K2.5 essentially matches or exceeds GLM-5 on short-form reasoning. It can only be explained by something else: the ability to maintain coherent goal-tracking, resist compounding errors, and adapt plans across dozens of sequential decisions without human intervention.

The paper gives this "something else" a name—agentic engineering—and positions it as a distinct capability axis orthogonal to reasoning depth. This is a significant conceptual move because it implies that scaling reasoning RL alone (as in Kimi K2.5, which reports strong math/code RL results) will asymptotically fail to produce useful autonomous agents. The capability requires its own training paradigm (long-horizon agentic RL with environment feedback), its own architectural support (long-context attention that doesn't degrade), and its own evaluation methodology (chained tasks, multi-step business simulations, repository-scale exploration). The paper does not prove this orthogonality formally—it's an empirical observation, not a theorem—but the pattern across Tables 7, 8, and 9 is consistent enough to be persuasive.

What distinguishes this from the obvious claim that "long-horizon tasks are harder" is the specific diagnostic finding that errors compound across sequential commits, revealed by CC-Bench-V2's chained task evaluation. Table 8 shows that GLM-5 achieves 52.3% pass@1 on chained tasks while Claude Opus 4.5 achieves 61.6%, compared to a much closer 25.8% vs. 26.9% on isolated backend tasks. The gap emerges specifically from the sequential dependency structure: "a suboptimal edit in one task can silently break tests in subsequent tasks." This suggests that the core failure mode isn't inability to write correct code (both models do that comparably on single tasks) but inability to maintain a coherent model of the codebase state across multiple modifications. This is a qualitatively different skill than reasoning or code generation—it's closer to working memory and state tracking over extended horizons—and the paper's evaluation framework makes it visible for the first time at this scale.

Innovation 2: Asynchronous Agentic RL as a First-Class Training Paradigm, Not an Infrastructure Hack

Prior to this work, the dominant approach to training LLMs for multi-turn agent behavior was supervised fine-tuning on static trajectories (GLM-4.5, GPT-4's tool-use demonstrations) or synchronous RL on short-horizon tasks (DeepSeekMath's GRPO, reasoning RL in most open-source efforts). The paper's asynchronous agentic RL infrastructure is not merely an engineering optimization to speed up training—it represents a qualitatively different training paradigm that enables learning from trajectory distributions inaccessible to synchronous methods.

The conceptual distinction hinges on what "training on long-horizon tasks" actually requires. In synchronous RL, the computation graph for a training step must span the entire rollout: the model generates a complete trajectory, computes rewards, and backpropagates through the policy's decisions. When trajectories vary in length by 10× or more (as they do in real agentic tasks), the synchronization barrier means that training throughput is gated by the slowest trajectory in every batch. This is not fixable by adding more GPUs in the standard way—more parallel workers just means more idle workers waiting for the straggler. The consequence, unstated but implied by the paper's framing, is that synchronous RL creates a de facto upper bound on trajectory length complexity that can be used for training: beyond some threshold, the idle time makes training economically infeasible regardless of the scientific desirability of learning from longer trajectories.

The asynchronous design (Section 4.1.1) breaks this coupling by treating trajectory generation and gradient computation as independent, loosely synchronized processes. The inference engines generate continuously; the training engine consumes completed trajectories as they arrive; model weights synchronize periodically but not per-batch. This means the training engine is never idle waiting for a single straggler—it processes whatever is available. The conceptual leap is recognizing that the off-policy bias introduced by this asynchrony is an acceptable cost for accessing longer, more diverse trajectories, and that this bias can be managed through algorithmic innovations rather than eliminated through synchronization.

The paper doesn't frame it this way, but this represents a shift from process-level RL (where the optimization objective is defined over a single, coherent policy) to population-level RL (where the optimization objective is defined over a mixture of policies, each contributing partial trajectories). The Direct Double-sided Importance Sampling algorithm (Section 4.1.2) is the specific mechanism that makes this shift viable: by discarding the traditional old-policy probability π_θold and instead using rollout log-probabilities as a direct behavior proxy, and by applying symmetric token-level masking rather than asymmetric clipping, the algorithm accepts that the "behavior policy" is not a single entity but a temporal mixture. This is a fundamentally different conceptualization of off-policy RL than the standard importance-sampling-with-clipping framework inherited from PPO, and it enables training at scales that would be impossible under the standard paradigm.

The significance extends beyond GLM-5's specific implementation. The paper's architecture—a central Multi-Task Rollout Orchestrator with registered task-specific microservices (Section 4.1.1), standardized message-list trajectory representations, and the Token-in-Token-out gateway—provides a blueprint for how agentic RL should be done at scale. Prior open-source RL frameworks (TRL, OpenRLHF, veRL) were designed for single-turn or short-horizon tasks and would require fundamental restructuring to support the decoupled, multi-framework, long-horizon workflow that GLM-5 implements. The paper's contribution is thus as much a systems architecture for agentic training as it is a specific model or algorithm.

Innovation 3: DSA Demonstrates That Lossless Sparsity Is Possible—and That It's the Exception, Not the Rule

The paper's ablation study of efficient attention variants (Section 2.1.2, Tables 4–6) makes a contribution beyond justifying DSA as an architectural choice: it provides systematic evidence that all attention mechanisms which compress or truncate information incur an irreducible accuracy penalty on retrieval tasks, while selective (sparse but exact) attention can be lossless. This is not a theoretical result—it's an empirical finding with practical consequences for how the field should think about scaling to long contexts.

Prior work on efficient attention had produced a confusing picture. Sliding window attention (Beltagy et al., 2020; Child et al., 2019) showed that many tasks don't require full attention, but its failures on long-range retrieval were undocumented in systematic comparisons at 128K scale. Linear attention variants (Katharopoulos et al., 2020; Yang et al., 2024) offered asymptotic efficiency but mixed quality results. The dominant assumption—implicit in the proliferation of "efficient attention" papers—was that compression-based methods could eventually match dense attention with enough training data and clever architectural design.

GLM-5's ablation challenges this assumption directly. Even with half the layers retaining full attention and the other half using the best-performing efficient variant (SimpleGDN, which maximally reuses pre-trained weights), the accuracy gap on RULER@128K is 8.25 points (Table 5). This gap is not eliminated by training on 190B tokens of long-context data. The paper's interpretation—that the gap reflects "unavoidable information loss introduced by efficient attention mechanisms during continual-training adaptation"—is a strong claim: it suggests that compression-based methods have a fundamental ceiling that cannot be overcome by scale, because the compression operation (whether linear recurrence, low-rank projection, or windowing) discards information that some queries genuinely need.

DSA avoids this ceiling by being selective rather than compressive. The indexer chooses which key-value pairs to attend to, but the attention computation on those pairs is exact—the same mathematical operation as dense attention. The key insight is that this selection can be learned to be nearly as accurate as full attention (Table 6: 0.35-point deficit at 128K after 150B tokens of joint training) while reducing computation by 1.5–2×. The paper's demonstration that the indexer can be trained via continued pre-training from a dense checkpoint (rather than from scratch) makes this practical at scale.

The significance of this finding is that it redirects the efficient attention research agenda away from compression and toward learned sparsity. If compression has a fundamental accuracy ceiling, then the path to long-context efficiency lies in better indexers (selection mechanisms), not better compressors. The paper's comparison of DSA against SWA, GDN, and SimpleGDN provides the empirical basis for this redirection, even though the DSA concept itself originated in DeepSeek-V3.2. GLM-5's contribution is the comprehensive ablation that establishes why DSA is categorically different, not just incrementally better.

Innovation 4: Context Management as a First-Class Agent Capability, Not a Deployment Afterthought

The paper's findings on context management for search agents (Section 4.2.4, Figure 8) might appear minor—a 6.7-point improvement from a simple heuristic, notable but not groundbreaking. But the intellectual contribution is subtler: the paper demonstrates that context management strategy is not merely a deployment optimization but a capability that interacts with model quality in non-trivial ways, and that the interaction is model-dependent.

The evidence for model-dependence comes from comparing GLM-5's BrowseComp trajectory to prior work. DeepSeek-V3.2 and Kimi K2.5 both employ discard-all strategies (resetting context entirely when it exceeds a threshold), achieving 67.6 and 74.9 respectively with context management. GLM-5's keep-recent-k strategy achieves 62.0 without full context reset, and the hybrid HCM strategy reaches 75.9. The key observation is not the absolute numbers but the shape of the improvement curve in Figure 8: keep-recent-k alone provides a substantial gain over unmanaged context (62.0 vs. 55.3), and layering discard-all on top (HCM) provides further gains at higher budgets by enabling more browsing steps. This suggests that context management operates through at least two mechanisms—preserving recent reasoning coherence (via keep-recent) and preventing catastrophic context overload (via discard-all)—and that these mechanisms are complementary rather than redundant.

Why does this rise to the level of an innovation rather than an implementation detail? Because it reveals a blind spot in how the field evaluates language agents. Standard agent benchmarks typically control for the agent framework and environment but treat context management as an implementation detail—assume infinite context or a fixed truncation strategy. The paper shows that this assumption is consequential: a model evaluated without context management may appear substantially worse than the same model with context management, and—more importantly—the optimal context management strategy may differ across models depending on their sensitivity to context length, their ability to recover from context resets, and their reasoning coherence over long horizons.

This finding connects to the broader agentic endurance thesis (Innovation 1). If agent performance on long-horizon tasks is bottlenecked by working memory and state tracking rather than raw reasoning, then context management is not a post-hoc optimization but a core architectural consideration in agent design. The paper's Hybrid Hierarchical Context Management strategy is a specific instantiation of this principle, but the broader implication is that future agent evaluations should treat context management as a first-class variable to be reported and ablated, not a fixed implementation choice.

5. Experimental Analysis

Evaluation Methodology

Dataset. The primary benchmarks span three categories: Reasoning & General (Humanity's Last Exam text-only subset [34], AIME 2026 I, HMMT Feb/Nov 2025, IMO-AnswerBench [29], GPQA-Diamond [39], LongBench v2 [5]); Coding (SWE-bench Verified [19], SWE-bench Multilingual [53], Terminal-Bench 2.0 [45], CyberGym [48]); Agentic (BrowseComp [50] and BrowseComp-ZH [63], τ²-Bench [55; 7], MCP-Atlas public 500-task set [6], Tool-Decathlon [22], Vending-Bench 2 [3], GDPval-AA [33]). The paper also introduces CC-Bench-V2, an internal suite for frontend (220 tasks across HTML/React/Vue/Svelte/Next.js), backend (85 tasks in 6 languages), and long-horizon (repo exploration + chained multi-commit tasks) evaluation. SWE-rebench [4], a continuously mined, decontaminated SWE evaluation constructed after SWE-bench Verified had been public for over two years, is used for temporal robustness checking. For reasoning tasks, the default maximum generation length is 131,072 tokens (temperature = 1.0, top_p = 0.95), extended to 202,752 tokens for HLE-with-tools and SFT; coding tasks use temperature = 0.7, top_p = 0.95, max_new_tokens = 16,384 (SWE-bench) or 8,192/65,536 (Terminal-Bench variants), with timeouts ranging from 10 minutes (MCP-Atlas) to 250 minutes (CyberGym).
Base model(s). All results are for the fully post-trained GLM-5 model (744B total parameters, 40B active, derived from the GLM series). Comparisons are against GLM-4.7 (the immediate predecessor), DeepSeek-V3.2 [26], Kimi K2.5 [43], Claude Opus 4.5 [1], Gemini 3 Pro [8], and GPT-5.2 (xhigh) [32] — a mix of open-weight and proprietary frontier models. The base model evaluations (Table 11 in Appendix B.1) show GLM-5-Base at 40B active parameters against DeepSeek-V3-Base (37B active), Kimi-K2-Base (32B active), and GLM-4.5-Base (32B active), establishing the pre-training improvement before post-training.
Metrics. The paper uses task-specific metrics: accuracy for reasoning benchmarks (fraction of questions with correct final answers, graded by domain-specific judges — GPT-5.2 medium for HLE, automated checking for AIME/HMMT/IMO-AnswerBench/GPQA); resolved rate for SWE-bench variants (fraction of GitHub issues where all tests pass after the agent's patch is applied); pass@1 for SWE-rebench; score for BrowseComp (binary correctness of the final answer); success rate for MCP-Atlas; account balance in dollars for Vending-Bench 2; Elo ratings for GDPval-AA and LMArena; and for CC-Bench-V2, Build Success Rate (BSR — fraction of projects that initialize and run), Instance Success Rate (ISR — fraction of projects passing all specifications), Check-item Success Rate (CSR — fraction of individual requirements met), and pass@1 for backend and long-horizon tasks. For long-context base model evaluation (Section 2.1.2), metrics include RULER (aggregate score across retrieval tasks), MRCR (multi-round coreference resolution accuracy), HELMET-ICL (in-context learning benchmark score), and RepoQA (code retrieval accuracy).
Baselines. The paper compares against both open-weight models (GLM-4.7, DeepSeek-V3.2, Kimi K2.5) and proprietary models (Claude Opus 4.5, Gemini 3 Pro, GPT-5.2 xhigh). For SWE-bench Verified and Multilingual, the OpenHands framework is used with a tailored instruction prompt for GLM-5, while proprietary models use their standard configurations. For Terminal-Bench 2.0, two agent harnesses are used (Terminus-2 and Claude Code 2.1.14/2.1.18) to assess robustness across frameworks. For BrowseComp, the discard-all strategy (used by DeepSeek-V3.2 and Kimi K2.5) serves as a context management baseline against GLM-5's keep-recent-k and hybrid HCM. For MCP-Atlas, all models are re-evaluated on the public 500-task set with a 10-minute timeout (extended from the original 4 minutes) to avoid deployment-condition failures. For τ²-Bench, domain fixes from the Claude Opus 4.5 system card are applied to the Airline domain and small prompt adjustments are added for Retail and Telecom to avoid premature user termination failures. For frontend evaluation, Claude Opus 4.5 provides the primary baseline; for backend, GLM-4.7 and Claude Opus 4.5; for long-horizon, the same plus GLM-4.7 on repo exploration and chained tasks. For long-context attention ablation (Section 2.1.2), a GLM-9B model with full attention across all 40 layers serves as the dense baseline, continuously trained on 190B tokens at 64K context for fair comparison against efficient variants.
Generation budget / compute accounting. For most benchmarks, compute is not explicitly budgeted — models are evaluated at fixed sampling parameters (temperature, top_p) with a fixed number of generations (typically pass@1 or pass@K with K specified). The BrowseComp results with context management include a compute budget axis in Figure 8 (measured in "steps" — the number of browsing actions executed), showing accuracy as a function of allowed computation. For agentic RL training, the generation budget is implicitly the number of concurrent rollouts (over 1k supported by the Multi-Task Rollout Orchestrator), with throughput determined by the asynchronous decoupling of inference and training engines. For the DSA continued pre-training, the budget is 20B tokens for the sparse adaptation phase and 150B tokens for the small-scale GLM-4.7-Flash verification experiment. For the efficient attention ablation, all variants are continually trained on 190B tokens at 64K context for fair comparison. The slime RL infrastructure reports batch sizes (32 for reasoning RL, variable for agentic RL to reach predefined trajectory thresholds), group sizes (32 for reasoning RL GRPO, K for agentic RL), and weight synchronization intervals (every K gradient updates for agentic RL).
Cross-validation / statistical protocol. No formal cross-validation is described for the main benchmark results — Table 7 reports single-run accuracy scores without confidence intervals. For Terminal-Bench 2.0, scores are averaged over 5 runs with Claude Code to reduce variance. For CC-Bench-V2 long-horizon tasks, pass@1 is "averaged over three runs" for repo exploration. For SWE-rebench (Table 9), the paper reports both Resolved Rate and "Resolved Rate SEM" (standard error of the mean, presumably from the benchmark's own multi-run protocol), with Pass@5 also provided. The MCP-Atlas re-evaluation explicitly extends timeout to 10 minutes to eliminate task failures from deployment conditions rather than model capability — a form of environmental robustness check. The frontend evaluation's Agent-as-a-Judge is validated against human expert judgments: for point-wise consistency, 130 check-items were independently scored by human experts and the judge agent, achieving 94% agreement (disagreements concentrated on subjective visual-quality criteria); for ranking consistency, 8 frontier models were evaluated by both the automated framework and human experts, yielding a Spearman correlation of 85.7%. For the efficient attention ablation, the SWA pattern is discovered via beam search at 16K context length (beam size 8, two layers per step, ~10 steps for 40 layers) and then applied uniformly at all context lengths — a cross-validation of the pattern's length generalization, though the paper does not report a separate validation set for the search procedure.

Main Quantitative Results

Base Model Performance (Pre-Training)

The base model evaluation (Appendix B.1, Table 11) establishes the raw capability before post-training. GLM-5-Base (40B active parameters) improves over GLM-4.5-Base (32B active) on English: SimpleQA EM from 30.0 to 36.0, MMLU from 86.1 to 88.3; on Code: EvalPlus Pass@1 from 78.1 to 87.0, LiveCodeBench-Base from 28.1 to 34.4; and on Chinese: C-Eval from 86.9 to 88.8, Chinese-SimpleQA from 70.1 to 74.6. Interestingly, math benchmarks show lower scores compared to GLM-4.5-Base: GSM8K drops from 79.4 to 68.8, MATH from 61.0 to 56.4. The paper does not discuss this regression explicitly, but it may reflect the different pre-training data composition (heavier code and web emphasis) that is later compensated by post-training RL. Against DeepSeek-V3-Base (37B active), GLM-5-Base achieves higher SimpleQA (36.0 vs. 26.6), EvalPlus (87.0 vs. 65.6), and comparable MMLU (88.3 vs. 87.2). Against Kimi-K2-Base (32B active), GLM-5-Base leads on EvalPlus (87.0 vs. 80.3) and LiveCodeBench (34.4 vs. 26.3) but trails on GSM8K (68.8 vs. 92.1) and MATH (56.4 vs. 70.2), consistent with Kimi-K2's math-focused pre-training.

Attention Architecture Ablation: GQA vs. MLA vs. MLA Variants

Table 1 (Section 2.1) compares GQA-8 (2048-dimension KV-cache) with three MLA variants on a set of 7 benchmarks at the architecture design stage. GQA-8 achieves 53.3 on BBH and 38.5 on HumanEval. Standard MLA with a 576-dimension latent KV-cache underperforms: 48.9 on BBH (down 4.4) and 33.5 on HumanEval (down 5.0). Applying Muon Split — splitting up-projection matrices into per-head blocks before orthogonalization — recovers most of the gap: BBH improves to 51.8, HumanEval to 36.7, and MMLU actually exceeds GQA-8 (62.5 vs. 61.2). The MLA-256 variant (increased head dimension to 256, reduced head count by 1/3 to decrease decoding computation) matches Muon Split performance: BBH 51.3, HumanEval 36.6, GSM8K 47.5 (slightly higher than Muon Split's 45.0). The paper notes that MLA-256 keeps training computation and parameter count constant while reducing decoding cost compared to standard MLA — the tradeoff is between per-head dimension (which affects both training FLOPs and decoding dot-product cost) and number of heads (which affects parallelism). The decision to use MLA-256 reflects the specific hardware roofline (compute-to-memory-bandwidth ratio) of the training GPUs.

Efficient Attention Ablation: Sliding Window and Linear Attention

Tables 4-6 (Section 2.1.2) provide a systematic comparison using the GLM-9B baseline (40 layers, full attention, fine-tuned at 128K context). Table 4 evaluates SWA variants without additional training, measuring the immediate performance drop from converting layers to sliding window (4096-token window, 1:1 ratio of full-attention to SWA layers):

GLM-9B Full Attention on RULER: 95.19 (4K), 93.67 (8K), 92.01 (16K), 91.09 (32K), 85.35 (64K), 75.28 (128K)
SWA Interleave (fixed alternating pattern): 94.87 (4K) — essentially matching at short context — then catastrophic collapse: 54.02 (8K), 25.89 (16K), 12.61 (32K), 8.32 (64K), 6.51 (128K). The 75.28 → 6.51 drop at 128K represents a 91.4% relative degradation.
SWA Pattern (beam-search-optimized layer placement): 95.78 (4K), 92.54 (8K), 88.92 (16K), 82.52 (32K), 70.23 (64K), 53.95 (128K). While still degraded relative to full attention, this preserves substantially more performance — at 128K, the gap is 21.33 points vs. 68.77 points for SWA Interleave. Crucially, the pattern was optimized only at 16K but generalizes reasonably to all context lengths, suggesting that layer placement for long-range retrieval is a structural property of the architecture rather than a context-length-specific choice.

Table 5 presents results after continual training on 190B tokens at 64K context for the most capable variants, with ∆@64K and ∆@128K showing the gap relative to the full-attention baseline:

SWA Interleave: RULER drops 19.41 at 64K and 30.35 at 128K; RepoQA drops 18.67 and 26.50. Even with training, the fixed interleaving is fundamentally broken for retrieval.
SWA Pattern: RULER drops only 1.63 at 64K and 5.69 at 128K — a substantial improvement from no-training performance, showing that the search-based placement effectively identifies which layers need full attention. However, RepoQA still drops 6.67 at 64K and 14.66 at 128K — the task-specific retrieval demands of code (finding specific function definitions across files) are harder for SWA than the synthetic retrieval in RULER.
GDN (Gated DeltaNet): RULER drops 8.59 at 64K and 11.28 at 128K; MRCR drops 4.81 and 5.17. GDN is better than SWA Pattern on RepoQA (3.50 drop at 64K vs. 6.67) but worse on RULER at 64K (8.59 vs. 1.63), suggesting that linear recurrence's compression is more suitable for code retrieval (where attention patterns may be more predictable) than for the diverse retrieval tasks in RULER.
SimpleGDN: RULER drops 3.59 at 64K and 8.25 at 128K — the best among efficient variants on RULER at 64K, though still worse than SWA Pattern at that context length. Notably, on HELMET-ICL at 128K, SimpleGDN actually improves over full attention by 4.48 points (81.84 vs. 77.36), a finding the paper does not explain in depth but may reflect linear attention's inductive bias acting as a beneficial regularizer for in-context learning tasks.

The key conclusion from Table 5: all efficient attention variants that compress or truncate information incur an irreducible accuracy gap on fine-grained retrieval, even after substantial continual training and with half the layers retaining full attention. The gap ranges from 1.63 to 11.28 points on RULER at 64K depending on the method and is always larger at 128K.

Table 6 provides the DSA verification on GLM-4.7-Flash (a smaller model with MLA) to contrast against these findings:

GLM-4.7-Flash baseline: RULER scores of 97.44 (4K), 96.72 (8K), 95.83 (16K), 92.96 (32K), 85.34 (64K), 79.21 (128K)
DSA warmup only (indexer trained for 1000 steps, base model frozen): 97.51 (4K), 96.54 (8K), 95.40 (16K), 90.09 (32K), 84.05 (64K), 71.35 (128K). The drop is modest and concentrated at the longest context — the indexer, even without joint training, largely preserves short-context performance.
DSA full (joint training for 150B tokens): 96.77 (4K), 96.25 (8K), 96.69 (16K), 93.45 (32K), 87.06 (64K), 78.86 (128K). At 16K, DSA surpasses the baseline (+0.86); at 32K (+0.49) and 64K (+1.72); at 128K, the deficit is only 0.35 points.

The contrast with Table 5 is stark: after sufficient joint training, DSA is essentially lossless (0.35-point deficit at 128K vs. 5.69 for the best SWA variant, 8.25 for SimpleGDN), while providing the same 1.5-2× computation reduction. This validates the paper's claim that DSA's selective (sparse but exact) attention is qualitatively different from compressive (windowed or linear) attention, enabling application to all layers without the irreducible accuracy penalty.

Reasoning and General Benchmarks (Post-Training)

Table 7 presents the main results across all models. For HLE (Humanity's Last Exam), GLM-5 achieves 30.5 (text-only) and 50.4 (with tools), compared to GLM-4.7's 24.8 and 42.8 — improvements of 5.7 and 7.6 points respectively. Against open-source models, GLM-5 slightly trails Kimi K2.5 (31.5 text, 51.8 with tools) but exceeds DeepSeek-V3.2 (25.1, 40.8). Against proprietary models, it surpasses Claude Opus 4.5 (28.4 text, 43.4* with tools — asterisk indicating full-set evaluation rather than text-only) and Gemini 3 Pro (37.2 text, 45.8* with tools) on HLE-with-tools, though GPT-5.2 xhigh leads at 35.4 text and 45.5* with tools.

For math benchmarks, the field is tightly clustered: on AIME 2026 I, all models score between 90.6 (Gemini 3 Pro) and 93.3 (Claude Opus 4.5), with GLM-5 at 92.7; on HMMT Feb 2025, GLM-5 achieves 97.9 — the second-highest behind GPT-5.2 xhigh (99.4) and above Claude Opus 4.5 (92.9), Gemini 3 Pro (97.3), and Kimi K2.5 (95.4); on HMMT Nov 2025, GLM-5 at 96.9 is again second to GPT-5.2 xhigh (97.1). The IMO-AnswerBench (82.5) and GPQA-Diamond (86.0) results place GLM-5 in the middle of the frontier pack, slightly trailing Kimi K2.5 on GPQA (87.6) and Gemini 3 Pro on IMO-AnswerBench (83.3).

On LongBench v2 — the long-context reasoning benchmark — GLM-5 achieves 64.5, the highest among open-source models and competitive with Claude Opus 4.5 (64.4), though trailing Gemini 3 Pro (68.2). This is a significant improvement from GLM-4.7's 59.1 (+5.4 points) and demonstrates the impact of the 200K mid-training stage and DSA architecture on sustained long-context reasoning — a capability directly relevant to agentic tasks that require reasoning over large codebases.

Coding Benchmarks

On SWE-bench Verified, GLM-5 achieves 77.8%, improving from GLM-4.7's 73.8% and exceeding DeepSeek-V3.2 (73.1%), Kimi K2.5 (76.8%), and Gemini 3 Pro (76.2%). It trails Claude Opus 4.5 (80.9%) and GPT-5.2 xhigh (80.0%) by approximately 2-3 points — a relatively small gap considering the parameter count difference (744B vs. undisclosed for Claude/GPT-5.2). On SWE-bench Multilingual, GLM-5 achieves 73.3%, outperforming DeepSeek-V3.2 (70.2%), Kimi K2.5 (73.0%), Gemini 3 Pro (65.0%), and GPT-5.2 xhigh (72.0%), but trailing Claude Opus 4.5 (77.5%). The multilingual result is notable because it covers 9 programming languages (Python, Java, Go, C, CPP, JavaScript, TypeScript, PHP, Ruby — the same set as the training environments in Section 4.2.1), suggesting that the language-diverse SWE environment scaling during agentic RL directly contributes to this capability.

Terminal-Bench 2.0 presents a more nuanced picture. With the Terminus-2 agent framework, GLM-5 scores 56.2 (60.7 on the verified version that fixes ambiguous instructions), compared to DeepSeek-V3.2's 39.3, Kimi K2.5's 50.8, Claude Opus 4.5's 59.3, Gemini 3 Pro's 54.2, and GPT-5.2 xhigh's 54.0. With Claude Code as the agent harness, GLM-5 scores 56.2 (61.1 verified). The consistency across frameworks (Terminus-2 and Claude Code produce essentially identical scores) is a robustness check: it suggests the coding capability is not an artifact of a specific agent harness's prompting or tool configuration but a genuine model property. The verified version (fixing ambiguous instructions in the original benchmark) provides an additional 3.5-4.9 points across frameworks, highlighting how benchmark quality — specifically instruction ambiguity — can mask true model capability. The paper explicitly notes this as the motivation for releasing their verified dataset.

On CyberGym, a cybersecurity vulnerability-fixing benchmark, GLM-5 achieves 43.2% — a dramatic improvement from GLM-4.7's 23.5% (+19.7 points) — second only to Claude Opus 4.5 (50.6%) and well above DeepSeek-V3.2 (17.3%) and Gemini 3 Pro (39.9%). This benchmark, evaluated in Claude Code 2.1.18 with 250-minute timeouts over 1,507 tasks, tests a distinct capability from SWE-bench: understanding security vulnerabilities and producing patches that don't introduce new vulnerabilities, which requires reasoning about code security properties rather than just functionality.

Agentic Benchmarks

BrowseComp (web browsing for complex question answering) reveals the importance of inference-time context management. Without context management, GLM-5 scores 62.0, outperforming DeepSeek-V3.2 (51.4), Kimi K2.5 (60.6), and substantially exceeding proprietary models Claude Opus 4.5 (37.0) and Gemini 3 Pro (37.8). With context management, GLM-5 reaches 75.9 — the highest among all models, including proprietary ones (Claude Opus 4.5: 57.8, Gemini 3 Pro: 59.2, GPT-5.2 xhigh: 65.8). The +13.9-point gain from context management (62.0 → 75.9) is larger than for any other model: DeepSeek-V3.2 gains 16.2 points (51.4 → 67.6), Kimi K2.5 gains 14.3 points (60.6 → 74.9), suggesting GLM-5's keep-recent-k + HCM strategy extracts more value from context management than the simple discard-all used by competitors. On BrowseComp-ZH (Chinese web browsing), GLM-5 achieves 72.7, beating Claude Opus 4.5 (62.4) and Gemini 3 Pro (66.8), though trailing GPT-5.2 xhigh (76.1).

On τ²-Bench (conversational agent in dual-control environments), GLM-5 scores 89.7 — competitive with Claude Opus 4.5 (91.6) and Gemini 3 Pro (90.7) and above GPT-5.2 xhigh (85.5). The paper notes that "small prompt adjustments" were added for Retail and Telecom domains to avoid failures from premature user termination, and Airline domain fixes from the Claude Opus 4.5 system card were applied — these adjustments highlight the sensitivity of agentic benchmarks to user simulator behavior, where model performance can be confounded by simulator quirks rather than genuine capability differences.

On MCP-Atlas (real-world tool-use with Model Context Protocol servers), GLM-5 scores 67.8 on the public 500-task set, improving from GLM-4.7's 52.0 (+15.8 points). This places GLM-5 above DeepSeek-V3.2 (62.2), Kimi K2.5 (63.8), and Claude Opus 4.5 (65.2), and competitive with Gemini 3 Pro (66.6) and GPT-5.2 xhigh (68.0). The timeout extension from 4 to 10 minutes per task was applied to all models to ensure fairness — shorter timeouts can disproportionately penalize models that are slower but more thorough.

On Vending-Bench 2 (long-horizon business simulation), GLM-5 achieves a final account balance of $4,432, compared to GLM-4.7's$ 2,377, DeepSeek-V3.2's $1,034, Kimi K2.5's$ 1,198, Claude Opus 4.5's $4,967, Gemini 3 Pro's$ 5,478, and GPT-5.2 xhigh's $3,591. The 3.7× gap between GLM-5 and Kimi K2.5 on this metric, despite Kimi K2.5 matching or exceeding GLM-5 on short-form reasoning (AIME, GPQA), is one of the paper's most important empirical findings — it demonstrates that reasoning ability does not automatically translate to sustained agentic performance over long horizons, and that GLM-5's agentic RL training provides a capability that reasoning-focused RL alone does not develop.

On GDPval-AA (economically valuable tasks), GLM-5 achieves an Elo of 1,409, improving from GLM-4.7's 1,198 (+211 points) and ranking second only to GPT-5.2 xhigh (1,462), above Claude Opus 4.5 (1,400), Kimi K2.5 (1,288), and Gemini 3 Pro (1,201). The Elo metric reflects relative model preference across diverse economic tasks, providing a broad capability signal that complements the more targeted benchmarks.

CC-Bench-V2: Real-World Agentic Engineering

Frontend Evaluation (Table 8):

GLM-5 achieves Build Success Rates (BSR) of 100% for React, Vue, and Svelte, and 95% for Next.js — establishing that the model can produce syntactically valid, buildable code with extremely high reliability. Claude Opus 4.5 achieves 95%, 100%, 90%, and 80% respectively, and GLM-4.7 achieves 65%, 70%, 60%, and 70% — the BSR improvement from GLM-4.7 is the most dramatic gain, particularly for React (65% → 100%).

Instance Success Rate (ISR — passing all specifications for a task) reveals a more nuanced picture. For HTML, GLM-5 achieves 38.9% vs. Claude Opus 4.5's 52.2% and GLM-4.7's 35.4%. For React, 34.6% vs. 39.7% vs. 17.2%. For Vue, 32.7% vs. 46.9% vs. 24.5%. The consistent pattern is that GLM-5 substantially improves over GLM-4.7 (roughly doubling React ISR, significantly improving Vue) but still trails Claude Opus 4.5 by 5-14 points depending on the stack.

Check-item Success Rate (CSR — fine-grained requirement completion) shows GLM-5 much closer to Claude Opus 4.5: for HTML, 76.3% vs. 82.2%; for React, 71.0% vs. 70.7% (essentially tied); for Vue, 77.1% vs. 74.3% (GLM-5 slightly ahead). The ISR-CSR gap is informative: GLM-5 meets most individual requirements (CSR competitive with Claude) but fails to complete entire end-to-end tasks (ISR trailing Claude), suggesting that the failure mode is not inability to implement specific features but inability to maintain coherence across the full task specification — a pattern consistent with the long-horizon finding that errors compound across steps.

Backend Evaluation (Table 8):

On 85 tasks across 6 languages, GLM-5 achieves 25.8% pass@1, compared to GLM-4.7's 19.6% and Claude Opus 4.5's 26.9%. The 6.2-point improvement over GLM-4.7 is meaningful, but the near-parity with Claude Opus 4.5 on this metric (0.9 points difference) is perhaps more significant — it suggests that for isolated backend modifications (single-commit, test-verified), GLM-5 has reached frontier-level capability. The strict all-or-nothing criterion (all unit tests must pass, 5-10 tests per task) makes this a challenging evaluation, and the shared failure modes between GLM-5 and Claude Opus 4.5 are not analyzed.

Long-Horizon Evaluation (Table 8):

On Large Repo Exploration, GLM-5 achieves 65.6% pass@1 (averaged over 3 runs), compared to GLM-4.7's 47.8% and Claude Opus 4.5's 64.5%. The task requires locating specific source files in repositories with "tens of thousands of files," where target files are at least 3 directory levels deep, carry opaque names, implement unique functionality, and require 1-2 hops of logical reasoning from a user-facing description. GLM-5 slightly exceeds Claude Opus 4.5 on this metric (65.6% vs. 64.5%), a notable result that the paper attributes to "GLM-5's training on agentic tool-use trajectories" providing better strategic search capabilities — the ability to iteratively narrow the file space via directory-level reasoning rather than relying on keyword matching.

On Multi-step Chained Tasks, GLM-5 achieves 52.3% pass@1, compared to GLM-4.7's 43.0% and Claude Opus 4.5's 61.6%. The 9.3-point gap to Claude Opus 4.5 is the largest on any CC-Bench-V2 metric, and the paper explicitly identifies the failure mode: "errors are compounded across the chain: a suboptimal edit in one task can silently break tests in subsequent tasks." The chained task structure — where the codebase state evolves cumulatively across K sequential commits, with tests from all prior tasks applied at each step to catch regressions — creates a uniquely challenging evaluation that single-commit benchmarks like SWE-bench cannot capture. The paper frames narrowing this gap as an active research direction requiring "advances in long-context consistency and long-horizon self-correction."

SWE-rebench: Temporal Decontamination Check

Table 9 presents results on SWE-rebench (January 2026), an automatically mined evaluation that continuously collects fresh GitHub issue-fixing tasks to prevent benchmark contamination. GLM-5 achieves a Resolved Rate of 42.1% with a standard error of ±1.21%, and Pass@5 of 50.0%. This places GLM-5 below the frontier proprietary models — Claude Opus 4.6 (52.9%), GPT-5.2 xhigh (51.7%), Claude Sonnet 4.5 (47.1%), Gemini 3 Pro (46.7%), Claude Opus 4.5 (43.8%) — but above Kimi K2.5 (37.9%) and essentially tied with GLM-4.7 (41.3% ± 2.12%). The small gap between GLM-5 and GLM-4.7 on this benchmark (0.8 points) is surprising given the 4.0-point improvement on SWE-bench Verified (73.8% → 77.8%), and the paper does not discuss possible explanations — one hypothesis is that SWE-rebench's task distribution differs systematically from SWE-bench Verified, or that the strict decontamination (tasks newer than the training data cutoff) disproportionately affects models trained on public SWE data. The Pass@5 metric (50.0% for GLM-5 vs. 58.3% for Claude Opus 4.5 and Gemini 3 Pro) shows that GLM-5 benefits less from multiple sampling attempts than proprietary models, consistent with either lower per-sample variance or lower ceiling accuracy on these tasks.

Real-World General Abilities (Section 6.3, Figure 11)

Figure 11 presents head-to-head comparisons between GLM-5 and GLM-4.7 across five capability domains:

Translation: on ZMultiTransBench (1,220 samples, 7 language pairs), GLM-5 scores 1,050 vs. 1,016 for GLM-4.7 (GPT-4.1-based pairwise comparison); on MENT-SNS (753 English-Chinese sentence pairs), GLM-5 scores 1,013 vs. 993. Both improvements are modest (3.3% and 2.0% relative) but consistent.
Multilingual Dialogue: LMArena Elo increases from 1,441 to 1,452 (+11 points); ZMultiDialBench human evaluation score from 2.85 to 3.12 out of 10 (+0.27). The small human evaluation gain suggests that dialogue quality improvements are incremental rather than transformative.
Instruction Following: IF-Badcase (450 production failure cases) improves from 72.9 to 75.2 (+2.3 points); IFBench from 78.5 to 83.2 (+4.7 points); MultiChallenge from 61.9 to 64.8 (+2.9 points). The IFBench improvement is the largest relative gain in this category.
World Knowledge: SimpleQA accuracy from 31.0% to 36.9% (+5.9 points); Chinese SimpleQA from 60.8% to 95.8% (+35.0 points). The Chinese SimpleQA gain is enormous — from barely above chance (for a 4-option multiple-choice metric, though the paper describes it as short-answer) to near-ceiling — and the paper does not discuss what specific training changes account for this, though the expanded pre-training data and the World Knowledge classifier (Section 2.2) likely contribute.
Tool Calling: ToolCall-Badcase (200 production failure cases) improves from 8.44 to 8.57 out of 10 (+0.13), a negligible gain that suggests tool-calling correctness was already strong in GLM-4.7.

Ablation Studies and Robustness Checks

GQA vs. MLA with Muon Optimizer (Table 1, Section 2.1): Standard MLA with a 576-dimension latent KV-cache cannot match GQA-8 under the Muon optimizer (BBH: 48.9 vs. 53.3, HumanEval: 33.5 vs. 38.5). The Muon Split technique — splitting up-projection matrices into per-head blocks before orthogonalization — recovers the gap (BBH: 51.8, HumanEval: 36.7), and the MLA-256 variant (increased head dimension, reduced head count for decoding efficiency) matches this recovered performance while reducing per-step decoding computation. The finding that the attention logit scale "remains stable during pre-training without any clipping strategy" is a practical robustness result that simplifies training.

MTP Parameter Sharing (Table 2, Section 2.1): Sharing parameters across 3 MTP layers during training (while keeping memory cost constant with a single MTP layer at inference) increases the acceptance length from DeepSeek-V3.2's 2.55 tokens to GLM-5's 2.76 tokens (measured with 4 speculative steps on a private prompt set). This 8.2% relative improvement in speculative decoding efficiency directly translates to faster inference.

DSA Continued Pre-Training (Table 3, Section 2.1.1): The DSA base model matches the MLA base model on long-context benchmarks after only 20B tokens of sparse adaptation training (vs. 943.7B tokens used by DeepSeek-V3.2 for DSA training). MQ-NIAH-128k: both 100.0; MV-NIAH-128k: 97.0 vs. 95.5; SQuAD-128k: 86.0 vs. 79.7 (DSA better); HotpotQA-128k: 63.0 vs. 66.3. The finding that SFT fine-tuning of both models produces "tied" training loss and evaluation benchmarks validates that DSA does not impair downstream task learning. The small-scale verification on GLM-4.7-Flash (Table 6) provides additional evidence: after 150B tokens of joint training, DSA surpasses the dense baseline at 16K, 32K, and 64K context lengths, with only a 0.35-point deficit at 128K.

SWA Layer Pattern Search (Table 4, Section 2.1.2): The beam-search-optimized SWA pattern (SFSSFFSSSFFFFSSFSFFFFFFSFSFSSFSSFSFSSFSSS, S=SWA, F=Full Attention) substantially outperforms naive interleaving without any additional training (RULER@128K: 53.95 vs. 6.51). The pattern was discovered at 16K context but generalizes effectively to all context lengths — a finding that suggests the optimal layer placement for long-range retrieval is a structural property of the model architecture rather than context-length-dependent. After 190B tokens of continual training (Table 5), the SWA Pattern's gap to full attention shrinks to 5.69 points at 128K RULER but remains substantial.

GDN vs. SimpleGDN (Table 5, Section 2.1.2): Removing GDN's Conv1d and explicit gating modules (SimpleGDN) while directly mapping pre-trained QKV weights into the linear recurrence formulation improves performance: RULER@128K gap to full attention shrinks from 11.28 (GDN) to 8.25 (SimpleGDN); HELMET-ICL@128K actually improves over full attention by 4.48 points. The simplification eliminates the need for additional parameters that must be learned from scratch during continual training, suggesting that maximal reuse of pre-trained weights is critical for efficient attention adaptation.

DSA RL Stability (Section 3.2, discussed rather than tabled): Using torch.topk (deterministic) rather than CUDA or TileLang top-k (non-deterministic) for the DSA indexer's token selection is critical for RL stability. Non-deterministic operators cause "drastic performance degradation during RL after only a few steps, accompanied by a sharp drop in entropy" — a finding that, while not presented as a formal ablation table, is stated as an empirical observation from large-scale RL training. Freezing the indexer parameters during RL is a separate design choice that accelerates training and prevents unstable indexer learning.

Token-in-Token-out vs. Text-in-Text-out (Section 4.1.2, qualitative): The paper argues that TITO is "critical for asynchronous RL training" because re-tokenization can introduce "subtle mismatches in token boundaries, whitespace/normalization handling, truncation, or special-token placement" that corrupt step alignment between actions and rewards. No ablation comparing TITO vs. text-in-text-out is presented — the claim is based on engineering experience rather than controlled experiment.

Context Management Strategies for BrowseComp (Figure 8, Section 4.2.4): The keep-recent-k strategy (k=5) alone improves GLM-5's BrowseComp accuracy from 55.3% to 62.0%. The hybrid HCM strategy (keep-recent + discard-all at T=32k threshold) further improves to a peak of 75.9 at the highest compute budget, outperforming discard-all alone (the strategy used by DeepSeek-V3.2 and Kimi K2.5) consistently across all budgets. The finding that "different values of keep recent k or alternatively triggering keep-recent once the context length reaches a predefined token threshold, leads to the same results" is a robustness check that simplifies deployment. GLM-4.7 serves as an ablation baseline: its fewest-step strategy trails GLM-5's fewest-step strategy, and its discard-all strategy trails GLM-5's HCM strategy (Figure 8, gray vs. colored lines), confirming that the context management benefit compounds with model quality — a better model extracts more value from better context management.

Frontend Evaluation: Agent-as-a-Judge Validation (Section 6.2.1): The automated judge (Claude Sonnet 4.5 with Playwright MCP) achieves 94% agreement with human experts on 130 point-wise check-item evaluations, with disagreements "concentrated on subjective visual-quality criteria rather than functional specifications." For ranking consistency across 8 frontier models, Spearman correlation between automated and human rankings is 85.7%. This validation is critical because the frontend ISR and CSR metrics depend entirely on the judge agent's reliability — without it, the reported performance numbers would be confounded by judge errors.

τ²-Bench Prompt Adjustments (Section 6.1.3, Appendix B.3): The paper applies "small prompt adjustments" to the user simulator in Retail and Telecom domains "to avoid failures caused by premature user termination." The optimized prompts (Figures 12-13) add explicit rules about when to end conversations ("Do not end until you have clearly and completely expressed all your requirements"), how to handle information not in the instruction ("Say you don't remember or don't have it"), and domain-specific guidelines. The fact that such adjustments are necessary and consequential — models appear worse on this benchmark without them — is both a robustness check and a limitation disclosure: it reveals that τ²-Bench scores are sensitive to user simulator behavior that may not reflect the original benchmark design.

ReST^EM Revision Model (Appendix K, Figure 16 — referenced in Section 6.3 of the prior summary but not detailed in the provided paper excerpt): The paper mentions that an attempt to further optimize the revision model using ReST^EM "backfires: additional sequential revisions substantially hurt performance," with a hypothesis that on-policy data collection "exacerbates spurious correlations in revision data." This is a negative result that is not elaborated in the available sections but suggests that the revision training procedure is sensitive to the data generation methodology.

Slide Generation Ablation (Section 4.2.5): The multi-level reward formulation is partially ablated through the reporting of reward hacking behaviors. The paper identifies two specific hacks — "hard truncation of overlong content" (hiding overflow content rather than properly laying it out) and "excessive manipulation of spacing" (adding space to satisfy geometric constraints without genuine aesthetic improvement) — and reports that refining the renderer "to eliminate exploitable loopholes" was necessary. The empirical improvement from 40% to 92% in 16:9 aspect ratio compliance validates the overall pipeline but does not isolate the contribution of individual reward levels. The overall 67.5% human-evaluated win rate over GLM-4.5 aggregates content quality (60%), layout rationality (57.5%), and visual aesthetics (65%) — all individually positive but with substantial variance.

Critical Assessment

Do the experiments demonstrate the claimed "transition from vibe coding to agentic engineering," or do they demonstrate something narrower?

The paper's central framing — that GLM-5 represents a paradigm shift from human-prompted code generation to autonomous multi-step software engineering — is supported most directly by the Vending-Bench 2 and CC-Bench-V2 results, but with important boundaries. Vending-Bench 2 ( $4,432 vs.$ 1,034 for DeepSeek-V3.2, Table 7) clearly shows sustained autonomous decision-making over a year-long simulated horizon that prior open models cannot match. However, Vending-Bench 2 is a business simulation, not a software engineering task — it measures resource management and planning, not the coding-specific agentic behaviors (debugging, refactoring, multi-file editing) that "agentic engineering" implies. The connection between Vending-Bench success and coding agent success is asserted rather than demonstrated.

CC-Bench-V2's chained tasks (Table 8) are more directly relevant: they require sequential commits across a codebase with cumulative state changes, exactly the "agentic engineering" scenario the paper emphasizes. GLM-5's 52.3% pass@1 vs. Claude Opus 4.5's 61.6% shows meaningful autonomous capability — the model can complete multi-step development tasks without human intervention roughly half the time — but the 9.3-point gap to the proprietary frontier suggests that GLM-5 has not "solved" agentic engineering. It has made substantial progress toward it, narrowing the gap relative to GLM-4.7 (43.0%), but the framing of "transitioning the paradigm" may overstate the case: the model succeeds on approximately half of chained tasks and fails on half, with failures compounding across steps.

The SWE-bench Verified improvement (73.8% → 77.8%, Table 7) is a 4.0-point gain — meaningful but incremental at a level where the benchmark may be approaching saturation (Claude Opus 4.5 achieves 80.9%, GPT-5.2 xhigh 80.0%). This benchmark evaluates single-commit bug fixes, precisely the "vibe coding" paradigm the paper claims to be moving beyond. The fact that GLM-5's SWE-bench gain is relatively modest (4 points) while its CC-Bench-V2 long-horizon gain is much larger (9.3 points on chained tasks, 17.8 points on repo exploration) actually supports the paper's thesis: GLM-5's training is specifically improving the capabilities that SWE-bench does not measure. But this also means that the headline SWE-bench numbers (77.8%, competitive with Claude Opus 4.5) are doing more rhetorical work than scientific work — they establish competitiveness on the metric the field already uses, while the genuinely novel capability (multi-step autonomous development) shows a wider gap to proprietary models.

What is and is not tested regarding asynchronous RL's contribution?

A central claim of the paper is that the asynchronous agentic RL infrastructure (Section 4.1) is a key innovation enabling agentic capability. However, the paper provides no ablation comparing synchronous vs. asynchronous training of the same model on the same tasks — a controlled experiment that would directly test this claim. The improvement from GLM-4.7 to GLM-5 (Table 7, across all agentic benchmarks) confounds multiple changes: DSA architecture, larger parameter count (744B vs. 355B), extended context (200K vs. 128K), mixed-domain reasoning RL, the asynchronous infrastructure itself, and the scaled agentic environments (10K+ SWE tasks, terminal tasks, search tasks). Attributing the agentic improvement specifically to the asynchronous RL infrastructure is impossible from the reported results — any or all of these changes could be responsible.

The paper's ablation of synchronous-vs-asynchronous is implicit and qualitative: "Naive synchronous RL suffers from severe GPU idle time during long-horizon agent rollouts" (Section 3.3) and the claim that asynchronous training "significantly improves the efficiency of our RL post-training pipeline" (Section 1). These are infrastructure efficiency claims (faster training, higher throughput), not capability claims. The capability claim — that asynchronous training enables learning from trajectory distributions inaccessible to synchronous methods — is plausible but unverified. A controlled experiment that holds total training FLOPs constant and varies synchronous-vs-asynchronous would be the relevant test, and it is absent.

The TITO Gateway and DDIS algorithm (Section 4.1.2) are similarly unevaluated through controlled ablation. The claim that TITO "is critical for asynchronous RL training" is based on engineering reasoning (re-tokenization corrupts action-reward alignment) but is not experimentally verified. The DDIS algorithm's specific components — reusing rollout log-probabilities as behavior proxy, double-sided symmetric masking, version-based off-policy filtering — are presented as design decisions without ablations comparing against alternatives (e.g., maintaining a checkpoint history for exact importance sampling, using asymmetric clipping, not filtering stale trajectories). The paper's asynchronous RL innovations are thus best understood as an engineering contribution (a working system at scale) rather than an algorithmic one for which the specific mechanisms are validated.

Are the proprietary model comparisons fair?

The paper compares GLM-5 against Claude Opus 4.5, Gemini 3 Pro, and GPT-5.2 xhigh on a range of benchmarks, but several asymmetries complicate interpretation:

Context management: GLM-5's BrowseComp score with context management (75.9) is compared against proprietary models that may or may not use comparable techniques. Claude Opus 4.5 scores 57.8, Gemini 3 Pro 59.2 — but it is unclear whether these models were evaluated with equivalent context management strategies. The paper's keep-recent-k + HCM strategy was specifically developed and tuned for GLM-5; applying it to other models might close or reverse the gap.
Agent framework: SWE-bench and Terminal-Bench results depend on the agent harness. GLM-5 uses OpenHands with a "tailored instruction prompt" for SWE-bench; proprietary models use their standard configurations. The "tailored prompt" is not specified, and whether similar tailoring would improve proprietary model scores is unknown. On Terminal-Bench, GLM-5 is evaluated with both Terminus-2 and Claude Code frameworks — a good practice — but proprietary models are not evaluated across frameworks (GPT-5.2 xhigh and Gemini 3 Pro are only evaluated with Terminus-2).
Timeout and environment conditions: MCP-Atlas evaluation extends the timeout to 10 minutes for all models specifically to avoid disadvantaging slower models. This is fair but acknowledges that the original benchmark's 4-minute timeout was a confound. τ²-Bench adjustments (Section 6.1.3) are applied to GLM-5's evaluation but the paper states they also apply domain fixes "proposed in the Claude Opus 4.5 system card" — suggesting the adjustments bring the evaluation in line with how Claude was evaluated, making the comparison more symmetric.
Vending-Bench 2: Results are "conducted independently by Andon Labs" for all models, which adds credibility. However, GLM-5's $4,432 vs. Claude Opus 4.5's$ 4,967 represents a 12.1% gap — whether this is statistically significant given the inherent variance in a simulated year-long business environment is not reported (no standard errors, no multiple runs).

Single benchmark family and the missing evaluation dimensions:

All main results are on English-language or Chinese-language benchmarks. The "agentic engineering" capability is evaluated primarily through SWE-bench variants, Terminal-Bench, and CC-Bench-V2 — all software engineering tasks. The paper does not evaluate on other agentic domains where the infrastructure might be expected to generalize: scientific research workflows, legal document analysis, financial modeling, or any non-coding agentic task. The search agent evaluation (BrowseComp, BrowseComp-ZH) provides a non-coding agentic signal, but the environment scaling for RL (Section 4.2) was dominated by coding (10K+ SWE environments, terminal tasks, slide generation — only the search task pipeline is non-coding). The paper's claim of "agentic general intelligence" (Section 1) thus rests on an agentic capability that may be specific to software engineering.

The evaluation also lacks latency and cost metrics. The paper emphasizes efficiency (DSA, INT4 quantization, Chinese GPU adaptation) but reports no throughput numbers, tokens-per-second, or dollar-cost-per-task for any benchmark. For a paper whose contribution is partly about making agentic training practical, the absence of wall-clock training time or inference latency is a significant omission. The DSA computation reduction is quoted as 1.5-2×, but this is a relative factor without absolute scale — how long does a full agentic RL training run take? How many GPU-hours? What is the inference latency for a typical SWE-bench task? These metrics would substantiate the efficiency claims and enable practitioners to assess deployment feasibility.

Test set sizes and statistical reliability:

SWE-bench Verified: 500 tasks. GLM-5's 77.8% represents 389 correct resolutions. The difference from Claude Opus 4.5's 80.9% (~404 correct) is approximately 15 tasks — with a binomial standard error of roughly √(500 × 0.78 × 0.22) ≈ 9.3, so the 3.1-point gap is less than 2 standard errors. The paper does not report confidence intervals.
SWE-bench Multilingual: Likely smaller (exact size not specified in the provided sections).
Terminal-Bench 2.0: Scores averaged over 5 runs with Claude Code, which provides some variance reduction, but the benchmark size is not specified.
CC-Bench-V2 frontend: 220 tasks, split across 5 stacks (HTML, React, Vue, Svelte, Next.js). The per-stack sample sizes are small (27-113 tasks per stack, Table 12-13), meaning ISR differences of 5-10 points (e.g., GLM-5 34.6% vs. Claude 39.7% on React) may not reach statistical significance.
CC-Bench-V2 backend: 85 tasks. GLM-5's 25.8% vs. Claude's 26.9% is a 1-task difference — far within sampling error.
CC-Bench-V2 chained tasks: Size not specified. The 9.3-point gap (52.3% vs. 61.6%) is the most important result for the agentic engineering thesis, but without task count and variance estimates, its reliability is unclear.
BrowseComp: The paper does not specify the number of questions; the original BrowseComp paper [50] contains 1,266 questions, but the paper's re-evaluation may use a subset. The 75.9 vs. 57.8 gap to Claude Opus 4.5 is large enough to likely be significant regardless of test set size.
Vending-Bench 2: Single-run per model (variance unmeasured). A year-long business simulation with stochastic elements likely has substantial run-to-run variance.

The paper would be strengthened by reporting standard errors or confidence intervals for all main results, particularly for the smaller benchmarks (CC-Bench-V2, SWE-bench Multilingual) and for metrics where the gap between models is small relative to plausible sampling variation.

Missing ablations that would strengthen the paper:

Synchronous vs. asynchronous RL: Same total compute budget, same environments, compare agentic benchmark performance. This would directly test whether the asynchronous infrastructure provides a capability improvement or "only" an efficiency improvement.
Model scale ablation: Train a smaller GLM-5 variant (e.g., 355B parameters like GLM-4.5) with the same post-training pipeline to isolate the contribution of model scale from the contribution of the training methodology.
Environment scale ablation: Vary the number of SWE training environments (e.g., 1K vs. 5K vs. 10K+) while holding other factors constant, to measure the return on environment construction investment.
DSA vs. MLA for agentic tasks: Compare the full GLM-5 (with DSA) against an otherwise identical model trained with MLA on agentic benchmarks, to isolate DSA's contribution to agentic capability (beyond its established contribution to training efficiency).
Agentic RL vs. SFT-only: Does the agentic RL provide gains beyond supervised fine-tuning on the same agent trajectories? The paper's pipeline includes both SFT on agent data (Section 3.1) and agentic RL (Section 3.3), but their relative contributions are confounded.
Thinking mode ablation: Disable Interleaved Thinking, Preserved Thinking, or Turn-level Thinking individually and measure the impact on CC-Bench-V2 and SWE-bench. These features are presented as innovations but their individual contributions are unevaluated.
On-Policy Cross-Stage Distillation ablation: Compare the final model with and without the distillation stage to quantify its impact on recovering capabilities from earlier RL stages. The paper claims it mitigates "cumulative degradation of previously acquired capabilities" but provides no numbers.

Do the results support the claim that test-time compute can compensate for model scale?

The prior sections' claim that "test-time strategies can compensate for model scale" is not directly tested in the reported experiments. Unlike the reference paper (which conducted a FLOPs-matched comparison between a small model with test-time compute and a larger model without), GLM-5's comparisons are all at fixed inference budgets (single runs or fixed pass@K) across models of different scales. The paper shows that GLM-5 (744B) outperforms larger proprietary models on some benchmarks, but this is not a test-time compute scaling result — it's a claim about training efficiency and architecture quality producing a better model at the same or smaller scale. The BrowseComp Figure 8 does show accuracy as a function of step budget, demonstrating that GLM-5 benefits from additional test-time computation (more browsing steps), but this is not compared against a scaling curve for a larger model.

When the paper's central claims hold and when they don't:

"GLM-5 achieves state-of-the-art among open-weight models" : This holds across nearly all reported benchmarks (Table 7), with the notable exception of AIME 2026 I (Kimi K2.5 ties at 92.5), HLE text-only (Kimi K2.5 leads 31.5 vs. 30.5), and GPQA-Diamond (Kimi K2.5 leads 87.6 vs. 86.0). On agentic benchmarks specifically (Vending-Bench 2, BrowseComp, τ²-Bench, MCP-Atlas), GLM-5's lead over other open models is larger and more consistent than on reasoning benchmarks.
"GLM-5 rivals proprietary models on complex coding tasks" : This holds for SWE-bench Verified (trailing Claude Opus 4.5 by 3.1 points), SWE-bench Multilingual (leading GPT-5.2 xhigh by 1.3 points), and CC-Bench-V2 backend (essentially tied with Claude Opus 4.5). It does not hold for CC-Bench-V2 frontend ISR (trailing by 5-14 points across stacks) or chained tasks (trailing by 9.3 points). The claim is most accurate for isolated, single-commit coding tasks and weakens as task horizon lengthens.
"DSA achieves lossless sparsity" : This holds within 0.35 points at 128K context (Table 6), which is within reasonable measurement noise for a benchmark evaluation. It's worth noting that "lossless" is an empirical claim about a specific set of benchmarks (RULER, NIAH, SQuAD, HotpotQA), not a theoretical guarantee, and the evaluation does not include the specific retrieval patterns that agentic coding produces (e.g., locating a function definition across 100K+ tokens of mixed code and natural language).
"Asynchronous RL enables learning from long-horizon interactions" : This is the least verified major claim. The paper demonstrates that a model trained with asynchronous RL performs well on long-horizon benchmarks, but does not demonstrate that synchronous RL would have failed to achieve comparable performance given equivalent total compute. The infrastructure's efficiency benefits (higher GPU utilization) are plausible and consistent with the system description, but the capability benefits are inferred rather than proven.

6. Limitations and Trade-offs

Lack of Controlled Ablation Separating Asynchronous RL Infrastructure from Other Training Changes

The assumption or constraint. The paper attributes much of GLM-5's agentic capability to the fully asynchronous, decoupled RL infrastructure described in Section 4.1. However, the improvement from GLM-4.7 to GLM-5 on agentic benchmarks (Table 7) confounds multiple simultaneous changes: the DSA architecture replacing MLA, the parameter count doubling from 355B to 744B total, context extension from 128K to 200K, the mixed-domain reasoning RL stage, the scaled agentic environments (10K+ SWE tasks vs. GLM-4.5's unspecified number), the new thinking modes (Interleaved, Preserved, Turn-level), and the asynchronous infrastructure itself. The paper provides no experiment that holds total training FLOPs constant and varies only the synchronous-vs-asynchronous training regime. The claim in Section 3.3 that "Naive synchronous RL suffers from severe GPU idle time during long-horizon agent rollouts" is an infrastructure efficiency claim, not a capability claim, and Section 1's assertion that the asynchronous infrastructure "drastically improves post-training efficiency" is about training throughput rather than model quality.

The consequence. A practitioner cannot determine whether the asynchronous RL infrastructure is necessary for achieving GLM-5's agentic performance, or whether comparable results could be obtained with synchronous RL given equivalent total compute (longer wall-clock training, more GPUs). The infrastructure described in Section 4.1 is substantially more complex than standard synchronous RL pipelines—requiring a central Multi-Task Rollout Orchestrator, the TITO Gateway, DDIS algorithm, version-based off-policy filtering, and DP-aware routing. Each component introduces engineering complexity and potential failure modes. If synchronous RL with the same environments and compute budget would achieve similar results, the infrastructure investment may not be justified. Conversely, if the asynchronous design is genuinely required for learning from long-horizon trajectories that would be infeasible to train on synchronously, this is a crucial finding that the paper does not establish experimentally.

What evidence exists in the paper. None. The paper provides no synchronous-vs-asynchronous comparison controlling for model scale, training data, environments, or total compute. The TITO Gateway (Section 4.1.2) is presented as "critical for asynchronous RL training" based on reasoning about re-tokenization mismatches, but no experiment shows training degradation when TITO is removed. The DDIS algorithm (Section 4.1.2) is justified by infeasibility of tracking historical checkpoints—a systems constraint, not an experimental finding. The version-based off-policy filtering (Section 4.1.2) includes a threshold τ for discarding stale trajectories, but no sensitivity analysis for τ is reported, and no ablation compares filtering-vs-no-filtering.

Mitigation status. Not mitigated. The paper acknowledges the complexity of the infrastructure but does not ablate it. The contribution remains an existence proof—asynchronous agentic RL at this scale is possible and produces a capable model—rather than a demonstration that the specific asynchronous design choices are necessary or optimal.

Difficulty Estimation Cost for Agentic Rollout Selection Is Unaccounted For

The assumption or constraint. The agentic RL pipeline (Section 4.1) generates trajectories continuously from inference engines, filters them through a central orchestrator, and routes them to the training engine when a predefined batch size threshold is reached. The environments themselves—particularly the 10K+ SWE environments (Section 4.2.1) and the Dockerized terminal environments (Section 4.2.2)—require substantial computation to execute: building Docker containers, running test suites, validating patches. The paper reports that SWE environments are constructed "based on the RepoLaunch framework that scales the construction of executable environments" and that terminal environments achieve "Docker construction accuracy exceeding 90%," but provides no accounting of the compute cost for environment execution during RL training. This cost is external to the model's generation and training computation but is required for the reward signal that drives learning.

The consequence. The total cost of training GLM-5's agentic capabilities is significantly higher than the FLOPs consumed by the model itself. The environments involve executing real code in sandboxes—running test suites across repositories with thousands of files, building Docker containers, rendering web pages for slide generation (Section 4.2.5)—each of which consumes CPU, memory, and I/O resources that scale with the number of concurrent rollouts (over 1K, per Section 4.1.1). A practitioner attempting to replicate this training pipeline needs to provision environment execution infrastructure in addition to GPU clusters for model inference and training. The paper's emphasis on GPU utilization efficiency (asynchronous design, DSA attention reduction) addresses only part of the total cost.

Furthermore, the environment failure filtering mechanism (Section 4.1.2) discards samples that "fail due to environment collapse"—meaning compute was spent on environment execution for trajectories that are then excluded from training. The paper does not report what fraction of trajectories are discarded for this reason. If environment instability is common (the paper acknowledges "coding-agent sandboxes can be inherently unstable"), a non-trivial fraction of the environment execution budget produces no training signal, further reducing effective efficiency.

What evidence exists in the paper. The paper reports the number of environments constructed (over 10K SWE environments across thousands of repositories, Section 4.2.1; thousands of terminal environments, Section 4.2.2) but never reports the compute cost of constructing them or executing them during RL. The infrastructure description (Section 4.1.1) mentions that the orchestrator "supports over 1k concurrent rollouts" but does not specify what CPU/memory resources are provisioned for the corresponding 1K+ concurrent environment executions. The terminal environment pipeline reports "Docker construction accuracy exceeding 90%" (Section 4.2.2), implying roughly 10% of constructed environments fail validation—the cost of those failed constructions is unaccounted. The paper's general evaluation (Table 7) reports no latency or dollar-cost metrics for any benchmark, despite extensive discussion of training and inference efficiency (Sections 2.4, 3.6, 5).

Mitigation status. Not mitigated or acknowledged. The paper does not discuss environment execution cost as a limitation. The efficiency narrative (DSA, INT4 quantization, Chinese GPU adaptation) focuses exclusively on model computation, creating an incomplete picture of the total system cost for agentic RL training.

The Hardest Agentic Tasks Remain Unsolved—Error Compounding Across Sequential Steps Is Unmitigated

The assumption or constraint. The paper's central thesis is the transition from single-turn code generation to sustained autonomous software engineering. However, the CC-Bench-V2 results (Table 8, Section 6.2.3) reveal a specific failure mode that the training pipeline does not address: errors compound across sequential commits. On multi-step chained tasks, GLM-5 achieves 52.3% pass@1, compared to Claude Opus 4.5's 61.6%—a 9.3-point gap. The paper explicitly identifies the mechanism: "a suboptimal edit in one task can silently break tests in subsequent tasks." This is not a matter of insufficient reasoning depth or tool-use capability (GLM-5 is competitive on isolated backend tasks at 25.8% vs. Claude's 26.9%) but a distinct failure mode where the model's internal representation of the codebase state drifts from reality as modifications accumulate. The training pipeline—despite its emphasis on long-horizon agentic RL (Section 4.1), preserved thinking (Section 3.1), and 200K context (Section 2.3)—does not include any mechanism specifically designed to prevent or recover from state-tracking errors across sequential commits.

The consequence. For any deployment scenario where the agent must make multiple interdependent changes to a codebase—which is the defining characteristic of real software engineering as opposed to isolated bug fixes—GLM-5 fails approximately half the time due to error compounding. The 52.3% pass@1 on chained tasks means that in roughly half of multi-step development attempts, the agent will produce a broken codebase state that a human developer must diagnose and repair. This is better than GLM-4.7's 43.0% but still far from the reliability needed for autonomous deployment. Moreover, the failure mode is latent: a suboptimal edit in task 1 may not be detected until task 3 or 4, at which point debugging requires understanding which of several cumulative changes caused the regression—a more costly repair than fixing an isolated error.

The paper's broader claim—that GLM-5 "demonstrates unprecedented capability in real-world coding tasks, surpassing previous baselines in handling end-to-end software engineering challenges" (Abstract)—is qualified by this limitation. On the specific "end-to-end" metric that best captures real-world software engineering (chained multi-commit tasks), GLM-5's improvement is substantial relative to GLM-4.7 but the absolute performance leaves room for failure in roughly half of attempts, and the gap to the proprietary frontier is the largest of any CC-Bench-V2 metric.

What evidence exists in the paper. Table 8 (Section 6.2.3) provides the direct evidence. The repo exploration task (65.6% vs. 64.5% for Claude—a slight lead) suggests that GLM-5's file-finding capability is strong. The chained tasks result (52.3% vs. 61.6%) isolates the compounding problem: the model can find the right files and make individual correct edits, but cannot maintain coherence across sequential modifications. The paper does not report per-step accuracy within chains—it is unknown whether performance degrades monotonically with chain position (consistent with state-tracking drift) or drops at specific types of transitions (e.g., when a later task depends on code modified in an earlier task). The SWE-rebench evaluation (Table 9) shows GLM-5 at 42.1% resolved rate vs. GLM-4.7's 41.3%—a 0.8-point gap that suggests the chained-task improvement (9.3 points over GLM-4.7 on CC-Bench-V2) may not generalize to all multi-step task distributions.

Mitigation status. The paper identifies this as an active research direction: "Narrowing this gap will require advances in long-context consistency and long-horizon self-correction, both active areas of our ongoing research" (Section 6.2.3). The existing mechanisms—Preserved Thinking (retaining reasoning across turns), the async RL infrastructure (training on long trajectories), and the DSA architecture (efficient long-context processing)—are necessary preconditions for addressing the problem but are not sufficient solutions. The paper does not propose or evaluate any specific mechanism for detecting or recovering from state-tracking errors during multi-commit development.

Generalisation Is Evaluated Only Within Software Engineering; Other Agentic Domains Are Unmeasured

The assumption or constraint. The paper frames GLM-5 as enabling "agentic engineering" and "agentic general intelligence" (Section 1, Conclusion), but the evaluation of agentic capability is overwhelmingly concentrated in software engineering tasks. The environment scaling for RL (Section 4.2) is dominated by coding: 10K+ SWE environments across 9 programming languages (Section 4.2.1), thousands of terminal tasks (Section 4.2.2), and slide generation (Section 4.2.5). The only non-coding agentic environment described is the search task pipeline (Section 4.2.3), and search capability is evaluated only through BrowseComp and BrowseComp-ZH (Table 7)—both web browsing for question answering. The agentic benchmarks in Table 7 include non-coding tasks (τ²-Bench for conversational agents, Vending-Bench 2 for business simulation, GDPval-AA for economic tasks), but these are evaluated zero-shot or with minimal prompt adjustments; the RL training for these domains is either absent or not described.

The consequence. A practitioner considering GLM-5 for non-coding agentic applications—scientific research assistance, legal document analysis, financial analysis, healthcare workflow automation—has no evidence that the model's agentic capabilities transfer to those domains. The training pipeline's heavy emphasis on coding environments (10K+ SWE tasks, terminal tasks, slide generation) may produce an agent that is specifically adapted to software engineering workflows: reading and editing code files, running terminal commands, interpreting test output, navigating file systems. These are specific interaction patterns that do not necessarily transfer to domains where the primary actions involve reading and synthesizing documents, querying databases, interacting with domain-specific APIs, or reasoning about non-code artifacts. The search agent evaluation (BrowseComp) provides the only non-coding agentic signal, and it tests a narrow capability (web browsing for factual questions) that shares little with the sustained, multi-file codebase interactions that dominate the training.

Furthermore, the paper reports "stable and significant gains in each domain under the mixed RL setting" for the reasoning RL stage (Section 3.2, covering math, science, code, and TIR), but makes no analogous claim for the agentic RL stage. The Multi-Task Rollout Orchestrator (Section 4.1.1) is described as managing "diverse downstream tasks," but the only concrete tasks mentioned for agentic RL are coding and search. The generalization of the asynchronous RL infrastructure to other agentic domains is an architectural claim, not an empirical one.

What evidence exists in the paper. The training environment descriptions (Section 4.2) list only SWE, terminal, search, and slide generation environments. Table 7 includes BrowseComp, BrowseComp-ZH, τ²-Bench, MCP-Atlas, Tool-Decathlon, and Vending-Bench 2 as agentic benchmarks, but these are evaluation-only—there is no evidence they were used as RL training environments. The improvement on Vending-Bench 2 from GLM-4.7 ( $2,377 to$ 4,432) is large, but this could reflect general capability improvements from the coding-focused agentic RL (better planning, better resource management from the SWE training) rather than domain-specific training. No evaluation exists for scientific agent tasks, creative workflows, multi-modal agentic tasks, or any non-code, non-search agentic domain.

Mitigation status. Not acknowledged as a limitation. The paper uses "agentic engineering" in the title and abstract, which is specific to software engineering, but the broader claims of "agentic general intelligence" (Conclusion) and "next generation of AI agents" (Introduction) are not scoped to engineering. The environment scaling section (4.2) describes what was built, not what was omitted, so the absence of non-coding agentic environments is not flagged as a gap.

The Difficulty of Replication Due to Undisclosed Hyperparameters, Data Mixtures, and Infrastructure Scale

The assumption or constraint. The paper describes the training pipeline at an architectural level but omits numerous details that would be necessary for independent replication or adaptation to different model scales. Key missing specifications include: the mixing ratios for the four reasoning RL domains (Section 3.2, described only as "roughly balanced"); the per-task sampling ratios controlled by the Multi-Task Rollout Orchestrator (Section 4.1.1, described only as "balanced data collection across tasks"); the specific reward functions used in agentic RL beyond the generic group-wise objective (Section 4.1); the weighting of the three reward types (rule-based, ORM, GRM) in the General RL hybrid reward system (Section 3.4); the threshold τ for version-based off-policy filtering (Section 4.1.2); the threshold for batch size triggering training engine updates (Section 4.1.1); the weight synchronization interval K (Section 4.1.1); and the mixing proportions for on-policy cross-stage distillation (Section 3.5, described only as "appropriate proportions"). For the pre-training data (Section 2.2), the composition of the 28.5T-token corpus across web, code, math, and science is not specified beyond qualitative descriptions—no sampling ratios, no deduplication thresholds, no quality classifier thresholds.

The consequence. The paper functions as a system description and capability demonstration but not as a reproducible recipe. A research group with access to comparable compute resources could not replicate GLM-5 without independently determining these hyperparameters through their own experimentation. The infrastructure complexity—asynchronous decoupled RL with custom TITO Gateway, DDIS algorithm, DP-aware routing, and multi-task orchestration—means that even with the hyperparameters specified, the engineering effort required to build a comparable training system is substantial and the paper's descriptions are insufficient as implementation specifications.

For the hardware-specific optimizations (Section 5), the paper describes the adaptation to Chinese GPU ecosystems qualitatively (Lightning Indexer, Sparse Flash Attention, MLAPO fusion, W4A8 quantization) but provides no performance numbers: no throughput (tokens/second), no latency measurements, no comparison against the same model running on standard NVIDIA hardware. The claim of "50% reduction in deployment costs" is unquantified—cost relative to what baseline, at what scale, for what workload? A practitioner evaluating whether to deploy GLM-5 on their own hardware has no empirical basis for estimating performance.

For the model architecture details not in Table 10, parameters such as the RoPE base frequency, the initialization scheme for the DSA indexer, the specific hyperparameters for INT4 QAT (quantization granularity, calibration methodology), and the MTP speculative decoding configuration (number of draft tokens, acceptance threshold) are unstated.

What evidence exists in the paper. The paper provides detailed hyperparameters for some components (Table 10 for architecture, Section 3.2 for reasoning RL: β=2, ε_low=0.2, ε_high=0.28, group size 32, batch size 32; Appendix A mentions pre-training peak learning rate 2e-4, DSA warmup learning rate 5e-3, and mid-training learning rate decay from 4e-5 to 1e-5) but omits others as listed above. The evaluation section (6) reports results without confidence intervals for most benchmarks, preventing assessment of whether reported differences are statistically reliable given the test set sizes discussed in Section 5's critical assessment. The "Pony Alpha" anonymous release anecdote (Section 8) provides community validation but no systematic third-party evaluation.

Mitigation status. Partially mitigated by the open-source release ("Code, models, and more information are available at https://github.com/zai-org/GLM-5"), which provides model weights and presumably inference code. This enables evaluation and fine-tuning of the released model but does not enable replication of the training process. The paper's function as a technical report—detailing the methods that produced the model—is what replication would require, and it is incomplete in the respects described above. This is a common limitation of large-scale industrial model reports and is not unique to GLM-5, but it constrains the paper's scientific contribution relative to its engineering achievement.

No Evaluation of Inference Latency or Wall-Clock Cost for Agentic Tasks

The assumption or constraint. The paper extensively discusses training and inference efficiency: DSA reduces attention computation by 1.5–2× (Section 2.1.1), MTP increases acceptance length to 2.76 tokens (Table 2), INT4 QAT enables low-precision deployment (Section 2.4.3), Chinese GPU adaptation reduces deployment costs by 50% (Section 5), and the slime infrastructure optimizes tail latency for RL rollouts (Section 3.6.2). However, none of these efficiency claims are accompanied by absolute performance measurements. The paper never reports tokens-per-second generation speed, end-to-end latency for completing a typical SWE-bench task, wall-clock time for a BrowseComp evaluation run, or the GPU-hours consumed for any benchmark evaluation. The DSA computation reduction of 1.5–2× is a relative factor without an absolute baseline—2× faster than what, at what sequence length, on what hardware?

The consequence. For a practitioner deciding whether GLM-5 is suitable for a production agentic coding deployment, latency and throughput are first-order concerns. An agent that produces correct patches 77.8% of the time (SWE-bench Verified) but takes 10 minutes per task may be less useful than an agent that achieves 73% accuracy in 2 minutes, depending on the use case. The paper provides no basis for making this tradeoff. The agentic RL infrastructure (Section 4.1) emphasizes throughput and GPU utilization for training, but the trained model's inference characteristics—particularly for the long-context, multi-turn, tool-calling patterns that agentic tasks require—are unevaluated.

The efficiency optimizations described in Section 5 (Lightning Indexer, Sparse Flash Attention, MLAPO, W4A8 quantization) are specific to Chinese GPU platforms, and no comparison against standard NVIDIA hardware is provided. A practitioner on NVIDIA hardware cannot determine whether GLM-5 would be faster or slower than alternatives, or whether the hardware-specific optimizations provide benefits that generalize across platforms. The 50% cost reduction claim for Chinese GPUs is unverifiable without knowing the baseline cost, the scale of deployment, and the specific workload.

What evidence exists in the paper. The only absolute performance metric related to inference speed is the acceptance length for speculative decoding (Table 2: 2.76 tokens for GLM-5 vs. 2.55 for DeepSeek-V3.2), which is a relative efficiency metric, not a latency measurement. The DSA training loss curves (Figure 6) show SFT loss over steps, not wall-clock time. The BrowseComp Figure 8 shows accuracy as a function of "Steps" (browsing actions), which is a compute budget metric, not wall-clock time. For agentic benchmarks, timeouts are specified (MCP-Atlas: 10 minutes, CyberGym: 250 minutes, Terminal-Bench: 2 hours) but actual completion times are not reported.

Mitigation status. Not mitigated. The paper's efficiency narrative is entirely about relative improvements and hardware-specific optimizations without absolute performance characterization. The open-source release will enable third-party latency benchmarking, but the paper itself provides none. This omission is particularly significant given that the paper's central contribution is partly about making agentic AI practical and efficient—without latency measurements, practicality cannot be assessed from the paper alone.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper shifts the conversation about LLM capability from a reasoning-centric frame—where progress is measured by benchmark scores on math and short-form coding—to an endurance-centric frame, where the limiting factor is not whether a model can produce one correct answer but whether it can produce dozens of correct, interdependent actions across a sustained horizon without compounding errors. This is not merely an "agentic capabilities are important" platitude. The paper's CC-Bench-V2 results (Table 8) provide a specific diagnostic: on isolated backend tasks, GLM-5 and Claude Opus 4.5 are nearly indistinguishable (25.8% vs. 26.9% pass@1), but on chained multi-commit tasks, a 9.3-point gap opens (52.3% vs. 61.6%). The gap does not emerge from coding ability—it emerges from the sequential dependency structure. This is the paper's core empirical contribution: it separates reasoning capability from agentic endurance as distinct, measurable, and unequally developed axes, and it provides a specific evaluation framework (chained tasks, repo exploration, Vending-Bench 2) that probes the endurance axis directly.

The implication for how the field should allocate research effort is significant. If reasoning and endurance are orthogonal—as the Vending-Bench 2 comparison between GLM-5 ( $4,432) and Kimi K2.5 ($ 1,198) strongly suggests, given their near-identical short-form reasoning scores—then further scaling of reasoning RL alone will asymptotically fail to produce useful autonomous agents. The Kimi K2.5 comparison is particularly instructive: it achieves 92.5 on AIME 2026 I and 87.6 on GPQA-Diamond, essentially tying GLM-5 on reasoning, yet its sustained business management performance is 3.7× worse. The capability that produces Vending-Bench performance is not a supercharged version of the capability that produces AIME performance. It is something else—likely involving state tracking, plan maintenance, error recovery, and long-horizon credit assignment—that requires its own training paradigm, its own architectural support, and its own evaluation methodology. The paper's infrastructure contributions (asynchronous agentic RL, DSA for long-context efficiency, environment scaling) are best understood as a first-generation blueprint for developing this endurance capability, not as a solved problem.

This reframing also redirects the efficient attention research agenda away from compression and toward learned sparsity. The ablation in Section 2.1.2 (Tables 4-6) provides systematic evidence that all attention mechanisms which compress or truncate information—sliding windows, linear recurrences, even those that retain full attention in half the layers—incur an irreducible accuracy penalty on retrieval tasks at long context. The best compressive variant (SimpleGDN) loses 8.25 points on RULER at 128K after 190B tokens of training (Table 5). DSA, by contrast, loses 0.35 points (Table 6) while providing the same 1.5–2× computation reduction. The mechanism is qualitative, not quantitative: DSA selects which tokens to attend to but computes exact attention on the selected tokens, while compressive methods approximate the attention computation itself. This is a strong empirical argument that compressive attention has a fundamental accuracy ceiling that cannot be overcome by scale or training data, and that future work on efficient long-context processing should focus on better indexers (learned sparsity) rather than better compressors.

The paper also provides a reconciliation of conflicting findings in the self-correction and tool-use literature. Prior work had reached contradictory conclusions about whether LLMs can self-correct—some studies finding improvements through iterative refinement (Madaan et al., 2023), others finding that LLMs "cannot self-correct reasoning yet" (Huang et al., 2023). The paper's thinking modes (Section 3.1) suggest a resolution: self-correction works when the model is specifically trained to retain reasoning context across turns (Preserved Thinking) and to reason before every action (Interleaved Thinking), but fails when these mechanisms are absent and the model must re-derive state from scratch at each step. The "correct-to-incorrect reversion problem" documented in Section 6.1 of the original paper—where approximately 38% of correct answers get revised to incorrect ones without selection mechanisms—is a specific instance of this failure mode. The implication is that self-correction is not a general capability that emerges from scale but a specific skill that must be trained through appropriate data construction (retaining erroneous segments in SFT with loss masking) and supported through architectural features (thinking block preservation).

Finally, the paper demonstrates that open-weight models can reach frontier-level performance on real-world coding when the right training methodology is applied, but the demonstration comes with sharp boundary conditions. GLM-5 is competitive with or exceeds proprietary models on isolated coding tasks (SWE-bench Verified 77.8% vs. Claude Opus 4.5's 80.9%; SWE-bench Multilingual 73.3% vs. Claude's 77.5%) and on backend engineering (25.8% vs. 26.9% on CC-Bench-V2). But on chained multi-commit tasks, the gap is 9.3 points, and the paper explicitly attributes this to error compounding that the current training pipeline does not address. This establishes a research frontier: the problem is no longer whether open models can generate correct code (they can) but whether they can maintain a coherent model of the codebase state across cumulative modifications. The tools for tackling this—better state tracking, explicit memory mechanisms, self-verification at commit boundaries—are suggested by the paper's findings but not implemented.

Follow-Up Research This Work Enables

Separating model scale from training methodology in agentic endurance. The GLM-4.7-to-GLM-5 comparison confounds multiple changes: DSA architecture, parameter doubling, context extension, asynchronous RL, environment scaling, and thinking modes. A controlled experiment that trains a GLM-4.5-scale model (355B parameters) with the full GLM-5 post-training pipeline (asynchronous agentic RL, 200K context, thinking modes, scaled environments) would isolate the contribution of the training methodology from the contribution of model scale. If the methodology-scaled 355B model achieves, say, 70% of GLM-5's chained-task improvement over GLM-4.7, then the training pipeline is the dominant factor; if it achieves only 20%, then raw parameter count is driving the gains. The experiment is feasible because the environments (10K+ SWE tasks, terminal tasks, search tasks) are already constructed and the training infrastructure is described. The result would have direct practical implications: organizations deciding whether to invest in larger models or better training pipelines would have evidence on which lever provides more leverage for agentic capability specifically.

Synchronous-vs-asynchronous RL comparison with controlled compute budget. The paper presents the asynchronous RL infrastructure as enabling training on long-horizon trajectories, but provides no evidence that synchronous RL would fail to produce comparable agentic capability given equivalent total compute. A head-to-head experiment: take the same base model, the same environments, and the same total GPU-hours, and compare agentic benchmark performance (CC-Bench-V2 chained tasks, Vending-Bench 2, BrowseComp) after training with synchronous GRPO versus the described asynchronous pipeline. If asynchronous training produces significantly better agentic performance at equal compute, the mechanism (longer effective trajectories, better exploration, reduced policy lag) would be worth isolating. If performance is comparable, the asynchronous infrastructure is an efficiency win but not a capability enabler, and simpler synchronous pipelines can be used for agentic RL. The experiment would need to control for the off-policy bias in asynchronous training—perhaps by measuring the effective number of gradient updates per environment interaction in both settings. The slime infrastructure's support for both synchronous and asynchronous modes (Section 3.6) makes this experiment practical for the GLM team, though external replication would require building a comparable infrastructure.

Explicit state-tracking mechanisms for multi-commit error prevention. The CC-Bench-V2 chained tasks reveal that GLM-5's primary failure mode is error compounding across sequential commits: "a suboptimal edit in one task can silently break tests in subsequent tasks" (Section 6.2.3). This suggests a specific architectural direction: train the model to maintain an explicit codebase state representation that is updated after each commit and verified against ground-truth test results. A concrete experiment: during agentic RL training, add an auxiliary loss that requires the model to predict which test cases will pass or fail after each edit, using the actual test outputs (available in the SWE environment) as supervision. If the model learns to anticipate the downstream consequences of its edits, it may learn to avoid suboptimal changes that would break future tasks. Evaluation would compare chained-task pass@1 with and without this auxiliary loss, and would measure whether per-step test prediction accuracy correlates with chain-completion success. The environment infrastructure (Section 4.2.1) already extracts Fail-to-Pass and Pass-to-Pass test cases, making the supervision signal available without additional annotation.

Context management strategy transfer across models and tasks. The paper's keep-recent-k and Hybrid Hierarchical Context Management (HCM) strategies provide a 13.9-point improvement on BrowseComp for GLM-5 (62.0 → 75.9), and the paper claims the strategy generalizes across values of k and threshold triggers (Section 4.2.4). However, the strategy was developed and tuned specifically for GLM-5, and the paper evaluates it only on BrowseComp. A systematic transfer study would apply the same HCM strategy to other models (DeepSeek-V3.2, Kimi K2.5, Claude Opus 4.5) on the same BrowseComp benchmark, and would evaluate GLM-5's HCM strategy on different long-context agentic tasks (MCP-Atlas, Tool-Decathlon, SWE-bench tasks with large codebases). If HCM provides consistent gains across models, it's a general inference-time technique that should become standard for agent evaluations. If the gains are model-specific, the interaction between context management and model architecture (DSA vs. dense attention, context window size, training data composition) becomes the interesting question. The paper's BrowseComp evaluation configuration—standardized on OpenAI's evaluation prompt and o3-mini judge—provides a reproducible testbed for this experiment.

Environment scale return-on-investment for agentic RL. The paper constructs over 10K SWE environments, thousands of terminal environments, and a large search task dataset, but provides no ablation of environment scale. A controlled experiment: train identical base models with identical RL hyperparameters but varying numbers of SWE training environments (e.g., 1K, 5K, 10K, 20K), and measure SWE-bench Verified and CC-Bench-V2 performance. The key question is whether environment diversity saturates—do the first 5K environments provide most of the gain, or does performance continue to improve with each doubling of environment count? The answer has direct resource-allocation implications: environment construction involves substantial engineering effort (Dockerization, test extraction, validation), and knowing the shape of the scaling curve would help practitioners decide how many environments to build. The paper reports that repositories span 9 programming languages and that filtering yields approximately 10 million issue-PR pairs (Section 4.2.1), so the raw material exists for much larger environment sets; the bottleneck is the validation and construction pipeline cost.

Chained-task intermediate evaluation for diagnosing compounding error dynamics. The CC-Bench-V2 chained tasks evaluation reports only final pass@1 (52.3% for GLM-5, Table 8), but the chain structure permits a much richer analysis. At each step k in a K-step chain, one can measure: (a) the pass rate on task k in isolation (what fraction of agents complete task k correctly, regardless of prior task success), (b) the conditional pass rate on task k given success on task k-1, and (c) the regression rate (what fraction of agents who succeeded on tasks 1 through k-1 then fail on task k due to breaking earlier functionality). If the regression rate increases with chain position, the failure mode is genuinely state-tracking drift. If the unconditional pass rate drops while the conditional pass rate remains high, the failure mode is difficulty escalation rather than state tracking. This decomposition would precisely characterize the compounding error mechanism and would suggest different interventions: state-tracking drift calls for explicit memory or self-verification mechanisms; difficulty escalation calls for better planning or hierarchical task decomposition. The CC-Bench-V2 pipeline—which applies test patches from tasks 1 through k at each step to catch regressions—already generates the necessary intermediate signals; the experiment is an analysis, not a new data collection effort.

Practical Applications and Downstream Use Cases

Automated batch resolution of GitHub issues at scale. Organizations maintaining large open-source repositories with thousands of open issues can deploy GLM-5 with the OpenHands framework (used in the SWE-bench evaluation, Table 7) to attempt automated resolution. At 77.8% resolved rate on SWE-bench Verified, approximately 3 out of 4 isolated bug-fix issues would be correctly patched without human intervention, and the 4.0-point improvement over GLM-4.7's 73.8% means roughly 40 additional correct resolutions per 1,000 issues. The key practical constraint is that GLM-5's chained-task performance (52.3% on CC-Bench-V2, Table 8) means that issues requiring coordinated multi-file changes have roughly a coin-flip chance of correct resolution, so a human-in-the-loop verification step would be essential for production use. The SWE-bench Multilingual result (73.3%, second only to Claude Opus 4.5's 77.5%, Table 7) extends this applicability across Python, Java, Go, C, CPP, JavaScript, TypeScript, PHP, and Ruby—a language breadth that covers the vast majority of open-source development.

Autonomous codebase exploration and onboarding. New developers joining large projects spend days to weeks locating relevant source files and understanding project structure. GLM-5's repo exploration capability (65.6% on CC-Bench-V2, Table 8—slightly exceeding Claude Opus 4.5's 64.5%) enables a concrete deployment: given a natural-language question about where specific functionality is implemented ("Where is the authentication token refresh logic?"), the model navigates the repository (potentially tens of thousands of files, with target files at least 3 directory levels deep and carrying opaque names) and returns the relevant file locations. At 65.6% accuracy, this is not yet reliable enough for fully autonomous operation, but it is accurate enough to serve as a developer assistant that significantly accelerates the exploration phase—roughly 2 out of 3 queries correctly answered. The metric is pass@1 averaged over 3 runs, so individual queries may benefit from running multiple attempts and aggregating results.

Long-horizon business simulation and strategy testing. Vending-Bench 2 evaluates models running a simulated vending machine business over a year of sequential decisions, with performance measured in final account balance. GLM-5 achieves $4,432 (Table 7), a 4.3× improvement over DeepSeek-V3.2's$ 1,034 and competitive with Claude Opus 4.5's $4,967. For organizations using simulated environments to evaluate business strategies or train AI decision-makers, GLM-5 provides an open-weight alternative to proprietary models at a fraction of the inference cost (the paper's Chinese GPU adaptation claims 50% deployment cost reduction, Section 5). The practical deployment would involve running GLM-5 in the simulation environment over many independent runs to characterize strategy robustness—the single-run evaluation in the paper doesn't capture variance, but the model's 86.6% improvement over GLM-4.7's$ 2,377 suggests the underlying capability improvement is real rather than noise.

Web-scale research and information synthesis with context management. The BrowseComp result with HCM (75.9, Table 7—the highest among all evaluated models including proprietary ones) enables a practical deployment for automated research: given a complex question requiring evidence from multiple web sources, GLM-5 browses the web autonomously, manages its own context to avoid degradation over long browsing sessions, and produces a final answer. The 75.9 accuracy (compared to 57.8 for Claude Opus 4.5 and 59.2 for Gemini 3 Pro) means the model can correctly answer roughly 3 out of 4 complex multi-hop questions without human guidance. The keep-recent-k + HCM strategy (Section 4.2.4) is a pure inference-time technique requiring no model modification, making it immediately applicable to any deployment without retraining. The BrowseComp-ZH result (72.7 for Chinese-language browsing, Table 7) extends this applicability to non-English information ecosystems.

When to Prefer This Method

The paper does not articulate an explicit tradeoff matrix against named alternatives—it positions GLM-5 as advancing the state of the art across the board rather than as better-suited to specific problem types compared to specific competitors. However, the results do suggest implicit decision rules that emerge from the performance patterns:

Prefer GLM-5 over other open-weight models when the deployment involves sustained, multi-step coding tasks (Vending-Bench 2, CC-Bench-V2 chained tasks, BrowseComp with context management) rather than single-turn reasoning. The agentic benchmarks show the largest gaps to DeepSeek-V3.2 and Kimi K2.5, while the reasoning benchmarks (AIME, GPQA, HLE) show near-parity, indicating that GLM-5's agentic-specific training provides a capability that reasoning-focused training alone does not.
Prefer GLM-5 with Hybrid Hierarchical Context Management when the task involves extended web browsing or tool use where context length exceeds ~100K tokens. The 13.9-point BrowseComp improvement from context management (62.0 → 75.9, Section 4.2.4) is an inference-time gain requiring no model modification, and the paper reports that the strategy generalizes across parameter settings, making it a low-risk addition to any GLM-5 deployment.
Prefer a proprietary model (Claude Opus 4.5 or GPT-5.2 xhigh) when the task involves sequential multi-commit development where errors compound across steps. The 9.3-point gap on CC-Bench-V2 chained tasks (Table 8) is the largest on any metric, and GLM-5's 52.3% pass@1 means roughly half of multi-step development attempts will produce a broken codebase. For deployments where reliability across cumulative modifications is paramount, the proprietary frontier maintains a meaningful advantage.
Prefer GLM-5 when deployment budget and hardware constraints favor open-weight, self-hosted inference, particularly on Chinese GPU ecosystems (Huawei Ascend, Moore Threads, Hygon, etc.—Section 5). The paper's full-stack adaptation to seven domestic chip platforms and the claimed 50% deployment cost reduction in long-sequence scenarios make GLM-5 the only frontier-level open model with documented multi-platform Chinese GPU support, reducing dependency on NVIDIA hardware and enabling deployment in environments where proprietary API access is restricted or costly.