GLM-5.3 API Is Now Live on Qubrid AI: Benchmarks, Architecture, Pricing, and How to Call It

If you want the short version: GLM-5.3 is the strongest agentic coding model Z.ai has shipped, its gains came entirely from post-training rather than a new base model, it now ties the top open-weights position on the Artificial Analysis Intelligence Index, and it is measurably more verbose per task than its predecessor - which is why the caching line on your invoice matters more than the headline rate.

Everything below is sourced and linked. Where a number is vendor-reported, we say so. Where independent evaluators disagree with the vendor, we show both.

Quick facts: GLM-5.3 at a glance

What is GLM-5.3?

GLM-5.3 is Z.ai's flagship model for complex software engineering and long-horizon agent work. Per Z.ai's official documentation, it uses the same base model as GLM-5.2 with all improvements driven by post-training, delivering what Z.ai describes as a 50% performance gain over GLM-5.2 on Z.ai Code Bench and state-of-the-art performance among open-source models on public benchmarks including Terminal Bench 3.0 and Agents' Last Exam (CLI).

The unusual part of this release is what did not change. As MarkTechPost reported, Z.ai released GLM-5.3 on August 14, 2026, reusing the GLM-5.2 base model with every gain coming from scaled post-training: more task environments, more environment types, longer training. No new pre-training run. No parameter-count bump. No architecture rewrite.

A note on parameter counts, because published figures vary by a few billion. explainx.ai's launch coverage quotes Z.ai's announcement describing "top-tier coding and agentic capabilities, achieved through post-training on the 743B base model," while Artificial Analysis records GLM-5.3 as keeping GLM-5.2's size at 753B total parameters with 40B active. Both describe the same thing: a very large sparse MoE with roughly 40B parameters active per forward pass. Treat the exact total as approximate until the weights land and the config file settles it.

The feature change that will break your existing code

Most integration guides bury this. From Z.ai's docs: GLM-5.3 supports text-only inputs with a 1M-token context window and a maximum output length of 128K tokens. It always operates with reasoning enabled and supports three reasoning effort levels - low, high, and max, defaulting to max. Disabling reasoning is no longer supported.

Z.ai's own migration note is blunt: if your application currently uses thinking.type: "disabled", change it to enabled and set reasoning_effort to low before updating the model ID, otherwise the request will fail.

The 1M context is real and usable for repository-scale work. The New Stack notes that with a 1-million-token context window and a 128,000-token completion ceiling, GLM-5.3 accommodates massive codebases.

Where the gains actually came from

The engineering story here is environment scaling, not model scaling.

Z.ai's framing is that the bottleneck in agentic post-training has moved off the model and onto the training environment. From their documentation: as agent capability improves, much of the difficulty in scaling post-training moves from the model to the environment, because a useful task environment has to be executable, verifiable, and close to real professional work - and you need many of them, not a handful of hand-built ones.

Their answer was to synthesise environments end to end. 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 verify it is actually solvable. Verifiers are synthesised without access to the reference solution, while solver trajectories are used to discover and close reward shortcuts. A verifier that passes oracle, no-op, and unsolved-state checks produces a binary reward reliable enough to train on directly.

They also carried forward the RL machinery from the previous release: GLM-5.3 keeps the RL strategies introduced in GLM-5.2, including SAO with compaction, which helps the gains hold on long-horizon tasks rather than only on short ones.

The tasks themselves are deliberately unlike benchmark puzzles. Z.ai's own example: in an ML infrastructure task, the model may be given the same working environment as an engineer, with access to compute clusters, storage systems, internal documentation, codebases, and experiment results. It must diagnose bottlenecks across the training stack, implement optimizations, run experiments, and deliver a measurable end-to-end speedup while preserving correctness. The New Stack reported that according to Z.ai, single tasks matched the workload of a senior engineer over several days, and called the release a compelling case study for post-training compute scaling because Z.ai concentrated compute on the specific environments the model actually works in.

GLM-5.3 benchmarks: the full table

Everything in this section is vendor-reported by Z.ai unless explicitly marked otherwise. That caveat is not boilerplate - read the independent-verification section below before making a procurement decision on these numbers.

