2026-06-18

GLM-5.2 Open Weights: What the MIT Release Actually Buys You

GLM-5.2 is a 744B-A40B model with MIT weights and a native 1M context—but running that window is a separate hardware, endpoint, and concurrency decision.

An MIT license fits in a short file. The GLM-5.2 BF16 checkpoint does not: the current Hugging Face tree contains 282 weight shards totaling 1,506,667,387,408 bytes. Even the FP8 variant is 755,632,050,320 bytes. That is the useful starting point for the GLM-5.2 open release—not a leaderboard victory lap, and not a promise that a million-token agent is now cheap to operate.

The release is genuinely permissive. The weights are public, the repository is tagged MIT, and the license grants broad rights to use, modify, distribute, sublicense, and sell copies subject to preserving the notice. But “open” answers a permission question. It does not answer which checkpoint to serve, how much accelerator memory the KV cache consumes, whether a provider endpoint accepts the account’s key, or whether a tool-using agent recovers cleanly after a streamed request dies.

This review reopens the live artifacts rather than repeating the launch summary. The result is a narrower and more useful decision: use the hosted route to evaluate GLM-5.2 unless control of weights or data justifies owning a very large inference stack; self-host only after a representative context-and-concurrency test fits the hardware you can actually operate.

The current artifacts correct the headline

The production version of this article called GLM-5.2 a 753-billion-parameter model released on June 13. The current first-party sources do not support that exact description. Z.ai’s GLM-5 repository labels the model 744B-A40B: about 744 billion total parameters and 40 billion active. The vLLM recipe rounds the same shape to roughly 743B and 39B active. The public Hugging Face repository records its creation on June 16, 2026.

That discrepancy is not a reason to distrust the model.

It is a reason to bind technical claims to named artifacts. Mixture-of-Experts counts are easy to round differently; an unsupported 753B figure becomes false precision when copied into pricing, hardware, and comparison tables.

1,048,576 positionsThe live config.json value behind the native 1M context claim.

78 model layersThree dense layers followed by sparse MoE layers in the current configuration.

256 routed expertsEight experts selected per token, plus one shared expert in the declared architecture.

128K maximum outputThe current Z.ai model guide’s output ceiling; input and output remain text-only.

The model card reports 74.4 on FrontierSWE, 81.0 on Terminal-Bench 2.1 with the Terminus-2 harness, and 62.1 on SWE-bench Pro. Those are relevant signals for long-horizon engineering. They are not interchangeable measurements: the footnotes use different harnesses, context caps, timeouts, generation limits, and judges. Treat the rows as reasons to run a pilot, not as a conversion table from benchmark points to production success.

MIT opens the case; it does not operate what is inside

The plain-language advantage of the repository is substantial. A team can inspect and retain the checkpoint, fine-tune it, build a quantized derivative, or serve it behind its own endpoint without negotiating a research-only license. The corresponding obligation is modest—keep the copyright and permission notice. The warranty clause is equally plain: the software is provided “as is.”

That last part belongs in the engineering decision. Open weights do not come with an uptime objective, regional endpoint, abuse-handling policy, capacity reservation, incident owner, or compatibility promise for your agent harness. Those contracts exist elsewhere, if they exist at all.

Open model shards pass through separate plugin, endpoint, capacity, and fallback gates — The license releases the checkpoint. A usable agent route still has to clear provider registration, endpoint selection, capacity limits, and recovery.

A read-only probe during this review makes the split concrete. Ten current primary surfaces returned HTTP 200, both checkpoint trees were measurable, and the machine-readable model configuration matched the published context claim. On the same host, openclaw models list --all --provider zai --json exited successfully with No models found. No credential was read and no installation was attempted. The result was not a provider failure; the Z.AI provider plugin simply was not installed.

Evidence boundary: this was source analysis, not an inference benchmark. No Z.AI key was used, no billable request ran, no checkpoint was downloaded, and no accelerator server was started.

The hosted OpenClaw route has three separate contracts

“OpenAI-compatible” is not the complete setup instruction. Current OpenClaw documentation gives Z.AI its own provider package, model catalog, endpoint choices, auth mapping, reasoning controls, and failure classification. The model reference is zai/glm-5.2, not a made-up glm-5-2-high name. The provider plugin comes first:

openclaw plugins install @openclaw/zai-provider
openclaw onboard --auth-choice zai-api-key
openclaw models list --all --provider zai

Catalog contract: can this installation name the model?

The final command is deliberately read-only. It should show the plugin-owned catalog row before anyone changes an agent’s primary model. A missing row is not evidence that the key is bad. It may mean the provider package is absent, the installed OpenClaw version predates the catalog entry, or the provider registry has not loaded.

Endpoint contract: which product did the key buy?

Z.AI documents different surfaces. The Coding Plan’s OpenAI Chat Completions base is https://api.z.ai/api/coding/paas/v4; the general API base is https://api.z.ai/api/paas/v4. OpenClaw’s auto-detect flow probes supported endpoints, while explicit onboarding choices can force Coding Plan global, Coding Plan China, general global, or general China. Using the wrong endpoint can bypass subscription quota or produce a rejection that looks like an ordinary auth problem.

