GLM-5.3: the same base model, a month of post-training, and a cyber capability nobody planned

mdjsonmcpcopy↗ai

2026-08-14 · 15 min · agents · post-training · reinforcement-learning · security

Why read this

Solid· top 85%

Diffs the 5.2 and 5.3 configs, counts active parameters from all 141 shard headers (41.25B, not 40B) and shows Unsloth's "2-bit" figures mix two files.

• Original analysis
• Widely used
• Concrete numbers to act on

·Training & RL·Needs a workstation GPU·Custom licence·Practitioner model

How this was scored

Is it new?

1 of 3: An incremental tweak

Can I trust it?

2 of 3: Measures key facts from files, code or configs

Can I run it?

2 of 3: Open code or weights with real limits

Will I understand it?

1 of 3: Partial mechanism

Can I act on it?

2 of 3: A concrete recipe, numbers or comparison

Will it last?

1 of 3: Relevant for months

Does it affect many?

2 of 3: A widely used model, tool or lab release

Only here?

2 of 3: A teardown or measurement few others did

Score 57 of 100, ranked 290 of 454 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

Z.ai's GLM-5.3 post opens with a sentence most labs would bury:

Scaling post-training is all we did for GLM-5.3.

It is the same base model as GLM-5.2. No new pretraining run, no new architecture, nothing to report about parameter counts because none of them changed. What changed is a month of additional post-training on the stack they had already built — IndexShare for long-context processing, SAO for RL on long-horizon tasks, and slime for large-scale asynchronous training — pointed at more environments, more diverse tasks, and more compute.

That makes the release unusually easy to read. Every number below is a post-training delta, which is a rarer thing to be able to say than it sounds.

What a month of post-training bought

Fourteen benchmarks where both models are scored, GLM-5.3 ahead on all fourteen. The two that dominate the story:

• Terminal-Bench 3.0: 4.6 → 28.3. A 6.2× move, and the largest on the board. It is also the one to be most careful with — GLM-5.2 scored 4.6, which is close enough to the floor that the model was essentially not playing. Going from not playing to 28.3 is a real capability change, but it is not the same kind of evidence as moving a mid-range score.
• SWE-Marathon: 19.4 → 42.5, and AutomationBench: 26.2 → 48.2. Both roughly double, both on long-horizon agentic work, which is where Z.ai says the environment scaling was aimed.

At the other end, Agents' Last Exam moves 23.8 → 28.5, a 1.20× gain — the smallest of the sixteen. The gains are real and they are not uniform.

Where the environments came from

The part of the post I found most interesting is not a benchmark. Z.ai describes the bottleneck moving off the model entirely:

As agent capability improves, much of the difficulty in scaling post-training moves from the model to the environment.

Their answer is to synthesize the environments, and for a subset of tasks the reward signal too. Research agents collect task patterns from real work and turn them into runnable long-horizon environments with multi-step dependencies and hidden state; a judge agent then attempts each task to confirm it is actually solvable. Verifiers are synthesized without access to the reference solution, and solver trajectories are used to find and close reward shortcuts. A verifier that passes oracle, no-op and unsolved-state checks produces a binary reward they consider reliable enough to train on directly.

That trio of checks is the load-bearing detail. An oracle check catches a verifier that rejects correct solutions; a no-op check catches one that accepts doing nothing; an unsolved-state check catches one that was already satisfied before the agent started. Those are the three ways a synthesized reward usually turns out to be worthless, and they are checkable without a human reading the task.

Z.ai is direct that this is not yet automatic: the pipelines "still require a meaningful amount of human-in-the-loop work."

The environments themselves are aimed at something closer to a job than an exercise. Their example is an ML infrastructure task where the model gets the same working environment as an engineer — compute clusters, storage, internal documentation, codebases, experiment results — and has to diagnose bottlenecks across a training stack, implement optimizations, run experiments, and deliver a measurable end-to-end speedup without breaking correctness. Some tasks, they say, represent several days of work for an experienced engineer.

The honest reading of the table

