GLM 5.2 against the shipping market: where the first frontier-adjacent open model wins, and where it doesn't

GLM 5.2 is the first open-weight model that belongs in the same sentence as Claude Opus 4.8 for long-horizon coding, and on a few benchmarks it edges past GPT-5.5 at roughly a sixth of the output token price. It is not a Claude replacement — Opus 4.8 still leads every coding benchmark anyone has measured — but for teams where cost, license control, or where your source code physically goes is part of the decision, it moves the line in a way no previous open model has.

This is a comparison piece, not a launch recap. We put GLM 5.2 next to what is actually shipping — the closed frontier (Claude, GPT, Gemini) and the open-weight field (DeepSeek, Qwen, Kimi, MiniMax) — on coding benchmarks, context, license, price-per-token, price-per-task, and self-host hardware. Then we tell you where we’d put it in a production loop and where we wouldn’t. Every number here is traceable; where the evidence is thin, we say so rather than dress it up.

One caveat sets the tone. The model is eight days old as we write this, and almost every headline benchmark is vendor-reported on Z.ai’s own harness. The relative rankings are probably directionally right. The absolute numbers deserve the skepticism you’d apply to any vendor’s launch slide.

What GLM 5.2 actually is

GLM 5.2 is a 753-billion-parameter Mixture-of-Experts model with 40B active per token, from Beijing-based Z.ai (Zhipu AI). It shipped to GLM Coding Plan subscribers on June 13, 2026, and the MIT-licensed weights landed on HuggingFace on June 16. The context window is one million tokens, five times its predecessor, and Z.ai has been serving that 1M window in production since launch rather than holding it as a spec-sheet maximum. Maximum output is 128K tokens, and there are two reasoning efforts — High and Max — with Max recommended for multi-step coding.

The architecture earns one paragraph because it explains the price and the speed later. GLM 5.2 uses sparse dense attention with an optimization Z.ai calls IndexShare: every four attention layers share one lightweight indexer, cutting per-token FLOPs by 2.9× at 1M context. An enhanced multi-token-prediction layer raises speculative-decoding acceptance by up to 20%. Post-training ran on an internal RL stack (SLIME) aimed at agentic, tool-using workflows. This is a model built for long-horizon coding agents, not for chat.

The backstory is real, and it gets exactly one sentence of weight: GLM 5.2 was trained on 100,000 Huawei Ascend 910B chips with no Nvidia hardware anywhere in the run, and Z.ai released the open weights the day after the US ordered Anthropic to disable Fable 5 for foreign nationals. That is context for why a frontier-adjacent open model exists right now, not a reason to adopt or avoid it. Adoption is an operations decision, and the rest of this piece is the operations.

The benchmark picture

Lead with where GLM 5.2 genuinely wins, because the wins are real and specific. On long-horizon coding benchmarks reported alongside the open-weight release, it sits above GPT-5.5 and below Claude Opus 4.8 — a position no open model has held before.

Table A — Long-horizon coding benchmarks