Coding and agentic benchmarks

The core deltas are confirmed across independent write-ups. Per MarkTechPost: Terminal-Bench 3.0 moves from 4.6 to 28.3, DeepSWE v1.1 from 46.2 to 66.9, Agents' Last Exam (CLI) from 23.8 to 28.5, and on GDPval-AA v2, which spans 44 occupations, GLM-5.3 scores 1,769.

Note the shape of the curve, because it is the single most useful thing to know when deciding where to point this model: the longer the task horizon, the bigger the gain. That is exactly what the environment-scaling story predicts.

The New Stack also flags the harness caveat you should apply to every cross-model comparison: that 66.9 on DeepSWE lands right alongside Google's Gemini 3.7 Flash at 65%, though variations in testing harnesses mean head-to-head comparisons should be taken with a grain of salt.

Z.ai Code Bench and the token-efficiency claim

Z.ai introduced a private benchmark for this release. Their stated reasoning: as a private benchmark, Z.ai Code Bench reduces the risk of contamination from public test sets and gives a more faithful measure of real-world user experience.

The results, in Z.ai's own words: at Max effort, GLM-5.3 reaches 34.5% at roughly 75K output tokens per task, compared with 23.4% at 96K for GLM-5.2. At High effort, GLM-5.3 reaches 31.4% at around 50K output tokens, surpassing Claude Opus 4.8 at 29.5% with 120K. GLM-5.3 remains behind Claude Fable 5, which reaches 39.5% at Max effort.

Kingy AI's analysis put precise arithmetic on it: at High effort GLM-5.3 scores 31.4% versus GLM-5.2's 20.9%, an absolute gain of 10.5 percentage points. At Max effort, 34.5% versus 23.4% is an 11.1-point gain or 47.4% relative, with average output falling from roughly 96,000 to 75,000 tokens per task at Max, a reduction of about 21.9%.

The same analysis is properly sceptical about what a private benchmark can prove: it remains a private, vendor-designed benchmark evaluated in Claude Code 2.1.207, and Z.ai has not released the tasks, graders, or run artifacts.

Independent verification: what Artificial Analysis found

This is the number that carries the most weight, because the evaluator ran the suite itself rather than reprinting a vendor table.

Artificial Analysis scored GLM-5.3 at 60 on its Intelligence Index. As OfficeChai summarised, that ties Kimi K3 for the top spot among open-weights models and sits three points behind Claude Opus 5's 63, seven points up from GLM-5.2.

What the composite covers, per Unite.AI: Intelligence Index v4.1.1 aggregates nine evaluations spanning agentic real-world work tasks, agentic tool use, terminal coding, scientific reasoning and knowledge, graduate-level science questions, physics reasoning, knowledge reliability and hallucination, and long-context reasoning. GLM-5.3's 60 is the composite of its run across that battery, at a total evaluation cost of $1,238.50.

The agentic result is the standout. Per OfficeChai's reporting of the same run: on GDPval-AA v2, Artificial Analysis's real-world agentic knowledge work evaluation, GLM-5.3's Elo climbs from 1524 to 1770 - a 246-point jump in one release - putting it second on that test behind only Claude Opus 5 at 1855, ahead of every other model on the board, and clearing the previous open-weights leader Kimi K3 (1668) by more than 100 points.

Artificial Analysis's own summary, posted on X, framed the significance plainly: between Kimi K3 and GLM-5.3, the open weights frontier is closer than ever to the proprietary frontier.

The token-efficiency contradiction you need to plan around

Here is the finding most launch coverage skipped, and the one that will actually shape your bill.

Z.ai reports fewer output tokens per task on their private Code Bench. Artificial Analysis measured more output tokens per task on their index. Both can be true - different task distributions, different harnesses - but you should budget against the independent number.

From Artificial Analysis: across Intelligence Index v4.1, GLM-5.3 uses roughly 18,700 output tokens per task, up about 20% from GLM-5.2 (15,700) and 27% more than Kimi K3 (14,700), which has implications for cost of deployment. On cost: at $0.68 per Intelligence Index task, GLM-5.3 costs 1.5x GLM-5.2's $0.44.

