GLM-5.3 Found Bugs Hiding Since 1981: What Its Benchmarks Actually Mean

GLM-5.3 did more than raise a coding score. Its largest gains appeared after a bug was found: reproducing it, building exploit primitives, and finishing long technical jobs.

GLM-5.3 Found Bugs Hiding Since 1981: What Its Benchmarks Actually Mean

GLM-5.3 matters less because it raised another coding score and more because its largest gains appeared on long, multi-step work. Z.ai reports that the model reproduced known vulnerabilities, progressed further from a crash toward working exploits, and helped security teams identify 2,436 findings across 269 open-source projects. One reported flaw dated to 1981.

The central lesson is simple: GLM-5.3's benchmark gains suggest better persistence after the model finds the first clue, not proof that it can independently discover every unknown vulnerability.

Key takeaways

  • Z.ai says GLM-5.3 uses the same base model as GLM-5.2; the gains came from further post-training for harder, longer tasks.
  • Its reported score rose from 4.6 to 28.3 on Terminal-Bench 3.0 and from 46.2 to 66.9 on DeepSWE.
  • On security evaluations, Z.ai reports 84.5 on CyberGym, 54.4 on ExploitBench, and 105/130 completed ExploitGym tasks under two-hour/six-hour budgets.
  • The reported 2,436 real-world findings are not an OpenModels audit. Only 53 were public in Z.ai's release materials; 2,383 remained under embargo.
  • GLM-5.3 is available on OpenModels at a 10% discount: $1.121 input, $3.924 output, and $0.252 cached input per 1 million tokens on the selected route shown August 19, 2026.

What is GLM-5.3?

GLM-5.3 is Z.ai's long-horizon coding and agent model update, built on the same base model as GLM-5.2 but strengthened through additional post-training. The training emphasis is on tasks that require an agent to inspect an environment, use tools, make changes, run checks, recover from errors, and continue until the job is complete.

That distinction matters. A one-shot coding test asks whether a model can produce an answer. A long-horizon agent test asks whether it can survive the full loop:

inspect code → use tools → edit files → run tests → read failures → revise → finish

The benchmark pattern suggests GLM-5.3 improved most on the second kind of work.

GLM-5.3 benchmark results at a glance

Benchmark What it tests in plain English GLM-5.2 GLM-5.3 Reported change
Terminal-Bench 3.0 Completing difficult, multi-step jobs through a terminal 4.6 28.3 +23.7 points
DeepSWE Resolving long software-engineering tasks in real repositories 46.2 66.9 +20.7 points
CyberGym Reproducing a known vulnerability from a description and unpatched source 77.2 84.5 +7.3 points
ExploitBench Progressing from reaching a bug toward useful exploitation capabilities 24.4 54.4 +30.0 points
ExploitGym, 2h / 6h Turning a provided vulnerability trigger into unauthorized code execution 29 / 39 105 / 130 +76 / +91 tasks

All model scores in this table are reported by Z.ai. They should be read as vendor evaluations until equivalent independent runs are available.

Why the same-base-model detail matters

Z.ai says GLM-5.3 did not begin with a new base model. The company instead expanded post-training across more environments, harder tasks, and longer execution sequences.

This makes the release a useful case study in agent training. The result suggests that model progress does not only come from adding parameters or pre-training data. It can also come from teaching an existing model to stay oriented across a longer chain of actions.

The most interesting GLM-5.3 improvement is not knowing more at the first step. It is losing less capability between the first clue and the finished job.

How to read the cybersecurity benchmarks

These benchmarks measure different stages of a vulnerability workflow. Treating them as interchangeable produces the wrong conclusion.

What is CyberGym?

CyberGym is a vulnerability-reproduction benchmark containing 1,507 historical vulnerabilities from 188 open-source projects. The agent receives a vulnerability description and the corresponding unpatched repository, then generates a proof-of-concept input that triggers the flaw. The benchmark verifies that the input triggers the pre-patch version but not the patched version.

In plain English: the bug is known; can the agent find the path through the code and make it happen?

Z.ai reports GLM-5.3 at 84.5, up from 77.2 for GLM-5.2. The benchmark's scope and evaluation method are independently documented by the CyberGym research team.

What is ExploitBench?

ExploitBench measures exploitation as a capability ladder rather than calling every crash a successful exploit. It tracks 16 measurable capabilities across stages that include code coverage, crashes, sandbox primitives, arbitrary read/write, control-flow hijacking, and arbitrary code execution.

In plain English: after the agent reaches the bug, how much control can it build from it?

GLM-5.3's reported score rose from 24.4 to 54.4, a 30-point gain and more than double GLM-5.2's score. That is a stronger signal than the smaller CyberGym increase because reproducing a known flaw and turning it into useful control are different skills. The benchmark design is described in the ExploitBench paper.

What is ExploitGym?

ExploitGym is an exploit-generation benchmark with 869 real-world tasks across userspace software, Chrome's V8 JavaScript engine, and the Linux kernel. Each task gives the agent vulnerable source code, build information, a proof-of-vulnerability input that already triggers the bug, and a containerized target. The goal is to create an exploit that retrieves a protected flag through unauthorized code execution.

In plain English: the bug already crashes; can the agent turn that starting point into a working exploit?

Z.ai reports that GLM-5.2 completed 29 tasks within two hours and 39 within six hours. GLM-5.3 completed 105 and 130, respectively. The ExploitGym project independently documents the 869-task design and its dual-use risks.

The benchmark ladder in one table