Benchmark	GLM 5.2	Claude Opus 4.8	GPT-5.5	Notes
SWE-bench Pro (vendor)	62.1	69.2	58.6	Z.ai harness; not standardized
Terminal-Bench 2.1	81.0	~85	~84	CLI agent tasks
FrontierSWE	74.4	75.1	72.6	Long-horizon multi-step
PostTrainBench	34.3	37.2	28.4	Agent post-training tasks
SWE-Marathon	13.0	26.0	12.0	Ultra-long-horizon systems; 2× gap
MCP-Atlas	76.8	82.2	—	Tool-use / MCP
GDPval-AA v2	1,524	—	~1,514	General agent; GLM 5.2 ties GPT-5.5
Code Arena Frontend (Elo)	1,595 (#2)	—	—	Human vote; behind Fable 5 only

All scores vendor-reported unless stated. No SWE-bench Verified score for GLM 5.2 has been published.

Three numbers carry the “where it wins” claim. On SWE-bench Pro it scores 62.1 against GPT-5.5’s 58.6. On FrontierSWE, 74.4 against 72.6. And on GDPval-AA v2, a general-agent task suite, it scores 1,524 — effectively level with GPT-5.5’s 1,514. For a class of work — multi-step agent tasks that run for many turns inside a codebase — GLM 5.2 is now in a dead heat with one of the two closed frontier leaders. That is the headline, and it is earned.

The honest ceiling is the rest of the same table. Claude Opus 4.8 is ahead on every benchmark measured: SWE-bench Pro 69.2, Terminal-Bench ~85 against 81.0, MCP-Atlas 82.2 against 76.8. The one to stare at is SWE-Marathon — 26.0 for Opus, 13.0 for GLM 5.2. That is a 2× gap, the widest delta in the whole set, and SWE-Marathon is the benchmark that covers the deepest work: building compilers, optimizing kernels, the multi-hour systems tasks where a model has to hold a large mental model and stay coherent across dozens of steps. If that is the work your agents do, this number is the one that should decide the question, and it is not flattering to GLM 5.2.

Now the methodology, because the audience here will ask anyway. Every GLM 5.2 score in Table A comes from Z.ai’s own harness. None of them has appeared on the Scale AI SEAL standardized SWE-bench Pro leaderboard as of June 24, and that gap is not a footnote. Vendor harnesses, with tuned scaffolding and retry logic, routinely run 10 to 30 points above standardized conditions. The same leaderboard’s top standardized score is GPT-5.4 (xHigh) at 59.1%. Opus 4.8’s vendor-reported 69.2% corresponds to roughly 51.9% standardized (the Opus 4.6 thinking entry). Apply that haircut evenly and GLM 5.2’s 62.1 lands somewhere in the same band as everyone else — the relative order likely holds, the absolute claim does not. This caveat is not specific to GLM 5.2. It applies equally to the Opus and GPT numbers in the same column. Read the table as a ranking, not as a score.

Two gaps in the evidence are worth naming directly. First, there is no published SWE-bench Verified score for GLM 5.2 — the single most-cited coding metric, and the one your stakeholders will ask about by name. The predecessor GLM-5 scored 77.8% on Verified; 5.2 may be higher, but Z.ai has not published it, so we cannot put it next to Opus 4.8’s 88.6% or GPT-5.5’s 88.7%. That is a hole in the available data, not evidence of weakness. Second, no Aider polyglot run exists, vendor or third-party. Where these cells are blank, they are blank because the number does not exist yet, and we would rather show you the hole than fill it with a guess.

Code Arena: the signal that’s harder to game

One benchmark in the set is not a pass-rate number, and it is the one we trust most. Code Arena (arena.ai) is an Elo leaderboard built on blind pairwise human votes on real coding tasks — you cannot tune a harness to win it, because the scoring is a person picking the better of two outputs without knowing which model produced either. On the Frontend WebDev board, GLM 5.2 (Max) ranks #2 globally, behind only Claude Fable 5 (currently restricted), with +29 Elo over Claude Opus 4.7 (Thinking). Among models you can actually call today it is the top-ranked option, and on Design Arena it sits at #1 with an Elo of 1,360, ahead of every available Opus variant.

This matters because human-preference signal is the closest thing we have to “would a developer accept this PR,” and it sidesteps the contamination and harness arguments entirely. It is also narrow, and we will not oversell it: Code Arena’s frontend board measures frontend and UI generation. It says nothing about backend services, infrastructure code, or systems work. A model can be #1 at generating a clean React component and still trail badly on a kernel-optimization task — and the SWE-Marathon line in Table A says that is roughly what is happening. Use the Code Arena result for exactly what it covers. If your team’s output is UI and web frontends, this is the most relevant single data point in the piece. If it is distributed systems, it is close to irrelevant.

Two independent practitioners back the broader framing. The interconnects.ai analysis calls it “the first [open model] one could plausibly substitute for Opus/GPT-class workflows,” and adds the useful aside that “benchmarks are half dead these days,” which is part of why the human-vote signal carries weight. Daniel Bergholz, testing it on a real Next.js production site through OpenCode, wrote that it was “the first time an open-weights model has genuinely impressed me on real code” — and noted, unprompted, that the model explained why it chose client-side filtering over an API-per-keystroke given the site’s ISR constraints, then deployed unchanged.

That same hands-on session is also where the rough edges show. Bergholz reported the OpenCode harness crashing after the task completed (a harness bug, not the model), and the model began auto-committing to git after he mentioned committing once. The auto-commit behavior is a flag for any team that wants explicit control over what lands in version history — it is the kind of helpfulness you have to constrain before you trust it in a loop. Simon Willison, who seeded the wider attention with his June 17 write-up, kept his testing to creative coding rather than agentic workflows: GLM 5.2 produced a strong animated SVG pelican, but its opossum-on-a-scooter output was a step down from GLM-5.1’s and skipped animation entirely. None of this is damning. It is the normal texture of a model eight days into public use — uneven in ways the benchmark table cannot show you, which is exactly why the hands-on reports matter. The session that produced the working blog-search feature cost about $0.26. Hold that number; it is the bridge to the part of this piece that should actually drive your decision.

How open got here, and why this release is different

The shape of this moment is familiar. The open-versus-closed dynamic has run this cycle before: a lab releases weights, the ecosystem builds on them, the closed labs keep a capability edge, and the open models close most of the gap over the following six to twelve months. We watched it through the LLaMA era from 2022 to 2024. What changed in 2026 is that the open releases stopped coming from Meta and started coming, in volume, from Chinese labs — and they stopped trailing by a generation.

DeepSeek set the precedent. DeepSeek V3 in January 2026, then V3.2, established that a Chinese lab could ship open weights competitive with the GPT-4 class at a fraction of the training cost, and price the API low enough — V3.2 at $0.23/M input and $0.34/M output — to make the cost argument on its own. V4 Pro then pushed the capability side, landing 80.6% on SWE-bench Verified. Qwen, Kimi, and MiniMax filled in around them. By June 2026 the open-weight coding field was crowded and genuinely good, but it had a ceiling: none of these models was in the conversation for the hardest long-horizon coding, and none paired frontier-adjacent scores with a usable 1M context.

GLM 5.2 is the release that pushes through that ceiling. The interconnects.ai analysis puts it at roughly 6.8 months behind Claude Opus 4.5’s November 2025 release — squarely on the six-to-nine-month lag that the open field has been holding. The jump from the base GLM-5 is specific and measurable rather than a headline number: GLM-5 already scored 77.8% on SWE-bench Verified, comparable to Opus 4.5; GLM-5.1 scored 58.4 on SWE-bench Pro. The 5.2 upgrade is mostly the 5× context expansion, the IndexShare inference efficiency work, and sharper RL post-training for agentic tasks. That is why it is the open model that now sits in the long-horizon coding conversation rather than the cost conversation alone — and why the comparison that actually matters is not GLM 5.2 against last year’s open models, but GLM 5.2 against the closed frontier and against DeepSeek on price. The next two sections are those two comparisons.

The cost problem nobody puts on the launch slide

Here is the thing a production team needs before anything else: GLM 5.2 is verbose, and verbosity is a cost. It burns roughly 43,000 output tokens per Intelligence Index task — about 62% more than GLM 5.1’s 26,000 and roughly 79% more than MiniMax M3’s 24,000 for comparable work. At $4.40 per million output tokens, that is about $0.19 per task in output alone, and Artificial Analysis puts the all-in figure at roughly $0.46 per task. The model is genuinely near the top on intelligence and, in their words, “sits off the most attractive quadrant” on the intelligence-versus-tokens chart. You pay for the reasoning in tokens, and at scale the tokens add up fast.

Set it against the open-weight field and the gap is stark.

Table B — Open-weight comparator snapshot (June 2026)

Model	SWE-bench Verified	Context	License	Input $/1M	Output $/1M	AA Index
DeepSeek V4 Pro	80.6%	1M	MIT	$0.44	$0.87	44
Qwen 3.6 Plus	78.8%	—	Apache 2.0	$0.29	$1.65	—
Kimi K2.6	76.8%	—	Open weight	~$4	~$4	43
MiniMax M3	—	1M	Open weight	~$1.20	~$1.20	44
GLM 5.2	— (5.0: 77.8%)	1M	MIT	$1.40	$4.40	51

GLM 5.2’s Verified score is unpublished; 77.8% is GLM-5 (the base, not 5.2). The Verified gap with DeepSeek V4 Pro may be larger than the open-weight Pro scores suggest.

DeepSeek V4 Pro is the comparison that should give a cost-driven team pause. It scores 80.6% on SWE-bench Verified — a metric GLM 5.2 has not published a 5.2-era number for at all — and it produces equivalent work at about $0.05 per task, roughly a ninth of GLM 5.2’s cost. At 1,000 coding tasks a day, that is the difference between about $189/day and about $50/day. Over a quarter, on a busy agent loop, you are choosing between a five-figure and a low-five-figure inference bill for output that, on the one standardized coding metric both can be measured on, favors the cheaper model. Kimi K2.6 lands in between at about $0.31/task. GLM 5.2 wins the Artificial Analysis Intelligence Index outright at 51 — seven points clear of the next open models — but the Index is a multi-task suite, and the per-task cost is the price of topping it.

The closed frontier sits in its own column, and the price-per-token story flips the open-weight argument back on its head.

Table C — Commercial comparison (all models)

Model	Context (tokens)	License	Input ($/1M)	Output ($/1M)	Open weights
Claude Opus 4.8	200K	Proprietary	$5.00	$25.00	No
GPT-5.5	~128K	Proprietary	$5.00	$30.00	No
Gemini 3.1 Pro	1M	Proprietary	$2.00	$12.00	No
DeepSeek V4 Pro	1M	MIT	$0.44	$0.87	Yes
Qwen3-235B-A22B	1M	Apache 2.0	$0.46	$1.82	Yes
MiniMax M3	1M	Open weight	~$1.20	~$1.20	Yes
Kimi K2.6	—	Open weight	~$4.00	~$4.00	Yes
GLM 5.2	1M	MIT	$1.40	$4.40	Yes

On raw token price GLM 5.2 is a fraction of the closed frontier — $4.40 output against GPT-5.5’s $30 and Opus 4.8’s $25. That is the “sixth of the cost” line, and against the closed models it holds. The trap is reading it as cheap in absolute terms. The verbosity means the per-task cost can erase a chunk of the per-token advantage, and against the open field — DeepSeek at $0.87, Qwen at $1.82 — it is the expensive option, not the cheap one. The combination that GLM 5.2 owns, and that nothing else does today, is frontier-adjacent coding scores plus a 1M context plus MIT licensing in one model. If you need all three, you pay the verbosity tax to get them. If you only need two, something cheaper covers you.

One more honest gap: the 1M context is live, but its quality at extreme length is unverified. No independent needle-in-a-haystack or long-context retrieval benchmark for GLM 5.2 had been published as of June 24. Practitioner reports confirm it works on long coding trajectories, with one note that instruction fidelity can start to slip above 64K tokens. “Works at moderate long context” is supported. “Usable at the full 1M” is a Z.ai claim no third party has yet checked. Plan around the verified range, not the spec sheet.

Running it: cloud and self-host

If you run it as a managed API, you have options. OpenRouter lists 13-plus providers. The cheapest serious one is GMI on FP8 at about $0.72/M blended and ~184 tokens/sec; the fastest is Baseten at ~278 t/s for $0.90 blended. Throughput varies 7.2× across providers, so the provider you pick matters as much as the model. The catch sits in the latency column: first-token latency runs 8 to 14 seconds across every provider measured. That is fine for an async agent loop chewing through a queue. It is not acceptable for an interactive, chat-style developer assistant where a person is waiting on the cursor. Match the deployment to the workload.

If you self-host — which is the entire point of the open weights for some teams — the hardware floor is real.

Table D — Self-host hardware (GLM 5.2)

Config	VRAM	Speed	Best for
FP8 full precision	744 GB (8×H200)	180–280 t/s	Enterprise cluster
AWQ INT4	372 GB (4×H200)	100–150 t/s	Production self-host floor
2-bit GGUF (Unsloth)	239 GB	3–6 t/s	M4 Ultra Mac, solo dev
Cloud (GMI, cheapest)	Managed	~184 t/s	Starting point

Full FP8 precision needs about 744 GB of VRAM — eight H200s — and that is before you account for a 1M-token KV cache, which pushes it toward 820–900 GB. AWQ INT4 at 372 GB (four H200s) is the realistic production self-host floor. The eye-catching number is Unsloth’s 2-bit dynamic GGUF: it squeezes the footprint to about 239 GB, which fits a 256 GB M4 Ultra Mac Studio — but at 3 to 6 tokens per second. That is a single-developer experiment on a desk, not a team server. Supported frameworks cover the field: vLLM, SGLang, Transformers, KTransformers, and Unsloth. It runs in Claude Code, Cline, and OpenCode today, so it drops into existing agent tooling without custom glue.

The compliance note belongs here, with the ops, because it is an ops decision and not a politics one. If you call the Z.ai cloud API rather than self-hosting, your data routes through infrastructure subject to China’s National Intelligence Law, whose Article 7 requires Chinese organizations to support national intelligence work. A US House inquiry opened in May 2026 naming Zhipu among PRC-origin AI firms under review. The clean part of this: the law applies to the hosted API, not the weights. Download the MIT-licensed weights and run them on your own hardware, and that exposure goes away — the file on your GPUs does not phone home. For a team handling sensitive or regulated source, that distinction is the whole reason self-host exists, and GLM 5.2 makes it cheaper to reach than any frontier-adjacent model before it.

Where it makes sense, and where it doesn’t

We’d reach for GLM 5.2 in four situations, and we’d reach past it in four others. Direct version:

Pick GLM 5.2 when:

• Your target is beating GPT-5.5 on coding at lower token cost, not matching Opus 4.8. On long-horizon coding benchmarks it does that today.
• You need a 1M-token context with open weights. No other open model combines frontier-adjacent coding scores and a 1M window at this level right now.
• Your work is frontend or UI generation. It is #1 on Code Arena among available models, and that is human-vote signal on the exact task type.
• License and data control are load-bearing. MIT with no commercial restrictions, downloadable weights, no usage telemetry, and self-hosting that resolves the API compliance question.

Reach past it when:

• Cost-per-task is the binding constraint. DeepSeek V4 Pro scores 80.6% Verified at about $0.05/task against GLM 5.2’s ~$0.46. On a high-volume loop that is a different inference bill by an order of magnitude.
• You do deep systems work — compilers, kernels, multi-hour coherence. The 2× SWE-Marathon gap against Opus 4.8 is real and it is exactly this category.
• You need interactive latency. The 8–14 second first-token wait rules out chat-style loops; this is an async-agent model.
• You’re sending sensitive source through the cloud API without legal sign-off. The China National Intelligence Law risk applies to the API. Self-host the weights or don’t use it for that data.

The pattern underneath the matrix: GLM 5.2 is the strongest open option when the constraint that’s actually binding you is access, license, or context — and it is the wrong tool when the binding constraint is raw cost-efficiency or the hardest tier of systems coding. Know which constraint is yours before you read the benchmark table, because the table can be made to argue either side.

What have you actually shipped with it

This model is eight days old. The benchmarks are vendor-reported, the standardized scores are not in, the Verified number does not exist, and the 1M context is unproven past moderate lengths. Every honest take on GLM 5.2 right now — including this one — is reasoning from launch slides and a handful of early hands-on reports. The thing that turns that into real signal is production data from people running it in anger.

So we are asking directly. Have you put GLM 5.2 in a production loop? What did it do well — and where did it break? Did the verbosity show up on your bill the way the per-task math predicts? Did the 1M context hold past 64K, or did instruction fidelity slip? Would you keep it in the loop, or did you roll back to something cheaper or stronger? Tell us what you shipped and what it cost you. The community gets honest signal one production run at a time, and yours is worth more than any vendor benchmark in this post.