"The most capable open-weights model for coding" is a carefully worded claim and it survives checking. Against open models GLM-5.3 is 16–0 over GLM-5.2, 12–0 over Qwen3.8-Max, 10–4 over Kimi K3, and 7–2 over DeepSeek-V4 Pro. Against the closed frontier it is 6–9 versus Fable 5 and 4–9 versus GPT-5.6 Sol.

Counted across the whole field rather than pairwise, GLM-5.3 holds the top score on 3 of 16 rows — CyberGym, AutomationBench, and GDPval-AA v2. Publishing a table where you lead three rows and lose thirteen is not the normal shape of a launch post, and the word doing the work in the headline is open-weights.

Two smaller notes on the table. Thirteen of the 112 non-GLM-5.3 cells are blank, so several head-to-head records rest on fewer than sixteen rows — the DeepSeek-V4 Pro comparison is nine rows, not sixteen. And ExploitGym is reported as 2h / 6h pairs rather than a single score, so any ranking of that row depends on which budget you pick.

Token efficiency is the better result

The claim I'd have led with is the one about cost, not capability.

expand

At Max effort GLM-5.3 reaches 34.5% at roughly 75K output tokens per task, against GLM-5.2's 23.4% at 96K — more accurate and cheaper, which is the direction that rarely happens on its own. At High effort it reaches 31.4% at around 50K tokens.

Z.ai compares that last figure to "Claude Opus 4.8 at 29.5% with 120K," which is true and worth reading precisely: 29.5% is Opus's Max effort, not its High. The comparison is GLM-5.3's High against Opus's Max. As an efficiency-frontier argument that is legitimate — the whole point of the chart is that the curves sit in different places — but it is not a like-for-like row.

The post is also straightforward that the frontier still belongs to someone else: "GLM-5.3 remains behind Claude Fable 5, which reaches 39.5% at Max effort."

One detail in the figure's own subtitle deserves attention: the benchmark was evaluated on Claude Code 2.1.207. Every model in that chart was scored through a competitor's harness. Given how much a harness shapes agent results, holding it fixed across models is the right call, and it is unusual to see it stated on the chart itself.

The cyber result, and what it actually says

This is the part Z.ai describes as a surprise:

As we scaled post-training, cyber capability developed faster than we expected.

They added vulnerability discovery data and environments to the training mix expecting the model to get better at finding and reasoning about flaws. What they report instead is that it began reasoning across multiple stages of exploitation and forming coherent plans for complete chains.

Both cyber claims in the post are accurate. GLM-5.3 does hold the top CyberGym score at 84.5 — narrowly, over Fable 5 at 83.8 and GPT-5.6 Sol at 83.6, but it is a genuine lead over closed models. And its gains really are largest further up the chain when measured against GLM-5.2: 2.23× on ExploitBench, 3.3× on ExploitGym at 6h.

Put the two sentences next to each other and they suggest a model leading at exploitation. The same table says otherwise. One rung up from discovery, GLM-5.3 sits at 54.4 on ExploitBench against 78 and 76.5. At full chains under a six-hour budget it clears 130 problems against 247 and 293. The gap to the closed models widens at precisely the rate the capability is described as growing.

Alongside this, Z.ai published a disclosure ledger: 2,436 findings tracked, 53 publicly disclosed, 2,383 still under embargo, 1,097 rated critical or high, across 269 open-source projects. The detail that stops you is the age distribution — the oldest flaw was introduced in 1981, and on average a vulnerability had been sitting in a codebase for 26.6 years before it was found. That is a claim about the state of open-source security as much as about the model.

It is also the context for the release schedule. The weights are not out yet:

We will release the weights in two weeks after launch, once safety evaluation and hardening are complete.

A two-week hold between announcement and weights, explicitly attributed to safety evaluation, is a reasonable response to having just demonstrated automated vulnerability discovery at scale. It also means nobody outside Z.ai can check any of the above yet.

What to take from it

The headline result is not the benchmark table, which shows a strong open-weights model that trails the closed frontier — a familiar position. It is the claim that a month of post-training on a fixed base moved fourteen benchmarks, several of them by more than 2×, with output token counts going down. If that reproduces when the weights land, the interesting variable in this release is the environment synthesis pipeline, not the model.

