Z.ai GLM-4.6: What We Learned From 100 Million Open Source Downloads — Yuxuan Zhang, Z.ai

What does an open model release become once developers start building on it? For Z.ai, the starting point was GLM-130B in 2022. GLM-4.6 arrived after several years of releases spanning language, visual understanding and media generation. That history matters because the coding model sits within an ecosystem of models, tools and community projects rather than a single standalone release.

The family expanded through ChatGLM-6B for language, CogVLM for visual understanding, CogView for image generation and CogVideo for video generation. The model-family map separates those branches by color: white for language, pink for multimodal understanding, green for image generation and yellow for video generation. The visual-understanding branch later became GLM-V.

In 2025, Z.ai added the GLM-4-0414 dense models, including 9B and 32B variants, followed by GLM-4.5 and GLM-4.6 in its first mixture-of-experts family. Zhang reports more than 65 released models, over 100 million downloads across platforms including Hugging Face and ModelScope, and approximately 1,500 community GitHub projects. These are reported measures of ecosystem activity, not evidence of model accuracy.

GLM-4.6’s public-benchmark story begins with improvements over GLM-4.5, particularly in mathematics and coding. Zhang also reports advantages over DeepSeek V3.2 and Claude Sonnet 4 on several benchmarks. He explicitly preserves a limit to that comparison: Claude Sonnet 4.5 still has a noticeable lead. The claim is progress across selected evaluations, not universal superiority.

User preference supplies a different view. Zhang reports an LM Arena tie for first with GPT-5 and Claude Sonnet 4.5, describing GLM-4.6 as the only open-source model in that group. This is the talk’s historical leaderboard snapshot; its category and tie definition are unspecified. Its role in the presentation is to complement benchmark results with feedback from people trying the models.

An isolated programming puzzle does not exercise the full behavior of a coding agent. CC-Bench instead uses a test platform built around Claude Code to evaluate realistic development workflows. Version 1.1 adds 22 hard coding tasks, bringing the total to 74. The comparison includes Claude Sonnet 4, GLM-4.5, Kimi K2 and DeepSeek V3.1 Terminus.

The tasks span frontend development, internal tools, data analytics and algorithm implementation. For each model, the evaluation records the complete agent trajectory: planning, tool calls, code edits and execution. That makes the path to a result inspectable, rather than reducing the run to a final code sample. The benchmark and its trajectory release are presented as open source.

Zhang describes GLM-4.6 as a clear improvement over GLM-4.5 and close to Claude Sonnet 4. The spoken 68.6% figure conflicts with the displayed slide and published CC-Bench results: against Claude Sonnet 4, GLM-4.6 records 48.6% wins, 9.5% ties and 41.9% losses in the 74-task evaluation. The published methodology uses human-guided, iterative Claude Code sessions; completion determines the outcome, with efficiency and reliability used to distinguish runs that both complete the task. These are workflow judgments, not isolated unit-test pass rates.

The training account starts with a broad language base, then adds specialization. Zhang describes approximately 15 trillion general-purpose tokens from web pages, books, encyclopedias and multilingual content, initially using roughly 4,000-token contexts. A further approximately seven trillion code and reasoning tokens add high-quality repositories and step-by-step mathematics, science and programming material.

Repository-level mid-training changes what counts as a training example. Related files, issues, pull requests and diffs from one project are packed into the same long context. The model can then learn how a change crosses file boundaries, how a patch relates to an issue and how individual files fit into the project. Zhang describes extending the context to roughly 32,000 tokens so the key files of a medium-sized repository can be considered together. The useful unit becomes a connected project, not an isolated file.

Next come approximately 500 billion synthetic reasoning tokens covering mathematics, science and algorithms. Explicit thinking traces supply examples of task decomposition, reflection on mistakes and long chains of reasoning—the behaviors later needed when an agent must recover from an unsuccessful step.

The final described stage adds approximately 100 billion tokens of long-context and agent data, extending sequences to roughly 128,000 tokens; Zhang separately specifies a 200,000-token context for GLM-4.6. The historical GLM-4.5 technical report documents the corresponding progression as 4,096 → 32,768 → 131,072 tokens. That report is a GLM-4.5 training account, not a separate disclosure of every GLM-4.6 training detail.

Long contexts accommodate documents, codebases and extended conversations. Agent trajectories add the sequence of actions within those contexts: multiple tool calls, search and code execution. Together, they teach both how to retain a large working context and how to act within it.

slime, Z.ai’s open-source reinforcement-learning framework, uses SGLang for inference. Its central systems decision is to support different execution arrangements for different workloads. Short mathematics or code-completion tasks work well with colocated, synchronous training and inference: both use the same GPU pool, alternating between a training update and generation with the latest policy. This arrangement makes effective use of GPU memory and compute.

Software-engineering agents introduce a different timing problem. One rollout may open a browser, call a backend API and wait for an external response, while another finishes quickly. If every worker must advance together, the slowest tasks hold up the entire batch and leave GPUs idle. The bottleneck is no longer just model computation; it includes the environment’s response time.

slime’s hybrid architecture connects a Megatron batch-training engine, a high-throughput SGLang inference cluster and agent environments through a shared data buffer. Megatron consumes training data and updates weights. A routing function dispatches inference requests to SGLang. The buffer separates the production of trajectories from their consumption by training.

