GLM-5.3 Complete Guide: Benchmarks, API, Coding, and Open Weights

Z.ai's official launch header states the release thesis, coding focus, cyber capability, and planned weights release. Source: GLM-5.3 launch post.

GLM-5.3 is Z.ai's August 14, 2026 update to the GLM-5 family, aimed squarely at coding agents, tool use, automation, and defensive security work. The important change is not a new base-model architecture. Z.ai says GLM-5.3 keeps the GLM-5.2 base and scales post-training with longer, richer agent environments, harder tasks, more complete trajectories, and stronger verification. That distinction matters: this is a release about making a large model behave better inside real workflows, not merely making it answer isolated prompts better.

Launch-day results support that story. In Z.ai's published table, GLM-5.3 rises sharply over GLM-5.2 on Terminal-Bench 3.0, DeepSWE 1.1, Toolathlon Verified, AutomationBench, CyberGym, and HLE with Tools. It does not win every row, and the table combines results from different benchmark owners and evaluation setups. Treat it as a useful launch snapshot, not a single independent controlled experiment.

The API model ID is glm-5.3. Thinking is required, with reasoning_effort values of low, high, or max; Z.ai documents max as the default. GLM Coding Plan and ZCode access are part of the launch. Z.ai also says open weights are planned roughly two weeks after release, following safety evaluation and hardening. They were not available on launch day.

One detail is still unresolved: the official Z.ai pricing page was live when this guide was checked, but it did not contain a GLM-5.3 per-token price row. Do not copy GLM-5.2 pricing into a GLM-5.3 cost calculator or assume the two are identical.

Key takeaways

• GLM-5.3 launched on August 14, 2026 as a post-training upgrade built on the GLM-5.2 base.
• The official API model ID is glm-5.3. Thinking cannot be disabled; supported reasoning effort levels are low, high, and max.
• Z.ai's launch table shows large gains over GLM-5.2 in terminal work, software engineering, tool use, automation, and cybersecurity tasks.
• The results are vendor-published or vendor-cited. They are not one independent run under a single harness, budget, and context setting.
• Z.ai reports better token efficiency on a private coding benchmark, but private-test methodology limits external reproduction.
• GLM-5.3 is available through GLM Coding Plan and ZCode, with documented Claude Code and OpenCode paths.
• The official pricing page did not list standalone GLM-5.3 token rates at the time of verification.
• GLM Coding Plan includes GLM-5.3 on every tier and starts at $18 per month, but its credits are not standalone API token prices.
• Z.ai plans to release weights about two weeks after launch, after safety work. "Open weights" should therefore be written in the future tense until the files are actually published.
• A separate QbitAI launch-day ZCode test reported a full-stack delivery, a 12-class vulnerability audit and repair, and explicit UNVERIFIED labels for GPU-only checks. These remain attributed media tests rather than standardized benchmark results.

GLM-5.3 at a glance

Item	Launch-day status
Release date	August 14, 2026
Developer	Z.ai
API model ID	glm-5.3
Main technical change	Scaled post-training on the GLM-5.2 base with longer and richer agent environments
Reasoning mode	Thinking required
Reasoning effort	low, high, max (documented default: max)
Main workloads	Coding, terminal agents, tool use, automation, research, and cyber defense
Access	GLM Coding Plan, ZCode, and documented coding-agent integrations
API pricing	No GLM-5.3 row verified on the official pricing page at publication cutoff
Open weights	Announced for about two weeks after launch, subject to safety evaluation and hardening
Parameter count	Inherited GLM-5.2 base is described as about 744B total parameters and 40B active; this is not a new GLM-5.3 architecture claim
Context	The inherited GLM-5.2 documentation advertises up to 1M context, while benchmark footnotes use task-specific 300K, 400K, and 1M settings

The parameter and context rows need careful wording. Z.ai presents GLM-5.3 as using the same base as GLM-5.2. That lets us describe the inherited base specification, but it does not justify inventing a new GLM-5.3 architecture sheet. Likewise, a model family supporting up to one million tokens does not mean every evaluation used one million tokens, every endpoint accepts the same configuration, or every task benefits from filling the window.

