GLM-5.2 vs Claude Opus 4.8: Open-Weight Coding at Frontier Pricing

GLM-5.2 scores 62.1% on SWE-bench Pro and 81.0 on Terminal-Bench 2.1 per Zhipu’s model card, four points behind Claude Opus 4.8’s 85.0 on the latter benchmark. The practical difference for coding teams is less about those four points than about how each model can be paid for: Opus 4.8 is a closed-weight model reachable through Anthropic’s API, while GLM-5.2’s MIT-licensed weights are self-hostable at hardware cost, and Z.ai sells a flat-subscription Coding Plan alongside its usage-based API business.

Zhipu confirmed the launch in a June 15, 2026 Hong Kong exchange filing by Beijing Zhipu Huazhang Technology (02513.HK), reported by New Times Space, and the Hugging Face model cards went up on June 16. The GLM-5 repository lists GLM-5.2 at 744B-A40B with a 1M-token context window. The family has since grown: the repository front page leads with GLM-5.3 and GLM-5.3-Flash, and both GLM-5.2 download pages point to GLM-5.3 as the newer version.

What Is GLM-5.2 and How Does It Compare to Opus 4.8?

GLM-5.2 is the flagship of the GLM-5 line from Zhipu (Z.ai), the model business of Beijing Zhipu Huazhang Technology, publicly listed as 02513.HK. The repository designates it 744B-A40B, and its download table lists every GLM-5 flagship, from GLM-5 through GLM-5.2, at that same designation. The active-parameter reading is explicit in the repository’s description of the GLM-5 baseline, which “scales from 355B parameters (32B active) to 744B parameters (40B active).”

Claude Opus 4.8 is Anthropic’s closed-weight frontier model; the repository groups it with the “closed-source frontier” and benchmarks against it directly. No Opus weights are published, so its side of any cost comparison runs through Anthropic’s API terms, which Zhipu’s materials do not address.

On standard coding benchmarks the repository calls GLM-5.2 “the strongest open-source model.” Every figure below comes from the comparison table on Zhipu’s model card, which also includes columns for GLM-5.1, Qwen3.7-Max, MiniMax M3, DeepSeek-V4-Pro, GPT-5.5, and Gemini 3.1 Pro:

Zhipu’s footnote marks the Opus 4.8 HLE result as a full-set score while GLM-5.2’s 40.5 is the text-only subset, so that row is not a like-for-like comparison.

On the Terminus-2 Terminal-Bench row, GLM-5.2 trails 81.0 to 85.0, the four-point gap in the headline. The same table reports Opus 4.8 at 69.2 on SWE-bench Pro, a 7.1-point gap; GLM-5.2’s 62.1 there is a 3.7-point improvement over GLM-5.1’s 58.4. The long-horizon rows split the difference: FrontierSWE puts GLM-5.2 within 0.7 of Opus 4.8, while SWE-Marathon leaves a 13-point gap and NL2Repo a 20.8-point gap. The second Terminal-Bench row, which Zhipu labels “Best Reported Harness,” reverses the headline: GLM-5.2 at 82.7, a figure the card’s footnote attributes to a Claude Code 2.1.167 harness, against Opus 4.8 at 78.9. Zhipu’s API documentation summarizes the long-horizon picture the same way, describing GLM-5.2 as sitting between Claude Opus 4.7 and 4.8 on FrontierSWE, SWE-Marathon and PostTrainBench, and as the highest-ranked open model on those suites. All of it is vendor-reported; the provenance questions sit in the switching section below.

How the GLM-5.2 Architecture Works

Three features matter for production deployments:

Mixture-of-experts with sparse activation. The 744B total does not activate on each token; roughly 40B parameters are active per forward pass, and that active slice, not the total, determines per-token inference compute.

IndexShare sparse attention. Zhipu’s term for an attention efficiency technique that reuses the same indexer across every four sparse attention layers, “reducing per-token FLOPs by 2.9× at a 1M context length” per the repository. Zhipu does not say what the 2.9× is measured against; sharing one indexer across four sparse layers could as easily be benchmarked against per-layer indexers as against anything else. For teams running long-context coding tasks, it is the mechanism Zhipu credits with keeping a 1M-token window serviceable rather than theoretical.

MTP speculative decoding layer. A multi-token-prediction layer that generates multiple output tokens per decoding step; Zhipu says the improved layer increases speculative-decoding acceptance length by up to 20%.

Supported deployment frameworks are SGLang, vLLM, Transformers, KTransformers, and Unsloth, with minimum versions listed on the model card; Ascend NPU deployments run through vLLM-Ascend, xLLM, or SGLang. Weights are publicly downloadable in two precisions: BF16 at zai-org/GLM-5.2 and FP8 at zai-org/GLM-5.2-FP8. As of November 2026 the BF16 repository records 324,229 downloads in the past month against 133,831 for FP8, so most current downloaders are pulling full-precision weights.

The weight license is MIT per the model cards, which Zhipu summarizes as “no regional limits, technical access without borders.”

What GLM-5.2 Costs vs Claude Opus 4.8

The comparison divides into two funded paths for GLM-5.2 and one for Opus 4.8.

Via Z.ai’s hosted API. The BigModel documentation serves GLM-5.2 through an OpenAI-style chat/completions endpoint with official zai-sdk clients for Python and Java. The documented surface covers thinking modes, streaming, function calling, structured output, context caching, and MCP tool use, with a 1M-token input window and 128K maximum output. Beyond usage-based API billing, Z.ai sells the GLM Coding Plan, a flat subscription marketed for agents and IDEs, with seat management, usage dashboards, and an enterprise pledge that subscriber data is never used for training. Zhipu’s documentation notes GLM-5.2 was opened to Coding Plan subscribers ahead of general release, and the Hong Kong filing frames the model as a driver of call volume for the company’s open platform and API business. Two caveats for buyers: the plan page markets the subscription as powered by GLM-5.3, GLM-5.3-Flash, and a GLM-5.3-FlashX-Legal variant, so a subscriber today gets a newer model generation than the one benchmarked here; and the page presents features and FAQs rather than tier prices, so price the current tiers directly against your Anthropic bill before comparing. GLM-5.2 itself remains available through the self-hosted weights and its documented API.