Their model page is blunter still: when evaluated on the Intelligence Index, GLM-5.3 (max) generated 170M output tokens, at the higher end compared to other reasoning models in a similar price tier, where the median is 72M.

Practical implication: GLM-5.3 at max effort is a high-verbosity reasoning model. In a production agent loop, your cost driver is output tokens, not input tokens. Two levers matter: drop to high or low effort where the task allows, and lean hard on implicit caching for repeated context. We do the arithmetic on both below.

The cybersecurity results, and what they do and do not mean

Z.ai flagged this capability as unplanned. From their documentation: as part of post-training they introduced vulnerability discovery data and environments into the training mix, expecting the model to get better at finding and reasoning about vulnerabilities. What surprised them was how quickly the capability continued to develop as training scaled - GLM-5.3 began to reason across multiple stages of exploitation, forming coherent plans for complete exploitation chains.

The three-benchmark picture, all vendor-reported:

Per Z.ai: on CyberGym, which starts from white-box source code and tests whether the model can identify and validate vulnerabilities by triggering faults, GLM-5.3 scores 84.5%, up from 77.2% - the best result on the benchmark, ahead of Mythos 5 and GPT-5.6 Sol. On ExploitBench, which requires deeper reasoning about real vulnerabilities and their exploitation, GLM-5.3 reaches 54.4%, more than doubling GLM-5.2's 24.4%. On ExploitGym, which measures how many exploitation tasks a model completes under time-normalized budgets, GLM-5.3 completes 105 tasks within two hours and 130 within six, against 29 and 39 for GLM-5.2, with Mythos 5 well ahead at 181 and 247.

Z.ai's own read of the pattern is admirably candid: the further up the exploitation chain a benchmark sits, the larger the gain from GLM-5.2 - and also the wider the remaining gap to the closed frontier. Capability is growing fastest exactly where they are furthest behind.

Independent coverage drew the practical line. explainx.ai: if you are evaluating for security work specifically, the CyberGym lead is real and worth testing against your own defensive workloads, but do not read it as offensive capability - the ExploitBench and ExploitGym numbers say the opposite. Memeburn made the same point: GLM-5.3 leads CyberGym slightly, but trails Mythos 5 clearly on ExploitBench and ExploitGym, the benchmarks that test actual exploitation rather than detection.

And The New Stack's caution applies to anyone tempted by the white-box discovery score: reliably crafting an exploit, proving real-world reachability in production, or patching the flaw without triggering downstream regressions is an entirely different challenge altogether.

There is a real-world evidence trail here too. Per Z.ai: after expert review, screening, and deduplication, the model identified 2,436 vulnerabilities across 269 projects, including 1,097 medium-to-high severity issues, spanning system kernels, operating systems, browser engines, open-source infrastructure, web applications, and network protocols. Many had gone unnoticed for years, with the oldest dating back roughly 40 years. Z.ai built a Security Disclosure Ledger to maintain a public record of the findings as they move through coordinated disclosure, recording affected project, severity, CVE where available, and how long the vulnerability sat in the codebase.

Where this is genuinely useful on Qubrid today: defensive audit passes over your own repositories, triage of static-analysis findings, and reachability reasoning across large codebases where the 1M context earns its keep. It is not a substitute for a security team.

What developers are actually saying about GLM-5.3

We would rather link the criticism than pretend it does not exist. If you are evaluating GLM-5.3 for production, these are the objections to test against your own workload.

The distillation objection. The New Stack collected practitioner reaction in a piece on what developers really think. The sharpest came from Nishant Soni, co-founder of long-horizon autonomous software engineering company NonBioS.ai, who said he would take Z.ai's long-horizon scaling claims "with a pinch of salt," that to his knowledge no benchmarks objectively demonstrate the claimed superior long-horizon capability in real-world tasks, and that he suspects the release is "largely an effort to deflect from the model's true source of frontier capability - which shows a pattern consistent with industrial-scale distillation of Anthropic models." In internal testing at NonBioS, his team reported striking similarity between Kimi/GLM outputs and Claude's, while Gemini and Grok showed greater diversity.