For broader model-comparison context, see GPT-5.6 vs Fable 5 vs GLM-5.2 and Kimi K3 vs Claude Fable 5 vs GPT-5.6 Sol.

What changed from GLM-5.2?

Z.ai attributes the update to longer-horizon reinforcement learning, rollout consistency, scheduling, and throughput improvements. Source: GLM-5.3 launch post.

Z.ai's release framing is unusually useful because it identifies the layer that changed: post-training. GLM-5.3 retains the GLM-5.2 base, then exposes it to longer trajectories and more realistic agent environments. In practical terms, the training problem moves away from "produce the right next answer" and toward "keep a complex job on track while the environment changes."

A long-running coding agent has to do more than emit a long response. It must inspect a repository, locate conventions, form a plan, call tools, interpret results, edit several files, run tests, diagnose failures, and decide whether the acceptance criteria are satisfied. Each step changes the state that the next step depends on. Small mistakes compound: a wrong assumption made during repository mapping can poison implementation and testing several minutes later.

The GLM-5.3 training recipe described by Z.ai targets this compounding problem with richer environments, longer trajectories, and verifiers. That can improve several behaviors at once:

1. keeping the original request active across many tool calls;
2. choosing a useful next action instead of repeatedly exploring;
3. recovering when a command or test fails;
4. checking the artifact rather than stopping after code generation;
5. spending fewer tokens on dead ends.

This also explains why the largest gains appear in agent-shaped evaluations rather than uniformly across every benchmark. Terminal-Bench 3.0 jumps from 4.6 for GLM-5.2 to 28.3 for GLM-5.3 in Z.ai's table. AutomationBench 1.0.6 rises from 26.2 to 48.2. DeepSWE 1.1 moves from 46.2 to 66.9. Those are much larger changes than a typical point release produces on static question answering.

The right interpretation is narrower than "GLM-5.3 is smarter at everything." The evidence says Z.ai improved how the inherited base operates in tool-rich, extended tasks. Teams should test that claim against their own repository, permissions, tool schemas, and retry policy.

Coding and agent benchmarks

These broad benchmark comparisons are Z.ai-published results, not an independent Atoms evaluation. Source: GLM-5.3 launch post.

The following table reproduces selected results published or cited by Z.ai at launch. n/a means no figure appeared in the supplied launch table.

Benchmark	GLM-5.3	GLM-5.2	Kimi K3	DeepSeek V4 Pro 0813	Fable 5	GPT-5.6 Sol
Terminal-Bench 3.0	28.3	4.6	17.4	n/a	33.7	34.6
DeepSWE 1.1	66.9	46.2	67.5	62.7	69.7	72.7
NL2Repo	58.0	48.9	58.0	61.1	n/a	n/a
CyberGym	84.5	77.2	80.0	83.3	83.8	83.6
Toolathlon Verified	73.0	59.9	76.5	74.1	74.7	74.9
AutomationBench 1.0.6	48.2	26.2	46.7	43.2	46.2	45.8
Agents' Last Exam	28.5	23.8	27.6	25.7	23.8	28.6
HLE with Tools	62.5	54.7	59.8	60.0	63.9	64.5
GDPval-AA v2	1769	1508	1682	1590	1743	1730

Source: Z.ai's GLM-5.3 launch post. These are vendor-published or vendor-cited figures, not Atoms test results.

What the table supports

The cleanest comparison is GLM-5.3 against GLM-5.2 inside the same launch table. GLM-5.3 improves by 23.7 points on Terminal-Bench 3.0, 20.7 on DeepSWE 1.1, 22.0 on AutomationBench, 13.1 on Toolathlon Verified, and 7.3 on CyberGym. It also adds 261 points on GDPval-AA v2.