In synchronous mode, sampling and immediate updates share the GPU pool. In asynchronous mode, rollout workers interact with real environments and keep writing completed trajectories into the buffer. Training consumes those trajectories at its own pace, updates the model and periodically sends new weights back to the rollout workers. A slow browser or API interaction no longer blocks the whole training pipeline.

The precision policy follows the same separation of responsibilities. Main training remains in BF16 for stability. After each policy update, blockwise quantization produces an FP8 version of the weights for rollout workers. Expensive trajectory generation then uses FP8 while training retains BF16. Zhang reports a throughput benefit without supplying a numerical speedup.

The reasoning-RL curriculum changes problem difficulty as the model improves. It begins with medium-difficulty problems so that a batch contains both correct and incorrect answers. That variation in reward supplies a useful learning signal. Once those problems become easier for the model, training switches to extremely hard problems; with 512 samples, a correct solution can still appear occasionally. In the presented comparison, switching difficulty sustains improvement beyond the medium-only curriculum.

A separate experiment changes the allowed reasoning length. For a model already given supervised fine-tuning at 64K tokens, Zhang reports that an RL schedule progressing through 32K, 48K and finally 64K reduces long-context ability and average output length. Returning to 64K at the end does not fully recover the loss. Starting RL directly at 64K and keeping that budget throughout performs better in the shown experiment. Two stages of difficulty and one stage of length are compatible choices: one controls which problems the model faces, while the other preserves room to reason.

For code RL, the next comparison concerns how token losses become a batch loss. A sequence mean gives each sequence equal weight after averaging its tokens. A token mean instead averages across all tokens, so a longer sequence contributes more terms. Zhang reports that token-based averaging converges faster and more steadily in the presented experiment, while reducing the tendency to produce very short template answers just to collect reward.

A small Python example makes the weighting distinction concrete. Here, one sequence contains two token losses and another contains six. The sequence mean gives each answer half the batch weight; the token mean gives each of the eight tokens equal weight.

from statistics import mean

sequence_losses = [
    [1.0, 1.0],
    [3.0, 3.0, 3.0, 3.0, 3.0, 3.0],
]

sequence_mean = mean(mean(losses) for losses in sequence_losses)
token_mean = mean(
    loss
    for losses in sequence_losses
    for loss in losses
)

print(sequence_mean)  # 2.0
print(token_mean)     # 2.5

The example isolates aggregation: it does not specify the full RL objective. Its significance is that equal weighting of sequences and equal weighting of tokens are different optimization choices whenever output lengths differ.

The science-RL experiment changes the training data instead. A small set of expert-verified multiple-choice questions produces better results than mixed-quality data in the shown comparison. The report’s detailed account identifies GPQA-Diamond as the evaluation benchmark; this should not be read as training on GPQA itself. The result supports careful scientific-data selection in this experiment, rather than a general rule that adding data harms a model.

The multimodal part of the talk introduces GLM-4.5V, which supports image and video understanding. Zhang reports strong grounding and image-understanding results relative to contemporary open-source models. Its architecture has three main components: a vision-transformer encoder, an MLP projector and the GLM-4.5 base model as decoder.

The input representation aims to preserve native image resolution and aspect ratio instead of forcing every image into a fixed square. That matters for UI screenshots, long vertical images and presentation slides, whose layout carries information. For video, a time-index token is inserted after each frame. The token gives the model an explicit representation of temporal order, helping it distinguish successive events and understand actions or procedures.

GUI interaction extends earlier CogAgent work. GLM-4.5V supports interaction through mouse, keyboard and touch across browser, desktop and mobile environments. Visual understanding therefore serves an action loop as well as an interpretation task: the agent must understand the interface it is about to operate.

The first access route is self-hosting: GLM-4.6’s open weights and GLM-4.5V can be served through SGLang, vLLM or other compatible frameworks. Zhang describes SGLang and vLLM integrations as ready on release day, alongside ecosystem work with LLaMA-Factory and ms-swift.

Model size makes this a substantial infrastructure choice. Zhang describes GLM-4.6 as approximately 355 billion parameters and points to H100-class hardware as an example of the resources involved, not an exclusive requirement or complete sizing prescription. The recording then shows SGLang and vLLM deployment commands before moving to hosted alternatives.

The hosted Z.ai interface offers a route to coding and PowerPoint generation without running the model locally. A brief demo introduces a Google-search-related task through a single request. The talk does not develop that example into a detailed implementation walkthrough.

The GLM Coding Plan brings the model into Claude Code and other development tools. The accompanying demo concerns replacing the existing model in a Claude Code workflow with GLM-4.6. This separates the model choice from the coding interface: developers can try GLM within an established agent workflow instead of adopting an entirely new environment.

Z.ai’s post-release community activity includes Reddit AMAs, online sessions and in-person technical-sharing events. These provide places to ask questions after trying a model, alongside the website and API routes introduced in the closing resources.

For deeper study, Zhang points to the GLM-4.6 technical blog and the GLM-4.5 technical report. Discord provides a community channel; GitHub hosts the open-source models and README instructions for deploying them. The closing path runs from trying the hosted model to studying its training account and operating the weights yourself.