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

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/glm-5-3
> date: 2026-08-14
> tags: llm, open-weights, agents, post-training, rl, security, explainer
Z.ai's [GLM-5.3 post](https://z.ai/blog/glm-5.3) 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](https://github.com/THUDM/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

<PostTrainDelta />

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

<BenchLedger />

"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.

<Figure
  src="/articles/glm-5-3/fig2.png"
  alt="Scatter plot of accuracy against average output tokens per task on Z.ai Code Bench, with four models each plotted at several effort levels. GLM-5.3 rises steeply from about 24.7 percent at 48K tokens to 34.5 percent at 75K. GLM-5.2 sits lower and further right. Claude Fable 5 is highest overall, reaching 39.5 percent at about 115K tokens. Claude Opus 4.8 reaches 29.5 percent at about 120K tokens."
  caption="Accuracy against output tokens on Z.ai Code Bench v1.0, run inside Claude Code 2.1.207. Up and to the left is better. (z.ai, GLM-5.3 launch post.)"
/>

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](/articles/harness-effect), 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.

<CyberChain />

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.