That pattern is consistent with the post-training thesis. The model appears much more capable of executing workflows that involve a terminal, tools, or a changing environment. It also closes much of the distance to the strongest proprietary models in several rows.

What the table does not support

It does not establish a universal ranking. Benchmark owners use different task sets, time budgets, context limits, scoring rules, and harnesses. Some competitor numbers may come from their developers, public leaderboards, or evaluator runs rather than one laboratory rerunning every model under identical conditions. Z.ai's footnotes also use different context configurations, including 300K, 400K, and 1M, depending on the test.

A one-point difference should not be treated as decisive without sample size, variance, and run-level records. GLM-5.3's 66.9 on DeepSWE is close to Kimi K3's 67.5, but those figures alone do not tell you whether one model will do better in a monorepo with custom build tools. Its 73.0 on Toolathlon is below several peers, while its 48.2 leads the listed systems on AutomationBench. Workload choice plainly changes the order.

Independent launch-day evidence was also limited. Until third parties publish prompts, harness versions, model settings, trajectories, and raw outputs, these results are best used to choose candidates for testing, not to skip testing.

GLM-5.3 vs Kimi K3 and DeepSeek V4 Pro

Against Kimi K3, GLM-5.3 leads in the displayed table on Terminal-Bench, CyberGym, AutomationBench, Agents' Last Exam, HLE with Tools, and GDPval-AA v2. Kimi K3 leads on DeepSWE and Toolathlon, while NL2Repo is tied at 58.0. That is not a clean sweep in either direction. It suggests GLM-5.3 may be especially competitive in automation and security-shaped workflows, while Kimi remains strong in software engineering and broad tool use.

Against DeepSeek V4 Pro 0813, GLM-5.3 leads on DeepSWE, CyberGym, AutomationBench, Agents' Last Exam, HLE with Tools, and GDPval-AA v2. DeepSeek leads on NL2Repo and Toolathlon. Terminal-Bench lacks a DeepSeek figure in this table, so no comparison should be manufactured.

The harness can matter as much as the model. Prompt format, tool descriptions, patch strategy, context compaction, command timeout, and test feedback all affect the result. A model that performs well with one evaluator's agent may lose its advantage inside a different coding stack. For a broader discussion of how recent systems trade places across evaluations, read GPT-5.6 Sol vs Fable 5 vs GLM-5.2 and Kimi K3 vs Claude, Fable 5, and GPT-5.6 Sol.

Token efficiency may be the bigger upgrade

The vendor chart connects coding performance with effort level and output-token budget. Source: GLM-5.3 launch post.

Z.ai also published results from a private coding benchmark that combine score and output-token use:

Model and effort	Score	Approx. output tokens
GLM-5.3 Max	34.5%	75K
GLM-5.3 High	31.4%	50K
GLM-5.2 Max	23.4%	96K
Claude Opus 4.8	29.5%	120K
Fable 5 Max	39.5%	Not specified in the supplied comparison

The interesting comparison is GLM-5.3 Max versus GLM-5.2 Max: a higher reported score with roughly 21,000 fewer output tokens. High effort also preserves much of the Max score while using about one third fewer output tokens than GLM-5.3 Max.

If that behavior carries into production, it could affect latency, quota consumption, and cost per completed task more than a small benchmark lead. Agent economics depend on successful completion, not the price of a single token. A verbose cheap model can cost more than a concise expensive one after repeated attempts.

But the caveat belongs next to the claim: this is Z.ai's private code benchmark. External readers cannot reproduce it from the published percentages alone. We need the task set, harness, token accounting, stopping policy, model versions, and repeated-run variance. Teams should measure total input, cached input, reasoning/output tokens, wall time, retries, and objective success on their own tasks.

A useful metric is:

cost per successful task = total cost of all attempts / number of objectively successful tasks

Preserve failed attempts in that calculation. Otherwise a model that retries often can look artificially cheap.

Cybersecurity capability and safety

The capability evidence explains the containment concern; measured capability is not permission for unauthorized use. Source: GLM-5.3 launch post.