The benchmaxxing question. ML researcher Nathan Lambert argued the effect is real but modest, and that the bigger factor is release timing. Per The New Stack's summary of his Interconnects post, Lambert thinks that if any benchmaxxing is going on, it is only to a subtle level, and wrote: "the Chinese labs use all the time that American labs do pre-release testing to keep hillclimbing on benchmarks."

The "meet the model halfway" take. Sherif Higazy, founder at AI benchmarking specialist Megaton, argued the environment thesis cuts both ways: getting consistently useful work from an agent requires meeting the model halfway, so teams adapt their working environments around how agents work - forcing repeated test runs, making inputs and outputs machine-readable and verifiable. His read on Z.ai's pitch: Z.ai is claiming developers can shift that burden upstream into model training, and if you train the agent inside a more diverse and realistic environment, it performs better on longer tasks without as much supervision.

The portability argument. Rohan Kodialam, co-founder and CEO at Sphinx, made the point we would make ourselves: once several models reach roughly comparable capability, choosing between them becomes much more about the workload than the leaderboard - cost, latency, privacy, deployment model, tool use, and performance on your specific tasks matter more than a few points on a benchmark. His conclusion: enterprises should avoid making their own model choices irreversible and build for portability as capabilities, economics, and infrastructure evolve.

The leaderboard discrepancy. One specific data-quality flag worth carrying forward, surfaced by Kingy AI: the independent DeepSWE leaderboard runs all models on mini-swe-agent for consistency, and at launch-day publication time it listed GLM-5.2 at 44% ±2, not the 46.2 in Z.ai's launch table. Harness choice moves these numbers by several points.

The vision gap. GLM-5.3 shipped text-only and that disappointed part of the community. Per explainx.ai, the June 29 community poll put vision at the top of the GLM-5.3 wishlist - screenshots, PDFs, UI designs, an Opus-class multimodal jump - and Z.ai's launch post makes no mention of vision. If your pipeline needs image input, this release does not change your options.

The open question on replication. Unite.AI put it well: whether independent evaluators replicate GLM-5.3's numbers, particularly the in-house Code Bench results and the cyber scores Z.ai ran in its own harness configurations, will determine how much of this launch is a genuine step for open-weights coding models and how much is evaluation choice.

Our position: the Artificial Analysis run has already replicated the direction of the gains independently, especially on agentic work. The private Code Bench numbers remain unverifiable by construction. Benchmark both against your own tasks before you migrate a production agent - which is the entire argument for having a per-token API and a model-agnostic endpoint rather than a subscription commitment.

Open weights status: still pending

GLM-5.3 shipped without its weights.

Per MarkTechPost, Z.ai says it will publish them roughly two weeks after launch, once safety evaluation and hardening finish. Independent trackers place the expected drop at approximately August 28, 2026. The licence is not confirmed: GLM-5.2's weights shipped under MIT, but Z.ai has not stated the GLM-5.3 terms.

One safety note worth repeating: until Z.ai's own zai-org organization publishes, any GLM-5.3 upload on Hugging Face from anyone else is not the model. Do not run it.

Why this matters right now: the API is the only production-grade path to GLM-5.3 today. And even after the weights land, self-hosting a ~750B-parameter MoE is a multi-node problem - weights alone run to roughly 1.5 TB at BF16, about half that at FP8, before KV cache. If you want the capability this week without standing up a serving cluster, the API is the answer.

GLM-5.3 pricing on Qubrid AI

No subscription. No seat licences. No credit system with variable multipliers and off-peak arithmetic. Pay per token, on the same key and the same billing account as every other model in the Qubrid catalog.

That last point is not incidental. Coverage of the subscription route flagged exactly this friction: usage is metered via credits, with baseline multipliers that differ per model and concurrency that varies by plan tier and resource availability. A subscription fits regular interactive work in a coding agent; a per-token API budget is cleaner when usage is irregular or you need a hard, forecastable spend ceiling.

Worked cost examples

Simple blended workload, 1M in + 1M out: $1.61 + $5.06 = $6.67

