GLM-5.2: The Open-Weight Model That Beats GPT-5.5

This article covers GLM-5.2, released by Zhipu AI (Z.ai) under a permissive MIT license. Figures are from the official Z.ai announcement; a few conceptual diagrams are original illustrations built to reinforce the mechanics, and are labelled as such.

Introduction

For most of the last two years, the story of frontier AI was a story of closed labs. The best models lived behind APIs, their weights guarded, their architectures described only in vague blog posts. Open-weight models were the plucky underdogs — good enough for hobbyists, never quite good enough to threaten the leaders.

GLM-5.2 is the model that makes that framing feel out of date.

Released by the Chinese lab Zhipu AI under a permissive MIT license — no regional limits, no usage restrictions — GLM-5.2 is, by Z.ai’s evaluations, the highest-ranked open-source model. It quadruples its predecessor’s context window from 200K to 1M tokens, and on long-horizon coding tasks it slots in between Claude Opus 4.7 and 4.8 while beating GPT-5.5. You can download the weights, run them on your own hardware, and use them commercially.

The most direct way to see what changed is to look at agentic coding performance as a function of how much the model is allowed to “think”:

The interesting question is not that GLM-5.2 is good — plenty of models are good. It’s how a model with a million-token context window can be served cheaply and quickly enough to be practical. The answer is a cluster of efficiency tricks built on top of sparse attention — IndexShare, KVShare, and a sharpened Multi-Token Prediction head. This article walks through the architecture, builds intuition for IndexShare with a hands-on visualizer, looks at the real benchmarks, and ends with what the community actually said.

Architecture for 1M Context

When GLM-5.2 extends the maximum context from 200K to 1M tokens, the primary inference bottleneck shifts away from raw computation toward KV-cache capacity and long-context kernel overhead. The architecture is a redesign aimed squarely at that shift. Z.ai’s own diagram captures the three moving parts:

Underneath, GLM-5.2 is a Mixture-of-Experts (MoE) model: rather than running every parameter on every token, it routes each token through a small subset of “expert” feed-forward networks — you get the knowledge capacity of a huge model at the inference cost of a much smaller one. (Independent analyses put it at roughly 744B total parameters with ~40B active per token.) Conceptually:

On top of the MoE backbone, GLM-5.2 builds on two ideas from the DeepSeek sparse-attention lineage:

• Multi-head Latent Attention (MLA) — compresses the key/value cache into a low-rank latent space, shrinking the memory footprint that normally explodes at long context.
• DeepSeek Sparse Attention (DSA) — instead of letting every token attend to every other token (which costs $O(n^2)$), a lightweight indexer scores all candidate tokens and keeps only the top-k most relevant ones for each query. Attention is then computed over that small selected set.

DSA is what makes long context affordable in principle. But it has a hidden cost, and closing that cost is exactly what GLM-5.2’s headline contribution does.

The IndexShare Trick

Here is the subtle problem with sparse attention. The expensive part of dense attention — comparing every query against every key — doesn’t fully disappear. To decide which top-k tokens to keep, the indexer still has to score the query against all previous tokens. That scoring step is itself an $O(n)$-per-token operation, and crucially, standard DSA recomputes it in every single layer.

At a 1M-token context with ~90 layers, that indexer becomes the dominant cost. You are paying to re-rank a million tokens, ninety times over, for every token you generate.

GLM-5.2’s insight is almost embarrassingly simple: the set of relevant tokens doesn’t change much from one layer to the next. So why recompute it every layer?

Concretely, layers are grouped in fours. The first layer of each group computes the indexer and picks the top-k tokens; the remaining three layers skip the indexer entirely and attend over the indices their group-leader already chose. That eliminates the indexer’s dot-product and top-k computation in three out of every four layers.

How much does this save? Let $D$ be the per-layer compute that is roughly independent of context length (the MLA projections and the MoE feed-forward), and let the indexer cost scale with context length $n$. For a model of $L$ layers with index groups of size $g$, the per-token compute is:

The reduction factor is therefore $\dfrac{D + \alpha n}{D + \alpha n / g}$. When the context $n$ is small, the indexer is negligible and the two are basically equal. But as $n$ grows, the $\alpha n$ term dominates and the ratio approaches $g$. At a 1M-token context with $g = 4$, GLM-5.2 reports a 2.9× reduction in per-token FLOPs — most of the way to the theoretical 4× ceiling.