Stage Starting information Required outcome What success does not prove
CyberGym Vulnerability description + unpatched code Reproduce the known bug with a proof of concept Independent zero-day discovery from a clean codebase
ExploitBench Known V8 bug and evaluation environment Climb from reachability toward exploitation primitives and code execution Broad performance across every software domain
ExploitGym Vulnerable code + an input that already triggers it Produce unauthorized code execution That real systems with all defenses enabled are equally exploitable

This ladder is the right way to interpret the release. CyberGym measures whether the model can reproduce a known vulnerability. ExploitBench measures how far it progresses after reaching vulnerable code. ExploitGym starts from a working trigger and asks whether the model can complete an exploit.

What did GLM-5.3 reportedly find in real code?

Z.ai says its work with security teams produced 2,436 vulnerability findings across 269 open-source projects after expert review, screening, and deduplication.

Severity Reported findings
Critical 107
High 990
Medium 1,286
Low 53
Total 2,436

That makes 1,097 critical or high-severity findings. Z.ai says the set spans kernels, operating systems, browser engines, infrastructure, web applications, and network protocols. The company also reports that the oldest flaw was introduced in 1981 and that vulnerabilities in the set existed for an average of 26.6 years before discovery.

Those figures are memorable, but they need a confidence label: they are Z.ai's reported findings, not an independently reproduced OpenModels study. Z.ai's release graphic said 53 findings were public and 2,383 remained under embargo. Most of the dataset therefore could not be independently inspected at publication time.

What GLM-5.3's results do and do not mean

The results support three practical conclusions:

  1. Long-horizon training appears to matter. Large gains on terminal work, repository tasks, and exploitation steps point toward better sustained execution.
  2. Benchmark choice must match the job. A model that reproduces known vulnerabilities is not automatically the best model for greenfield vulnerability discovery, patching, or general application development.
  3. Security capability is dual-use. Better exploit reasoning can help defenders reproduce bugs and validate mitigations, while also lowering the cost of offensive work.

The results do not prove that GLM-5.3 autonomously found 2,436 unknown zero-days from clean repositories. CyberGym supplies a vulnerability description. ExploitGym supplies an input that already triggers the bug. The real-world findings program used security-team review, and most results remained embargoed.

That limitation does not make the results unimportant. It makes them specific.

How much does GLM-5.3 cost on OpenModels?

OpenModels supports GLM-5.3 through its OpenAI-compatible API with a 10% discount on the selected route. The live route card captured on August 19, 2026 showed:

Price or signal OpenModels GLM-5.3 route
Input tokens $1.121 per 1M
Output tokens $3.924 per 1M
Cached input $0.252 per 1M
Displayed latency 0.04 seconds
Route state Selected
Discount 10%

These are route-level marketplace figures, not benchmark costs. OpenModels bills token-priced requests from actual input and output usage, and its pricing documentation recommends checking the live model page before production because price, supply, and route availability can change.

For a request using 100,000 input tokens and 10,000 output tokens, the displayed rates imply an estimated token charge of about $0.15134 before any workload-specific caching effects:

(100,000 / 1,000,000 × $1.121) + (10,000 / 1,000,000 × $3.924) = $0.15134

Use the OpenModels model catalog to confirm the current route, then call GLM-5.3 through the same OpenAI-compatible interface used for other supported models.

Final takeaway

Do not choose GLM-5.3 because it owns the largest number in a launch table. Choose it when your workload resembles the task behind the number.

If you need a model to work through terminals, large repositories, repeated tool calls, or long debugging chains, GLM-5.3's reported gains are relevant. If you need independent zero-day discovery, production exploit validation, or a security guarantee, these benchmarks are evidence to investigate, not proof of deployment readiness.

The release's strongest signal is persistence: GLM-5.3 appears better at continuing from “I found the problem” to “I finished the job.”

GLM-5.3 is available now on OpenModels with a 10% discount on the selected route shown above.

Frequently asked questions

Is GLM-5.3 available on OpenModels?

Yes. OpenModels supports GLM-5.3 through its OpenAI-compatible API. On August 19, 2026, the selected route showed $1.121 input, $3.924 output, and $0.252 cached input per 1 million tokens, with a 10% discount. Check the live catalog before sending production traffic because pricing and route availability can change.

Is GLM-5.3 a new base model?

According to Z.ai, no. GLM-5.3 uses the same base model as GLM-5.2. Its gains came from additional post-training across more environments, harder tasks, and long-horizon jobs requiring repeated tool use and verification.

Did GLM-5.3 discover 2,436 zero-day vulnerabilities?

No. Z.ai reported 2,436 vulnerability findings across 269 projects, but it did not classify the entire set as independently discovered zero-days. Only 53 findings were public in its release materials, while 2,383 remained under embargo. The total should be described as a vendor-reported finding count, not a verified zero-day count.

What does CyberGym measure?

CyberGym primarily measures targeted vulnerability reproduction. The agent receives a vulnerability description and an unpatched codebase, then must create a proof-of-concept input that triggers the historical flaw. It does not primarily test unknown-vulnerability discovery from a clean repository.

What is the difference between CyberGym and ExploitGym?

CyberGym asks an agent to reproduce a known vulnerability from a description and source code. ExploitGym starts later: it supplies vulnerable code and an input that already triggers the flaw, then asks the agent to turn that input into unauthorized code execution.

Is a higher benchmark score enough to choose GLM-5.3?

No. Choose the benchmark that resembles your workload, then run a private evaluation using your repositories, tools, time limits, and acceptance tests. Vendor benchmark scores are useful screening evidence, but task completion rate, retries, latency, and total cost on your own jobs determine production value.


Sources