Production coding agent, 50M input + 5M output per month, no caching:

• Input: 50 × $1.61 = $80.50

• Output: 5 × $5.06 = $25.30

• Total: $105.80

Same workload with a 70% implicit cache hit rate on input:

• Cached input: 35M × $0.30 = $10.50

• Uncached input: 15M × $1.61 = $24.15

• Output: 5M × $5.06 = $25.30

• Total: $59.95, a 43% reduction

Implicit cache tokens are priced roughly 81% below uncached input. For agentic workloads - where the same system prompt, tool schemas, and repository context are resent on every turn of a long loop - that is the single largest lever on your bill. Structure your prompts so the stable prefix stays byte-identical across calls and let the cache do the work.

The second cost lever: reasoning effort

Given the verbosity finding above, effort level is a first-class cost control.

Z.ai's guidance: for complex tasks such as coding, use max. Kingy AI's counter-guidance from the same launch data: use max effort for difficult repository tasks, use low when latency and token use matter. And The New Stack's warning: max reasoning introduces noticeable latency and token overhead, so teams must evaluate whether the downstream accuracy justifies the added compute cost.

Our production recommendation: default to high, escalate to max only for tasks where you have measured a win, and drop to low for classification, routing, extraction, and short-turn interactive work.

How to call the GLM-5.3 API on Qubrid

GLM-5.3 is served behind an OpenAI-compatible endpoint. If your code already targets any OpenAI-style SDK, this is a two-line change.

Python (OpenAI SDK)

The model ID is case-sensitive and exact: zai-org/GLM-5.3.

Streaming with reasoning traces

For agent loops, stream. You want reasoning deltas separated from content deltas so your UI can render a thinking indicator without polluting the final answer.

Function calling

GLM-5.3 is an agentic model first, so tool use is the primary path. Per Z.ai's capability list, the model supports function calling, streaming, context caching, and structured JSON output.

cURL

Migration checklist from GLM-5.2

1. Change the model ID to zai-org/GLM-5.3.

2. Remove any code path that disables thinking. Reasoning is always on - use reasoning_effort: "low" instead.

3. Re-tune max_tokens. At max effort this model is verbose, and truncated reasoning produces worse answers than a lower effort level would have.

4. Re-baseline your evals. Do not assume a drop-in win on short-horizon tasks; the gains concentrate on long-horizon work.

5. Structure prompts for cache hits before you scale traffic.

Where GLM-5.3 fits, by workload

Long-horizon agentic coding. The strongest case. The Terminal-Bench 3.0 and DeepSWE deltas are the largest in the table and they are precisely the long-horizon rows. Tasks that span hours and hundreds of tool calls are where the environment-scaling work shows up.

Business-process and workflow automation. AutomationBench is GLM-5.3's clearest outright lead over every model in Z.ai's chart, closed models included.

Real-world agentic knowledge work. The GDPval-AA v2 result is the strongest independently measured signal in the release: second overall, behind only Claude Opus 5.

Very large context reasoning. 1M tokens with a 128K output ceiling covers whole-monorepo passes, long document sets, and multi-hour conversation histories without a retrieval layer.

Defensive security review. Discovery and validation, not exploitation. See the caveats above.

Where to look elsewhere. Anything multimodal, since GLM-5.3 is text-only. Anything latency-critical at max effort. Anything requiring open weights in production this week.

GLM-5.3 vs Kimi K3 vs Qwen3.8-Max

All three are live on Qubrid, so this is an A/B you can run on one key rather than a decision you have to get right up front.

Index scores and token counts from Artificial Analysis and the Hacker News thread comparing the full board.

Reading the table: GLM-5.3 is the cheapest of the three per token and leads decisively on agentic knowledge work. Kimi K3 matches it on the composite index while being about 27% more token-efficient, has open weights today, and handles vision. Qwen3.8-Max is the most verbose of the three, which matters more than its headline rate.

For a long-horizon coding agent, start with GLM-5.3. For anything that needs image input or already-downloadable weights, Kimi K3. Then measure both on your own tasks, because that is the only comparison that settles it.