Interactive: The IndexShare FLOPs Visualizer

The interactive below lets you feel the scaling. Drag the context length to see how the indexer’s cost takes over at long context, and drag the group size to trade compute savings against index freshness. Group size 1 is plain DSA (no sharing); group size 4 is GLM-5.2’s choice.

Notice two things. First, at short context the two bars are nearly identical — IndexShare buys you almost nothing on a 4K prompt. Its entire value is unlocked at long context, which is precisely the regime GLM-5.2 targets. Second, pushing the group size past 4 keeps shrinking the bar, but Z.ai stopped at 4: beyond that, index staleness starts to hurt quality more than the compute saving is worth. Z.ai’s own measurement of single-token FLOPs versus position confirms the scaling — the gap between GLM-5.1 and GLM-5.2 widens with context length, reaching the headline 2.9× at 1M tokens (the right-hand panel of Figure 2).

KVShare and Multi-Token Prediction

IndexShare cuts the indexing cost, but two more changes do the heavy lifting for real serving.

KVShare lets the Multi-Token Prediction module reuse the main model’s KV cache instead of maintaining its own — important because, past 200K tokens, the bottleneck is no longer compute but KV-cache capacity.

Multi-Token Prediction (MTP) is GLM-5.2’s speculative-decoding engine. A small MTP head drafts several future tokens at once, which the main model then verifies in a single pass — accepted drafts are free speed. GLM-5.2 retrains this head with two goals: minimize the draft loss and maximize the acceptance rate. With the number of MTP steps set to 7, the acceptance length rises ~20% over the baseline (from 4.56 to 5.47 accepted tokens per step in coding scenarios — see the right panel of Figure 2). IndexShare is applied to the MTP layer too: the indexer runs on the first speculative step and the rest reuse its indices.

The payoff: throughput at long context

These tricks compound. Because GLM-5.1 simply runs out of context past 200K, the only fair comparison at extreme length is GLM-5.2 against itself at shorter lengths — and the throughput advantage grows steadily as sequences get longer.

Benchmark Results

Across eight standard LLM benchmarks evaluated at maximum thinking effort, GLM-5.2 improves on GLM-5.1 by a wide margin and closes much of the gap to the closed-source frontier. The clearest single jump is on Terminal-Bench 2.1 (81.0 vs. 63.5), landing within a few points of Claude Opus 4.8 (85.0). On SWE-bench Pro it scores 62.1 (vs. 58.4 for GLM-5.1), and it leads the comparison set on MCP-Atlas (77.0).

Why do these long-horizon numbers matter more than the standard benchmarks? The more telling test is long-horizon coding — multi-step tasks, run over many hours, where the model must plan, write, run, and revise across very long sequences. This is the regime the 1M context and IndexShare were built for, and it’s where GLM-5.2 separates itself from the open field and beats GPT-5.5.

To make that capability usable, GLM-5.2 exposes selectable thinking-effort levels — Non-Thinking, High, and Max — that trade latency for depth (Figure 1). Z.ai recommends Max for complex multi-step coding where the model needs to plan and revise across long sequences, and lighter levels for everyday use.

What the Community Said

The reception was warm but not uncritical. The lead thread on Hacker News drew 373 points and over 450 comments, and the discussion is more revealing than any benchmark.

The dominant note was gratitude to Chinese labs “for being open with their work” — a recurring theme as Western frontier labs tighten access. For many developers, GLM-5.2 is less a single model than evidence that the open-weight ecosystem is keeping pace.

The sharpest technical discussion wasn’t about IndexShare at all — it was about Z.ai’s slime asynchronous RL training framework. One widely-upvoted comment argued that “the actual gap between frontier and non-frontier models right now is RL infrastructure, not pre-training compute.” If that’s true, an openly-described RL stack may matter more in the long run than any single architecture trick.

The criticism was honest too:

• Running it locally is brutal. 744B parameters do not fit on a laptop, or even most workstations. Quantized GGUF builds exist, but “open weights” and “runnable at home” are not the same sentence at this scale.
• Top scores don’t mean every output lands. A “pelican on a bicycle” SVG generation impressed people; an opossum attempt was called “such a step down from GLM-5.1.” A #1 index score is an average, not a guarantee.
• Business-model tension. Some users flagged pricing and packaging changes around the GLM-5 line, a reminder that sustaining open-weight releases is an unsolved economic problem.

Key Takeaways

References