The caveats: Z.ai Code Bench is private, so its numbers cannot be independently checked by construction — a deliberate anti-contamination trade with a real cost. Thirteen table cells are blank. The weights are two weeks out. And the cyber capability that is described as emergent is, on the evidence published alongside it, still a discovery capability rather than an exploitation one.

The weights land, and confirm it

The two weeks passed. zai-org/GLM-5.3 is on Hugging Face, and the central claim of this article — same base model as GLM-5.2, nothing to report about parameter counts because none of them changed — stops being something to take on Z.ai's word and becomes something to check against a file.

So: fetch both config.jsons and diff them.

Fifty-six top-level keys across the union of the two files. Fifty-four are byte-identical. The two that differ are quantization_config — 5.3 ships an fp8 block-quantization spec that 5.2's file doesn't have the key for at all — and transformers_version, a library-metadata bump from 5.12.0 to 5.15.0 with no architectural content. Everything that describes the model itself — 78 layers, 256 routed experts at top-8, a 6,144 hidden size, the 1M-token context, the DeepSeek-V3-style noaux_tc/sigmoid aux-loss-free router — is unchanged.

One architectural detail is worth pulling out on its own: indexer_types, a 78-entry list that alternates in groups of four — three full layers, then full, shared, shared, shared repeating. A full layer computes its own sparse-attention token selection; a shared layer skips that computation and reuses a nearby full layer's index instead, and index_share_for_mtp_iteration: true extends the same reuse into the speculative-decoding layer. Twenty-one of the 78 layers do the full computation; the other 57 borrow it. It is the same cross-layer index-reuse idea Tencent's Hy4-preview ships under the name IndexCache — whether one release directly inspired the other isn't stated in either model card, but the two arrived within about two weeks of each other, which is a reasonable signal that reusing a neighboring layer's sparse-attention index is becoming a standard move for anyone building on DeepSeek Sparse Attention, not a one-off trick specific to either model.

Counting the parameters directly. Z.ai's own materials never state a parameter count for GLM-5.3 — the whole point of the launch was that nothing changed — so the number to check is Unsloth's: their docs describe GLM-5.3 as "a new 744B parameter (40B active) model." That number can be verified without downloading 1.5TB of weights. The repo's model API reports a per-dtype element count — BF16, F8_E4M3, F32 — summing to exactly 753,329,940,480 total parameters, but that total alone can't say how many are active per token, because it doesn't know which tensors are routed experts. For that, the shapes are needed, and the checkpoint ships as 141 safetensors shards. Each shard's header — a tensor-name-to-shape map — sits in the first few kilobytes of the file, readable with two HTTP range requests per shard (8 bytes for the header length, then that many bytes of JSON) without touching the weight data at all. Unioning all 141 headers gives the shape of every one of the model's 118,629 tensors.

Summed directly, every tensor's element count — including the fp8 quantization scale factors, which live in the same shards but aren't real parameters — comes to 753,375,793,584, about 45.85 million over the API's figure. Dropping every weight_scale_inv tensor closes that gap to exactly zero: 753,329,940,480, matching Hugging Face's own count to the last digit. That match is the useful part — it means the shape data is being read correctly, and the active-parameter number built from it can be trusted the same way.

Of those 753.33B parameters, only the mlp.experts.* tensors are conditionally active — 8 of each layer's 256 routed experts fire per token, everything else (attention, the shared expert, embeddings, the router, layernorms) runs in full. Layer index 78 turns out to be a 79th layer beyond the 78-layer backbone: it carries its own eh_proj/enorm/hnorm tensors, the signature of a DeepSeek-V3-style multi-token-prediction module, with its own attention block and its own 256 routed experts. Splitting it out:

The backbone-only total, 743.38B, lands within 0.1% of Unsloth's stated 744B — good evidence their figure is backbone-only, and good evidence the shape-based method is sound. The active count is the one that doesn't close as cleanly: 41.25B backbone-only, or 41.84B counting the MTP layer's own routing, both 3–5% above the stated "40B active." I'd trust the number computed here over the rounder one — it comes directly from the tensor shapes the model actually ships with, cross-checked exactly against an independent total from Hugging Face's own API, where "40B" reads like a round marketing figure that may predate final shapes or simply round down for the headline.