GLM-5.3's cyber results deserve attention and restraint. Z.ai reports 84.5% on CyberGym and 54.4% on ExploitBench. On ExploitGym, it reports 105 completed tasks under a normalized two-hour budget and 130 under six hours. These numbers suggest stronger vulnerability analysis and exploitation capability, which can support defensive research but also increases dual-use risk.

Z.ai says its workflow found 2,436 vulnerabilities across 269 projects after expert review and deduplication. Of those, 1,097 were rated medium to high severity, and the oldest affected code reportedly dates to 1981. The company links disclosure activity through Z.ai's vulnerability disclosure portal.

These are vendor reports, not an invitation to point an autonomous agent at arbitrary infrastructure. Safe use requires explicit authorization, scoped targets, rate and command limits, audit logs, secret isolation, and human review before disclosure or deployment. Never run exploit-generation workflows against systems you do not own or lack written permission to test.

For defensive teams, a sensible operating model is:

• use isolated replicas, containers, or purpose-built cyber ranges;
• block access to unrelated networks and production credentials;
• require approval before destructive commands or proof-of-concept execution;
• retain prompts, tool calls, patches, and findings for audit;
• verify severity and affected versions manually;
• coordinate disclosure with maintainers and follow embargo terms;
• treat generated exploit code as sensitive material.

The open-weight delay is relevant here. Z.ai says it will spend roughly two weeks on safety evaluation and hardening before releasing weights. That does not eliminate misuse, but it shows the release plan recognizes that stronger cyber agents require more than a standard model-card disclaimer.

API changes

The launch model ID is glm-5.3. The minimum request shape documented for the new reasoning behavior is:

{
  "model": "glm-5.3",
  "thinking": {"type": "enabled"},
  "reasoning_effort": "max"
}

GLM-5.3 requires thinking. Applications that previously sent "thinking": {"type": "disabled"} need to migrate instead of assuming the server will silently preserve old behavior. Z.ai documents three effort levels:

Setting	Intended trade-off
low	Lower reasoning spend for simpler or latency-sensitive tasks
high	A middle setting for substantial coding and tool work
max	Highest reasoning effort; documented default

Keep the request schema separate from product-specific controls. SDKs, OpenAI-compatible endpoints, Claude Code adapters, and ZCode may expose additional fields or defaults. Verify the exact endpoint and SDK version before shipping. Also log the effective model ID and effort level with each evaluation; otherwise later comparisons will be impossible to interpret.

Thinking content can create operational concerns. Do not store sensitive reasoning traces by default, and do not assume reasoning text is a reliable audit explanation. The real audit trail is the sequence of user inputs, tool calls, environment responses, file changes, tests, and approvals.

Availability, pricing, and open-weight timeline

The launch page distinguishes immediate access through ZCode, Claude Code, OpenCode, and Coding Plan from weights promised later. Source: GLM-5.3 launch post.

Z.ai lists GLM-5.3 for GLM Coding Plan and ZCode, and its launch material documents use with Claude Code and OpenCode. The GLM Coding Plan overview estimates weekly allowances under an assumed 90.9% cache-hit rate, but those plan allowances are not equivalent to a standalone API price per million tokens. They depend on plan tier, usage conditions, caching, and the provider's allowance calculation.

GLM Coding Plan pricing and quotas

GLM-5.3 is included in every GLM Coding Plan tier, and Z.ai says subscriptions start at $18 per month. The official plan page lists the following limits:

Plan	5-hour credits	Weekly credits	Estimated weekly tokens*
Lite	2,000	10,000	43–87 million
Pro	12,000	60,000	263–526 million
Max	28,000	140,000	613–1,226 million

*Z.ai's estimates assume all usage is on GLM-5.3 with a 90.9% cache-hit rate. The range reflects standard versus 50%-discounted off-peak credit charging. GLM-5.3 uses plan multipliers of 6.9 for input tokens, 1.7 for cached input, and 24 for output. These are subscription credits, not dollar prices per million API tokens.