Via self-hosted weights. The MIT license means no per-token fees and no usage caps; hardware is the constraint. At FP8, 744B parameters is roughly 750 GB of weight storage at one byte per parameter, before any KV cache, which rules out single-GPU serving. KTransformers appears among the supported frameworks with a linked tutorial, and the repository’s per-framework cookbooks and recipes are the practical starting point for capacity planning.

Claude Opus 4.8 has no self-hosting path.

What GLM-5.3 Changes for This Comparison

Two newer models sit above GLM-5.2 in the repository. GLM-5.3 uses the same base model as GLM-5.2; in Zhipu’s words, “every gain comes from post-training.” The company claims a 50% improvement over GLM-5.2 on its in-house Z.ai Code Bench, open-source state-of-the-art results on Terminal Bench 3.0 and Agents’ Last Exam, and state-of-the-art vulnerability discovery on CyberGym, with exploitation-benchmark scores it says more than double GLM-5.2’s. These are vendor claims published in Zhipu’s own repository, and no independent evaluation appears alongside them there.

GLM-5.3-Flash is a different proposition: a newly trained 320B-A18B base with a hybrid sparse-and-linear attention design meant to cut long-context serving costs, plus Manifold-Constrained Hyper-Connections for scaling efficiency, trained on a 30T-token multimodal corpus. For self-hosters, 320B-A18B is a much smaller footprint than the 744B flagship line. One operational detail from the repository: GLM-5.2 accepts only high and max for reasoning_effort, while GLM-5.3 and GLM-5.3-Flash add a low setting, defaulting to max.

Why the 1M Context Window Matters for Coding Teams

GLM-5.2’s card describes the window as “a solid 1M-token context that stably sustains long-horizon work” and frames the model as the first in the GLM-5 line to deliver long-horizon capability on a 1M-token context (model card). Zhipu’s API documentation describes a single delivered engineering task that processed more than 850K tokens across requirements, implementation, testing, and deployment, close to filling the window in one run. The same documentation claims GLM-5.2’s stability at very long context exceeds Opus’s in some real tests, and links a technical blog for the detail; the page itself carries only the summary claim, so treat that comparison as Zhipu’s assertion until the blog or an independent evaluation substantiates it.

For coding work, a 1M-token window fits:

• Large codebases in a single context, with complete test suites alongside the source they test
• Entire dependency chains for multi-file refactoring tasks
• Project-level work where module boundaries, interface contracts, and directory structure must stay coherent across one long task, which is the use case Zhipu’s documentation leads with

IndexShare is Zhipu’s stated answer to serving cost at that length: the 2.9× per-token FLOPs reduction at 1M context is the company’s basis for calling a full window affordable rather than theoretical. Zhipu’s benchmark table does not include a context-window row for Opus 4.8, so the 1M figure has no published counterpart in this comparison.

What Teams Should Consider Before Switching

The benchmark picture is less uniform than the four-point headline. GLM-5.2 trails on the Terminus-2 Terminal-Bench row (81.0 vs 85.0) and on SWE-bench Pro (62.1 vs 69.2), leads on the Best Reported Harness row (82.7 vs 78.9) and on AIME 2026, and sits within a point on FrontierSWE. Terminal-Bench 2.1 measures autonomous coding in terminal environments, the closest published proxy in this comparison for agentic coding performance, and every figure is Zhipu-reported.

Benchmark provenance. All head-to-head numbers come from Zhipu’s own model card and repository; no independent evaluation appears in Zhipu’s published materials. The card’s evaluation footnote shows how much configuration moves these scores: SWE-bench Pro ran through OpenHands at a 400K context, Terminus-2 at 256K, and the Claude Code harness with output tokens extended to 128K and scores averaged over five runs. Moving between the two Terminal-Bench harnesses shifts GLM-5.2 by 1.7 points and Opus 4.8 by 6.1.

Inference infrastructure. Self-hosting the BF16 or FP8 weights requires multi-GPU infrastructure; the FP8 weights alone are roughly 750 GB. Teams without it should compare the current Coding Plan price against their actual Anthropic API spend, keeping in mind that the plan now serves GLM-5.3-generation models. GLM-5.3-Flash at 320B-A18B is the lighter self-hosting option if the newer generation is acceptable.

Context window utilization. If coding workflows regularly exhaust their current window through large repositories, full test suites, or long multi-file refactors, a stably usable 1M window is structurally significant regardless of benchmark delta.

Migration surface. The documented API is an OpenAI-style chat/completions endpoint with official SDKs and a reasoning_effort control. Zhipu’s own evaluation ran GLM-5.2 inside a Claude Code 2.1.167 harness, which shows the pairing is achievable in practice, but the BigModel documentation does not describe an Anthropic Messages-compatible endpoint, so confirm what your agent supports before counting on a drop-in swap.

Thinking presets. GLM-5.2 accepts high and max reasoning-effort values only, defaulting to max, comparable in framing to Anthropic’s extended thinking mode, though the implementations differ.

The underlying trade has not moved: Opus 4.8 leads most published coding rows in Zhipu’s own table, and GLM-5.2 delivers a large share of that performance under an MIT license with a flat subscription on top. GLM-5.3’s arrival potentially improves the value side of that trade for new subscribers, if the vendor’s claims hold.