What else the release confirms. The license is broad — free use, modification, redistribution, commercial deployment, no royalty — with one specific carve-out: an organization running a "Model as a Service" business whose aggregate revenue (with affiliates) exceeds $10 billion over any trailing 12 months must pass a Z.ai security review before commercial use. That threshold excludes essentially everyone who might read this. Deployment support arrived unusually wide for a day-zero release: the model card lists SGLang, vLLM, TokenSpeed, Transformers, KTransformers, Unsloth, and Ascend-NPU stacks (vLLM-Ascend, xLLM, SGLang) as supported serving paths at launch, not "coming soon." And reasoning_effort accepts low, high, or max, defaulting to max — but per Unsloth's docs, "thinking cannot be disabled." Unlike some 2026-era releases that ship an explicit no-think switch for latency-sensitive use, GLM-5.3 has no off position; every call reasons, at a budget you choose.

The GGUF quants, and a "2-bit" that means two different files

Unsloth shipped Dynamic GGUF quants the same day, twelve variants from a full BF16 checkpoint down to 1-bit. Their docs page makes two accuracy claims — "Dynamic 1-bit GGUF reaches ~76% top-1 accuracy while being 85% smaller. Dynamic 2-bit reaches ~81% accuracy while being 83% smaller" — and then, in the walkthrough further down the same page, recommends a specific file for people actually trying to run it.

Sum the repo's own file listing by folder and the ladder is exactly what the docs describe at the ends: BF16 at 1,508.0GB, and the smallest 1-bit variant at 216.7GB, an 86% shrink. The middle is where it gets specific. UD-Q2_K_XL is 253.9GB — a 1 − 253.9 / 1508.0 ≈ 83.2% reduction, which is the file the "~81% accuracy... 83% smaller" sentence is describing. UD-IQ2_M is a different, smaller, importance-quantized file at 238.6GB — a 1 − 238.6 / 1508.0 ≈ 84.2% reduction — and it's this second file the walkthrough actually recommends: "We will be utilizing the 239GB UD-IQ2_M quant for the best balance of accessibility and accuracy." Read the two sentences as one fact — 239GB, 83% smaller, ~81% accuracy — and they don't describe any single file that exists. The 239GB figure and the 83%/81% figures belong to two different quants, 15.3GB apart, both of which Unsloth calls "2-bit" a few paragraphs apart on the same page. Neither number is fabricated; the shorthand just quietly stitches one file's size to its neighbor's accuracy claim.

The hardware side holds up better than the promotional framing suggests it might. Unsloth's separately published minimum-memory table pairs each bit-width with a floor — 223GB for 1-bit, 245GB for 2-bit, up to 810GB for Q8_0 — and the specific worked example, "the 2-bit dynamic quant UD-Q2_K_XL uses 254GB of disk space [and] works well in a 1×24GB GPU and 256GB of RAM with MoE offloading," is careful in a way that's easy to miss: it says 256GB of RAM, not "a 256GB Mac." That distinction matters, because the two aren't interchangeable — Apple's MacBook Pro line tops out at 128GB of unified memory even on the largest M-series chip, so any Mac actually offering 256GB has to be a Mac Studio, not a laptop. Unsloth doesn't make the MacBook claim here; it names a RAM figure and a GPU, and leaves the reader to supply the hardware. That's the more carefully worded of the two Mac-adjacent claims circulating around this release — a separate MLX-specific promotional claim, about running a smaller GLM-5.3-Flash variant on a MacBook Pro specifically, is covered in its own piece on this site and does not hold up the same way.

Between the two sections above, the pattern repeats: Z.ai's own claim about the model — same base, no architecture change — checks out exactly against the weights. Unsloth's claims about serving it check out on the totals and the hardware table, and come apart specifically where two adjacent SKUs get folded into one round number. Both are the kind of error that only shows up once the files exist to check against, which is the whole reason this update exists.