At the research cutoff, the official API pricing page returned successfully but did not expose a GLM-5.3 row that we could verify. A dedicated GLM-5.3 documentation route also returned 404. Therefore:

• do not quote a GLM-5.3 input or output token price without a current official row;
• do not substitute GLM-5.2 prices;
• do not convert Coding Plan allowances into a fake per-token rate;
• recheck the pricing page before procurement or publication updates.

Pricing status is "not yet documented in the verified table," not "free" and not "the same as GLM-5.2."

Open weights were announced, not delivered, on August 14. Z.ai's stated target is about two weeks after launch, following safety evaluation and hardening. Once released, teams should verify the license, file hashes, tokenizer, inference configuration, quantization support, hardware requirements, and whether the downloadable checkpoint matches the hosted API behavior. Hosted post-training systems can include serving-time components that are not captured by a weight file alone.

What QbitAI's hands-on ZCode tests add

A separate QbitAI launch-day report tested GLM-5.3 in ZCode on end-to-end software delivery and security work. These were outlet-run demonstrations, not Atoms tests or standardized benchmarks. They add a useful view of how the model handled verification, evidence boundaries, and multi-layer application work.

Scenario	QbitAI-reported result	What the result supports
Full-stack simulation game	About 40 minutes to produce an application with frontend, backend, database persistence, account isolation, automated tests, Docker build, and an acceptance report	The workflow attempted an end-to-end delivery loop instead of stopping at a visual demo
AegisDesk security audit and repair	The audit reportedly found all 12 seeded vulnerability classes in about seven minutes. A follow-up repair changed 22 files, added 1,463 lines, and passed 54 of 54 regression tests both inside ZCode and in a separate rerun	The model connected code review, remediation, and regression testing, although one CSRF finding was initially labeled too confidently
CUDA task on a Mac without an NVIDIA GPU	In 18 minutes 52 seconds, the workflow used CPU simulations for algorithm checks and a Docker CUDA Toolkit environment to run nvcc; real GPU execution, CPU/GPU numerical parity, and performance remained UNVERIFIED	The strongest signal was evidence discipline: the report separated checks it could run from conclusions the environment could not support

The full-stack result is more informative than the accompanying 3D demos because persistence, permissions, backend behavior, tests, and build status create objective acceptance points. The security sequence is also useful because it covers three stages: identify a vulnerability, repair the responsible data or authorization path, and rerun tests to check that the fix did not break expected behavior.

The CUDA case deserves equal weight. A coding agent with broad system access should distinguish VERIFIED, INFERRED, and UNVERIFIED conclusions instead of turning missing hardware into a confident success claim. That behavior is part of production engineering quality, especially when a task involves security, deployment, or hardware-specific code.

The caveat is the same as for other launch-day demonstrations: QbitAI reported one trajectory per scenario, and the supplied account does not provide repeated-run variance, complete token accounting, or a public reproduction package. Use these cases to design evaluation tasks, not as a substitute for testing GLM-5.3 in your own environment.

A 7,400-file DeepSeek Harness case study

A pre-release Zhidx report offers a more concrete, if less controlled, picture. The article says GLM-5.3 used parallel explorers to map the newly published DeepSeek Harness repository, then built a reversible persona plugin that switches among Classical Chinese, Northeastern Chinese, and cat-speak. The public plugin repository corroborates the plugin modes, system-prompt injection design, /yayan switching command, reversible unload behavior, and README claim that 11 unit tests passed.

This was a Zhidx case study, not an Atoms experiment and not a formal benchmark. We also could not reproduce the test locally at the research cutoff because pnpm install failed when the required @deepseek-ai/dsh-environment package returned 404. The claims about millions of exploration tokens, broad test runs, and clean-baseline failure diagnosis remain attributed to Zhidx and the plugin README.

Read the full case analysis: How GLM-5.3 Read 7,400 DeepSeek Harness Files and Built a Working Plugin.

How teams should evaluate GLM-5.3

