On June 17, 2026, Beijing-based Z.ai released GLM-5.2 - a 753-billion-parameter open-weight model under the MIT license with a 1M-token context window that, according to its published scorecard, beats GPT-5.5 on the benchmark most engineering teams use to evaluate coding agents. That combination - frontier benchmark scores, fully permissive license, downloadable weights - is unusual enough to deserve a close read rather than a headline skim.
This post is about what GLM-5.2 actually is, what the architecture does that is new, where the numbers are solid, and where the launch story quietly glossed over some friction.
What GLM-5.2 actually is
GLM-5.2 is Z.ai's flagship open-weights LLM, released on 13 June 2026. It is a 744B-parameter Mixture-of-Experts model with roughly 40B active parameters per token, a usable 1M-token context window, MIT-licensed weights, and two reasoning-effort levels. The MoE design matters for cost: only 40B parameters fire per forward pass, which keeps inference compute closer to a 40B-class model even though the full weight set is nearly 750B.
On the Artificial Analysis Intelligence Index v4.1 it scores 51, the highest of any open-weights model to date, and it is reported to match Claude Opus 4.8 and beat GPT-5.5 on several long-horizon coding benchmarks.
The benchmark delta is worth quoting precisely. GLM-5.2 beats GPT-5.5 on SWE-bench Pro (62.1 vs 58.6) and FrontierSWE (74.4 vs 72.6), and trails Claude Opus 4.8 by only about a point on FrontierSWE (74.4 vs 75.1) and MCP-Atlas (76.8 vs 77.8), all at roughly one-sixth of GPT-5.5's per-token price.
One honest note before moving on: Z.ai published zero official GLM-5.2 benchmarks at launch. Any hard performance number floating around immediately after release was inherited from GLM-5.1. The numbers above come from the scorecard published in the week following launch. They are now widely cited and corroborated across independent sources, but you should know they were not there on day one.
The IndexShare architecture and why the 1M window is real
Most 1M-token context claims deserve skepticism. Adding a large context window to a standard transformer architecture is computationally brutal: KV cache grows linearly with context length, and at a million tokens it can rival the model weights themselves in memory. Many models advertise 1M tokens but degrade sharply in practice past a few hundred thousand.
GLM-5.2 takes a different approach. GLM-5.2's IndexShare design - a shared indexer across every four sparse-attention layers, reported by Z.ai to cut per-token FLOPs ~2.9× at 1M context - is what makes the long window tractable at all. Concretely: the IndexShare mechanism computes routing indices on the first layer of a block and reuses them for subsequent layers, lowering per-token floating-point operations by 2.9× at maximum context length.
That arithmetic reduction is why this window is not pure marketing. Whether it holds across adversarial long-context evals (needle-in-haystack, multi-hop retrieval across a very large codebase) is still being tested independently, but the architectural basis for the claim is published and coherent.
The usable 1M-token context is available in the glm-5.2[1m] variant, with up to 131,072 output tokens per response - a 5× jump from GLM-5.1's 200K window.
131K output tokens in a single response is enough to return a large multi-file diff without truncation.
Multi-Token Prediction is also in the architecture: GLM-5.2 accelerates output generation by projecting up to five draft tokens simultaneously during inference, which boosts tokens-per-second throughput. That matters more than it might sound for agentic workflows, where a single task fires dozens of sequential tool calls. A faster model that finishes tasks in fewer wall-clock seconds often beats a marginally more accurate but slower one, because the agent loop is the bottleneck.
The MIT license and what it actually permits
Unlike many "open" models that are open in name only, GLM-5.2 ships under the MIT license, which means you can use it commercially, modify it, and redistribute it without the usual restrictions. That clears enterprise legal review in a way that the Llama Community License or RAIL licenses often do not.
The practical checklist for teams evaluating it:
- Commercial use: permitted without royalty or revenue conditions
- Fine-tuning: permitted; you own the resulting checkpoint
- Self-hosting behind a firewall: permitted; prompts and code never leave your boundary
- Redistribution of a modified model: permitted
- Air-gapped deployment: permitted
The 77.0 MCP-Atlas score is just below Claude Opus 4.8's 77.8, and the MIT license means you can stand it up behind your firewall without sending tool-call payloads to a third-party endpoint. For teams using MCP-connected agents on internal codebases, that combination - competitive tool-use scores, no data leaving the perimeter - is the actual value proposition.
Self-hosting GLM-5.2: the hardware reality
This is where the post has to be direct. The Hugging Face card confirms local-inference support via vLLM, SGLang, Transformers, KTransformers, and Unsloth, with 112 quantized versions available for llama.cpp, Ollama, and LM Studio. The tooling ecosystem is real and already mature. But the hardware floor is a datacenter floor.
The full BF16 checkpoint is about 1.5 TB, which would push you to roughly 16 H200s or a multi-node setup; FP8 halves that to the 8-GPU node most people target. Even the compressed path stays out of reach for most teams: NVIDIA's own quantized release, GLM-5.2-NVFP4, compresses stored weights to 381B parameters using its proprietary 4-bit float format and targets Blackwell-class datacenter silicon, tested on B200 and B300, not consumer GPUs. The accuracy cost is minimal - 89.39% on GPQA Diamond versus 89.52% for the FP8 baseline, a ~0.13-point gap.
Consumer cards can, in principle, run GLM-5.2 in a four-card setup with system RAM offloading, but users should expect single-digit tokens per second rather than the interactive speeds a hosted API delivers.
| Path | Weight size | Hardware | Speed |
|---|---|---|---|
| BF16 (full) | ~1.5 TB | 16× H200 | Production |
| FP8 (NVFP4) | ~744 GB | 8× H200 | Production |
| INT4 (quantized) | ~411 GB | 10× RTX PRO 6000 | Production |
| 4-bit GGUF | ~380-420 GB | 512 GB Mac Studio or EPYC server | Usable but slow |
| 2-bit GGUF | ~239 GB | 4× consumer cards + CPU offload | Single-digit tok/s |
There is also a second hardware cost that most guides understate: the KV-cache tax introduced by GLM-5.2's 1M-token context window means sizing a node purely against the FP8 weights figure without separately budgeting for cache growth at long context risks under-provisioning for the actual workload.
The honest summary: if you are running GLM-5.2 on your own infrastructure, you need a cluster, not a server. The API route (Z.ai's own endpoint, or hosted providers) is the practical path for most teams. The MIT license still matters even in that case - it means you have the option to move when your volume justifies the hardware.
GLM-5.2: common questions
What is GLM-5.2 and who made it?
GLM-5.2 is a 744-753B-parameter open-weight Mixture-of-Experts language model released by Z.ai (formerly Zhipu AI, Beijing) on June 13, 2026. It is MIT-licensed with a 1M-token context window and a MoE architecture that activates roughly 40B parameters per token, making inference cheaper than the parameter count suggests.
How does GLM-5.2 perform on SWE-bench Verified?
GLM-5.2 scores 62.1% on SWE-bench Pro, versus GPT-5.5's 58.6%, and 74.4% on FrontierSWE, versus GPT-5.5's 72.6%. It trails Claude Opus 4.8 by roughly one point on both. It ranks first among open-weight models on the Artificial Analysis Intelligence Index v4.1 with a score of 51. Benchmarks were not published at launch - they followed within a week.
Can you self-host GLM-5.2?
Yes, with datacenter hardware. The FP8 weights require roughly 8× NVIDIA H200 GPUs; the full BF16 checkpoint needs about 16. An INT4-quantized build fits on 10× RTX PRO 6000 cards. Consumer multi-GPU setups with CPU offload can run a 2-bit GGUF build but will see single-digit tokens per second - too slow for an interactive coding agent loop.
How does GLM-5.2 compare to Qwen3-Coder-480B?
Both are large MoE open-weight coding models. Qwen3-Coder-480B (Apache 2.0, ~35B active parameters, 256K native context) was positioned as state-of-the-art at its release and scores similarly on SWE-bench Verified. GLM-5.2 has a 5× larger native context window (1M tokens), uses MIT licensing, and led the Artificial Analysis Intelligence Index at launch. For pure coding benchmarks the gap is narrow; for repository-scale long-context tasks, GLM-5.2's 1M window and IndexShare architecture give it a structural edge.
Does the MIT license cover fine-tuned versions of GLM-5.2?
Yes. The MIT license permits modification and redistribution, including derivative checkpoints from fine-tuning. You own any fine-tuned version you produce. Verify the exact text on the Hugging Face model card before a production deployment, since license versions can vary across model family variants.