Why run GLM-5.3 on Qubrid AI

One endpoint, 60+ models. GLM-5.3 sits alongside Kimi K3, Qwen3.8-Max, NVIDIA Nemotron 3.5 Lightning, and the rest of the catalog behind the same base URL and the same key. Switching models is a string change - which is exactly the portability posture practitioners are recommending.

OpenAI-compatible, so nothing to rewrite. Existing SDKs, existing agent frameworks, existing observability. Point base_url at https://platform.qubrid.com/v1 and go.

Implicit caching that materially changes agent economics. $0.30 per million cached tokens against $1.61 uncached is the difference between a viable production loop and a surprising invoice.

Per-token billing with a forecastable ceiling. No credit multipliers, no tier-dependent concurrency, no off-peak arithmetic.

Compute and inference on one platform. If your evaluation ends with "we want to fine-tune or self-host once the weights drop," Qubrid GPU compute and the inference API live under the same account.

Day-0 partner access. We were a GLM-5.3 launch partner. Our earlier full benchmark breakdown and architecture deep-dive went up at announcement. This is the shipping version.

Frequently asked questions

What is GLM-5.3? GLM-5.3 is Z.ai's flagship model for complex software engineering and long-horizon agent tasks, released August 14, 2026. It reuses the GLM-5.2 base model, with all reported gains coming from scaled post-training.

What is the GLM-5.3 API price on Qubrid AI? $1.61 per million input tokens, $5.06 per million output tokens, and $0.30 per million implicit-cache tokens. That is 20% off list pricing of $2.01 / $6.32 / $0.37.

What is the GLM-5.3 context window? 1M tokens, with a maximum output length of 128K tokens, per Z.ai's documentation.

Does GLM-5.3 support vision or image input? No. GLM-5.3 is text-only. Vision was the top community request ahead of launch and did not ship in this release.

Can I disable reasoning on GLM-5.3? No. Reasoning is always enabled. Use reasoning_effort: "low" for the closest equivalent to a fast, non-thinking response. Sending a disabled-thinking request will fail.

What are GLM-5.3's benchmark scores? Vendor-reported: Terminal-Bench 3.0 28.3, DeepSWE v1.1 66.9, Agents' Last Exam 28.5, AutomationBench 48.2%, HLE with tools 62.5%, GDPval-AA v2 1,769 Elo, CyberGym 84.5%, ExploitBench 54.4%, ExploitGym 105 tasks at 2h and 130 at 6h. Independently, Artificial Analysis scored it 60 on its Intelligence Index.

Is GLM-5.3 better than Kimi K3? It depends on the workload. Both score 60 on the Artificial Analysis Intelligence Index. GLM-5.3 leads decisively on GDPval-AA v2 agentic knowledge work (1,770 Elo versus 1,668). Kimi K3 is more token-efficient at roughly 14,700 output tokens per index task against GLM-5.3's 18,700, has open weights today, and supports vision. Both are live on Qubrid.

Are GLM-5.3's open weights available? Not yet. Z.ai committed to publishing them roughly two weeks after the August 14 launch, pointing to late August 2026, once safety evaluation and hardening complete. The licence has not been confirmed. Any GLM-5.3 weights on Hugging Face from an organization other than zai-org are not the model.

How do I call GLM-5.3 with the OpenAI SDK? Set base_url to https://platform.qubrid.com/v1, use your Qubrid API key, and set the model string to zai-org/GLM-5.3. Pass enable_thinking and reasoning_effort via extra_body.

Which reasoning effort level should I use? max for hard repository-scale engineering tasks, high as a production default, low when latency and token cost matter more than the last few points of accuracy.

Is GLM-5.3 good for cybersecurity work? For defensive work - vulnerability discovery, validation, code audit - the CyberGym result is the best reported on that benchmark. For exploitation, it trails the closed frontier substantially. Z.ai says so itself.

Get started

GLM-5.3 is live on Qubrid AI now. Create a key, change one line, and run it against your own evals - which, given everything above, is the only benchmark that actually settles the question.

Start building with GLM-5.3 on Qubrid AI