Capacity contract: what happens when the model is busy?

Current pay-as-you-go pricing lists GLM-5.2 at

.40 per million input tokens, $0.26 for cached input, and $4.40 per million output tokens. Coding Plan subscriptions use plan quota instead. Z.AI says plan concurrency varies with tier and resource availability, and it describes general-purpose agent tools such as OpenClaw as best effort. Error 1302 means request rate limit; 1305 means temporary overload.

A production agent therefore needs bounded retries, a fallback policy, and a record of which endpoint answered. “Try again later” is not a recovery design for a tool call that may already have changed external state.

A one-million-token context is an allocation policy

The config declares the window; the serving stack decides how much of it is practical. Z.ai publishes BF16 and FP8 checkpoints. The live repositories make their scale hard to wave away:

Artifact	Measured weight shards	Measured bytes	Operational meaning
GLM-5.2 BF16	282	1.507 TB	Checkpoint storage and loading already require a serious multi-accelerator plan before KV cache.
GLM-5.2 FP8	141	755.6 GB	The practical self-host baseline, but not a small single-GPU artifact.
Native context declaration	—	1,048,576 positions	A capability ceiling, not a promise that full context and useful concurrency fit together.

The current vLLM recipe uses eight H200 or H20 accelerators for a single-node FP8 baseline. Its Docker example starts with a 131,072-token cap. The documented full-1M path uses eight B200 accelerators with FP8 KV cache, and the recipe calls --max-num-seqs the key control for sharing that memory. On AMD, it recommends starting lower and raising --max-model-len only when representative traffic leaves headroom.

A large context stream is divided across accelerator memory and concurrent request lanes — A long native window competes with concurrency for KV-cache memory. The serving envelope—not the config value alone—sets the usable limit.

This is the part release summaries usually omit.

A million tokens can be valuable for repository-scale work, but only if the relevant evidence survives retrieval and the task can afford the latency. Sending every file to the model may cost more, reduce concurrency, and make failures harder to replay. Start with a smaller cap, measure the miss that larger context fixes, and increase the window for that workload rather than for the headline.

Testing GLM-5.2 under the failure you expect

A useful GLM-5.2 pilot is not “ask a hard question and like the answer.” Give the hosted and self-hosted candidates the same bounded engineering packet: a repository snapshot, its tests, one explicit change, a tool schema, a stop condition, and a known recovery case. Preserve exact inputs and the model route so the comparison can be repeated.

Pin the surface. Record the hosted endpoint and model ref, or the checkpoint revision, quantization, vLLM version, parser flags, and context cap.
Run three context tiers. Use the same task at 128K, 256K, and the largest tier that fits. Look for an actual decision or failure that improves; do not reward token consumption.
Exercise tools, not just prose. Include one valid call, one schema rejection, one denied effect, and one long streamed response. Verify tool arguments and final state separately.
Kill one request after dispatch. The runner must determine whether an external effect happened before it retries. This is an application responsibility, regardless of model quality.
Measure the whole envelope. Capture time to first token, completion latency, output tokens, cached input, accelerator headroom, concurrent throughput, and operator intervention.
Prove exit. Switch the same workload to a fallback model or stop the local server without losing the task record, approval boundary, or recovery evidence.

Published benchmarks can help choose the candidate task. They cannot replace this drill. FrontierSWE says GLM-5.2 deserves attention for long-horizon engineering; it does not prove that your provider quota, repository shape, tool schemas, side effects, and latency budget produce the same result.

The decision is about ownership, not openness

Choose the hosted Z.AI route first when the goal is to evaluate coding quality, tool use, reasoning effort, and context behavior without operating hundreds of gigabytes of weights. Verify the provider plugin, endpoint family, catalog row, rate-limit behavior, and fallback before routing important work.

Choose self-hosting when retaining the checkpoint, controlling the serving boundary, or meeting a specific data-residency requirement is worth owning storage, accelerator scheduling, KV-cache policy, upgrades, telemetry, and recovery. Begin from the FP8 recipe’s conservative context cap; earn the larger window with measurements.

GLM-5.2’s open release matters because it gives teams a real exit path and a powerful model they can inspect and operate. Its most interesting number is not 744B, 1M, or 74.4. It is the distance between the permission granted by the license and the service level proved by your own run. Close that distance with one pinned workload. If the model survives the failure case and leaves evidence you can replay, then it belongs in the stack.

Sources checked against the live artifacts

Z.ai GLM-5.2 model card — architecture claims, benchmark methods, context, deployment links, and license tag.
Z.ai GLM-5 repository — current 744B-A40B label, checkpoint variants, supported serving frameworks, and reasoning-effort behavior.
Z.ai GLM-5.2 guide and pricing — current API capabilities and token prices.
OpenClaw Z.AI provider documentation — plugin, auth, endpoint choices, model ref, capacity notes, and read-only catalog check.
vLLM GLM-5.2 recipe — FP8 hardware baseline, context caps, KV-cache controls, and full-context serving envelope.