Start with tasks that resemble your actual work. A compact evaluation can cover one cross-file bug repair, one feature with acceptance tests, and one repository-level planning task. Freeze the repository commit and give every model the same tools, permissions, time budget, context policy, and retry limit.

Record more than pass rate:

Dimension	What to capture
Correctness	Regression tests, acceptance tests, and manual review
Efficiency	Input, cached input, output, and reasoning tokens
Tool behavior	Wrong, duplicate, malformed, and unnecessary calls
Recovery	Whether the agent diagnoses failures and changes strategy
Repository fit	Adherence to local architecture and conventions
Operations	Median and p95 latency, timeouts, and rate-limit failures
Safety	Secret access, command scope, network use, and approval compliance
Maintainability	Patch size, readability, tests, docs, and rollback quality

Repeat tasks. One successful run is a demo; several runs under fixed conditions begin to support a reliability claim. Compare cost per successful task rather than cost per attempt. Inspect the final artifact, not just the transcript.

For product work, Atoms AI agents coordinate specialized roles across planning, engineering, design, SEO, analytics, and deployment. Atoms Engineer Agent shows how that workflow applies to coding tasks, while coding-agent use cases show where it fits.

FAQ

When was GLM-5.3 released?

Z.ai launched GLM-5.3 on August 14, 2026.

Is GLM-5.3 a new base model?

Z.ai says it uses the same base as GLM-5.2. The main change is scaled post-training with longer, richer agent environments and stronger verification.

What is the GLM-5.3 API model name?

Use glm-5.3.

Can thinking be disabled?

No. The launch documentation says thinking is mandatory. Supported reasoning_effort values are low, high, and max, with max documented as the default.

How large is GLM-5.3?

Because Z.ai describes it as sharing the GLM-5.2 base, the inherited specification is approximately 744 billion total parameters with about 40 billion active. This should not be presented as a newly disclosed GLM-5.3 architecture.

Does GLM-5.3 support a one-million-token context window?

The inherited GLM-5.2 documentation advertises up to 1M context. Benchmark configurations vary, with launch footnotes using 300K, 400K, or 1M depending on the evaluation. Verify the current endpoint limits before designing around the maximum.

How much does the GLM-5.3 API cost?

No standalone GLM-5.3 per-token row was verified on Z.ai's official pricing page at the research cutoff. Coding Plan allowances are documented, but they should not be presented as API token prices.

How much does GLM Coding Plan cost for GLM-5.3?

Z.ai says GLM Coding Plan starts at $18 per month and includes GLM-5.3 across Lite, Pro, and Max tiers. The plan uses five-hour and weekly credit limits; those credits should not be converted into standalone API prices.

Are the GLM-5.3 weights available?

They were not available on launch day. Z.ai said it planned to release them about two weeks later after safety evaluation and hardening. Check the official repository before stating that the weights are live.

Is GLM-5.3 the best coding model?

No launch table proves that. It leads selected models on some automation and cyber evaluations, trails on other coding and tool-use tests, and lacks broad independent reproduction. Test it with your own harness and repository.

Did Atoms run the DeepSeek Harness plugin test?

No. Zhidx reported the pre-release test, and the public plugin README corroborates parts of the implementation. Atoms did not execute the original experiment.

Build with evidence, not leaderboard instinct

Benchmarks describe tendencies. Finished products reveal fit. Start a project with the Atoms AI agent team and evaluate the complete result, from planning and architecture through code, testing, SEO, analytics, and deployment.

Sources

• QbitAI launch-day hands-on report on GLM-5.3 in ZCode (August 14, 2026; supplied for editorial review)

• Z.ai: GLM-5.3 launch announcement

• Z.ai Developer Documentation: GLM Coding Plan overview

• Z.ai Developer Documentation: pricing

• ZCode

• Z.ai vulnerability disclosure portal

• DeepSeek Harness repository

• Persona plugin for DeepSeek Harness

• Zhidx-attributed case-study mirror: GLM-5.3 and DeepSeek Harness