A coding benchmark called Terminal-Bench 2.1 has become one of the more reliable signals for agentic performance, and GLM-5.2 just scored 81.0 on it - four points behind Claude Opus 4.8, ahead of every other open-weight model, and at roughly one-sixth the per-token cost of GPT-5.5. That gap closed fast. Six months ago no open-weight model was within 15 points.
Released on June 13-17, 2026 by Beijing-based Z.ai (formerly Zhipu AI), GLM-5.2 is a 753-billion-parameter open-weight model under the MIT license with a 1M-token context window. The weights are on Hugging Face. The license imposes nothing: no regional restrictions, no revenue clauses, no approval requirements - enterprises can download, fine-tune, and commercially deploy the model with complete freedom.
That combination - frontier-adjacent coding performance, permissive licensing, self-hostable weights - is genuinely new. But the release also came with some odd information gaps, and those gaps matter before you build a pipeline on top of it.
What GLM-5.2 Actually Does Well
It is the strongest open-source model on standard coding benchmarks: 81.0 on Terminal-Bench 2.1 and 62.1 on SWE-bench Pro. The SWE-bench Pro score is meaningful because that benchmark tests real GitHub issue resolution rather than synthetic problems; GLM-5.2's 62.1 beats GPT-5.5's 58.6 but trails Claude Opus 4.8's 69.2.
The 1M-token context window is the feature that matters most to anyone building a coding agent. It represents a roughly 5x jump over GLM-5.1's 200K window, and the model supports up to 131,072 tokens of output per response - enough for large multi-file diffs in a single shot. For a repository-scale agent that needs to read a full codebase before touching anything, that changes what's possible in a single context pass.
GLM-5.2 also introduces effort level control, enabling users to explicitly balance model capability against task execution speed and computational cost. Two named levels - High and Max - let you run cheaper, faster inference for interactive IDE work and dial up to Max for batch refactors or complex multi-file tasks. It's a practical affordance that most models leave implicit.
On agentic real-world evals beyond leaderboard scores: GLM-5.2 scores 1524 Elo on GDPval-AA, a real-world agentic work benchmark - ahead of every other open model by a wide margin and level with GPT-5.5. That independent signal, not generated by Z.ai, is the number worth watching most.
The Architecture Trick That Makes 1M Context Cheaper
Most large MoE models nominally support long context but degrade badly past a few hundred thousand tokens because the attention computation becomes prohibitively expensive. GLM-5.2 addresses this with a technique called IndexShare.
IndexShare is a cross-layer reuse trick for sparse attention. Instead of recomputing the sparse-attention top-k indexer in every layer, GLM-5.2 runs the full indexer only once every four layers, and following layers reuse the selected token indices - keeping the same sparse attention idea but making 1M-token inference cheaper.
Z.ai reports a 2.9x reduction in per-token FLOPs at 1M context length as a result.
The MoE design compounds this. With roughly 40B active parameters per token, you are not paying dense-753B compute per token. The total weight is enormous, but the per-inference cost is closer to a 40B-class model. That is the architecture reason why the pricing can be as low as $0.91 per million input tokens from third-party hosts on OpenRouter, with Z.ai also offering cached input at $0.26 per million tokens for long-context workloads.
For teams who want to go fully self-hosted: the Hugging Face repo distributes the model across 282 safetensor files totaling 1.51 TB at native BF16 precision. That number is not a typo. You need multi-GPU enterprise infrastructure - A100 or H100-class - to serve it. The practical production paths are FP8 quantization to reduce memory requirements, or multi-node tensor parallelism.
The 2-bit quantized variant alone needs roughly 245 GB of combined memory. A teammate like Beagle, routing Slack queries to a hosted API endpoint, sidesteps this entirely - but teams building proprietary coding agents who want data never to leave their infrastructure should budget seriously for the GPU spend before committing.
Where the Hype Outpaces the Evidence
Z.ai's release process was unusual in a way that should give builders pause. Z.ai published zero official GLM-5.2 benchmarks at launch. Any hard performance number floating around at release was inherited from GLM-5.1. The independent scores on Artificial Analysis and GDPval-AA came from the community, not the lab. That is actually a reasonable validation path - third-party benchmarks are harder to game - but it means there was a 72-hour window where the hype was running ahead of any evidence.
No detailed model card or architecture paper has been published by Z.ai. IndexShare and the improved MTP layer are described only in partner product copy. Training data composition and size carry no public numbers. For a model you might route sensitive code through, that opacity is worth registering.
There is also a token-efficiency concern. Artificial Analysis notes that GLM-5.2 uses roughly 43K output tokens per task on average, which can improve long-horizon performance while also increasing inference cost.
GLM-5.2 on Max effort appears to spend roughly 2x more tokens than GPT-5.5 on equivalent reasoning tasks. If you are billing per-token through a hosted API, that eats into the cost advantage quickly on compute-heavy workloads.
And the model is text-only. Image understanding is confirmed absent, with no published roadmap for a vision variant. For a pure coding agent pipeline this is rarely a blocker, but it is a firm boundary.
it still trails Claude Opus 4.8 by 13%. The gap closes fast on standard tasks and is real on the hardest ones.
What This Changes for Teams Building Agentic Pipelines
The meaningful shift GLM-5.2 represents is not a benchmark number. It is that for the first time, an MIT-licensed open-weight model can plausibly sit inside a production coding agent - not as a fallback for when the closed API is too expensive, but as a first-line choice.
GLM-5.2 is meant to be the model inside a coding agent, not a chatbot - its strengths are in agentic, repo-scale, multi-file work. For teams with data-residency constraints or regulatory requirements, MIT weights mean code never leaves their machines, no per-token API cost, and full commercial freedom without the restrictions of non-standard licenses.
The evaluation path is specific. If your agent's primary workflow is navigating a large existing codebase, fixing bugs across multiple files, and generating multi-thousand-line diffs, the combination of 1M context and strong SWE-bench Pro numbers makes GLM-5.2 worth a direct comparison against whatever you are paying for today. Run the same ten representative tasks against your current model and against GLM-5.2 via a hosted endpoint - it integrates with Claude Code, Cline, and Kilo Code already
- then compare output quality and token cost.
If your agent does web scraping, image analysis, or anything that requires vision, stop here and pick a different model. If you need to run on a single machine or a small team's GPU cluster, the hardware reality rules it out. But if the workload fits and the data-sovereignty argument is real for your organization, GLM-5.2 is the first open-weight model where "just use the closed API" is no longer the obviously correct default.