GLM-5.3 API Pricing: What $1.4/$4.4 Means for Agents

By Lazar Milicevic · Published October 18, 2026 · 10 min read

Your agent bill is probably the line item that grew fastest this year, and a new model priced well below the frontier names looks like an easy win. GLM-5.3 from z.ai lists at $1.40 per million input tokens and $4.40 per million output tokens, but per-token price and per-task cost are different numbers, and the gap between them is where cost-sensitive teams get burned. Here is how to read the pricing, where the model fits, and how to test it on your own workload before you move anything.

The pricing, read carefully

GLM-5.3's list price on z.ai's developer docs pricing page is $1.4 per 1M input tokens, $0.26 per 1M cached input tokens, and $4.4 per 1M output tokens. Cached-input storage is currently listed as free for a limited time, so treat that as a promotion, not a permanent feature of your cost model.

z.ai also lists two cheaper tiers on the same page:

All figures are per 1M tokens. Third-party sites quote different Flash prices and launch promos; I'm using only the official docs numbers, and you should re-check the live page before you budget, since pricing pages change.

One more detail from VentureBeat's coverage: the price is unchanged from GLM-5.2. If you have been paying for 5.2, the upgrade is a pure quality change at the same list rate. Per a pricing tracker, saygm.com, the list price rose from $1.00/$3.20 (GLM-5) to $1.40/$4.40 when GLM-5.1 launched in April and has held there since, so don't assume this vendor's prices only go down.

How it stacks up on list price

VentureBeat compared a workload of 1M input plus 1M output tokens across several models. On that blend:

On paper that is roughly a fifth of the Opus 5 figure and a sixth of GPT-5.6 Sol. Two caveats apply before you quote those ratios to anyone:

1. Comparison prices vary by source. Frontier vendors have multiple tiers, and the blended number depends on which tier and which context length you assume. Treat the table as VentureBeat's snapshot, not a universal truth.
2. A 1:1 input/output blend is arbitrary. Agent workloads are usually input-heavy (long context, tool results, repeated system prompts), which makes cached-input pricing matter more than the headline output rate.

For reference, an input-heavy agent step with 50K input tokens and 2K output tokens costs, at GLM-5.3 list rates, about $0.07 for the input and $0.0088 for the output, so roughly $0.079 per step. That is illustrative arithmetic with round numbers, not a measurement. The point is that input dominates, so cache hit rate is your main lever.

Per-token price is not per-task price

This is the part most "cheap model" posts skip. Artificial Analysis estimates GLM-5.3 at about $0.68 per Intelligence Index task, against roughly $0.44 for GLM-5.2, per VentureBeat's report. The per-token rates are identical. The difference is verbosity: GLM-5.3 produces more output tokens to get its answers, so the same rate card yields a roughly 55% higher task cost.

That finding sits awkwardly next to z.ai's own claim, from the GLM-5.3 overview docs, that the model gives stronger agentic coding results than GLM-5.2 at every effort level while using fewer output tokens. Both can be true, because they measure different things: one is a general intelligence benchmark, the other is z.ai's agentic coding evaluation. For your workload, neither is a substitute for measuring.

The practical takeaway: never compare models on the rate card alone. Compare cost per completed task at your acceptance threshold. A model that is 5x cheaper per token but needs 2x the tokens and a 20% retry rate is not 5x cheaper.

What the model is, and what it isn't

According to z.ai's docs, GLM-5.3 uses the same base model as GLM-5.2, with all improvements coming from post-training. That tells you what kind of upgrade this is: better behavior, not a new architecture. Expect improvements in instruction following, tool use, and coding, and don't expect a step change in raw knowledge.

On quality, Artificial Analysis gives it a score of 60 on its Intelligence Index, tying Kimi K3 as the top open-weights model and seven points above GLM-5.2. That puts it at the front of the open-weights pack. It does not tell you how it compares to the closed frontier models on your tasks, and an index score is an average over someone else's task mix.

Where this tends to be worth testing, based on how agent workloads are shaped:

• High-volume, well-specified steps: classification, extraction, routing, summarization of tool output, first-pass drafting.
• Coding sub-tasks inside a larger pipeline: file-level edits, test generation, refactors with clear specs.
• Fan-out research or enrichment: many parallel calls where one wrong answer is cheap to detect.

Where I'd stay cautious: long-horizon tasks where one early wrong step poisons everything downstream, and anything where a silent failure is expensive. Cheap models are great when failure is detectable and recoverable.

The cyber claims: what's real and what's vendor marketing

The launch story centered on security capabilities. z.ai's developer advocate posted on X that GLM-5.3 found a "potentially serious vulnerability in Cursor" during a reverse-engineering task, and that the issue was disclosed privately while the Cursor team works on a fix.

Read that for what it is: a vendor claim. Reported benchmark numbers come from z.ai's own testing and haven't been independently verified, according to BetaNews:

• CyberGym: 84.5%, up from 77.2% for GLM-5.2
• ExploitBench: 54.4%, up from 24.4%
• z.ai's disclosure ledger credits the model with 2,436 vulnerability findings across 269 open-source projects, 1,097 of them rated critical or high (sources disagree on that severity wording)

Per shattered.io, only 53 findings were public at launch, with 2,383 under embargo. Embargoed findings can't be checked by anyone outside the process yet.

Why this matters for a small business choosing an API: it affects policy and licensing more than daily usage. A model that is meaningfully better at offensive security work is a model whose vendor will face pressure on access controls, and that shows up in the license terms below. It also means you should apply the same prompt-injection and permission hygiene you'd apply to any agent, because a more capable model with broad tool access is a bigger blast radius if something goes wrong.

License, weights, and who it applies to

Reported release details are a bit tangled, so here is what I'd rely on and what I wouldn't.

Reasonably consistent: the announcement was on August 14, 2026, according to z.ai launch materials as reported by shattered.io. Treat the announcement date and the date API access began as two different things, and check z.ai's official channels for exact dates.

Open weights: multiple sources report that the weights were released on August 28, 2026 on Hugging Face under a custom GLM-5.3 license. Earlier articles said the license had not yet been published, so older coverage may be out of date. Check the official repository and its LICENSE file for the current state before you build a plan around self-hosting.

The license clause worth knowing: GLM-5.3 reportedly uses a custom "GLM-5.3 License" rather than the MIT license used for GLM-5.2. Sources differ on the details of a revenue-based condition that reportedly applies to Model-as-a-Service providers above a high revenue threshold. I have not verified the license text directly, so read it yourself. If you're a solopreneur or a team of ten using the model for your own business, this is unlikely to be your concern, but read the actual license text if you plan to redistribute, host the model for others, or fine-tune. I'm relaying the reported terms, not giving legal advice.

Where you can buy it, and why the host matters

Calling z.ai's first-party API is not the only option. In one comparison, OpenRouter listed dozens of endpoints from many hosts with input prices spread across a very wide range, per mxchat.ai. z.ai's own first-party rate in that comparison was $1.40/$4.40.

That spread is wide enough to be suspicious. Cheaper hosts can mean quantized weights, different context limits, lower throughput, or different data handling terms. Before routing client data through a third-party host, check:

• Which precision/quantization the endpoint serves
• Context window and max output limits actually enforced
• Data retention and training-use terms
• Rate limits and uptime history

If you're on a GLM Coding Plan instead of the pay-as-you-go API, check the current plan prices and metering rules per felloai.com and z.ai's own pages, since plans have changed from prompt-based to credit-based metering. And according to VentureBeat, developers who previously subscribed to a Coding Plan are currently limited to the OpenAI Chat Completions-compatible protocol, which affects which SDKs and tools you can point at it.

A test harness before you migrate anything

Don't switch because a chart says so. Run your own tasks through both models and measure cost per accepted result. A minimal approach with the Chat Completions-compatible protocol:

import time, json
from openai import OpenAI

# Check z.ai's docs for the current base URL and model IDs
client = OpenAI(base_url="<ZAI_BASE_URL>", api_key="<KEY>")

PRICE = {"in": 1.40, "cached": 0.26, "out": 4.40}  # $/1M tokens, re-check live page

def run(task, model):
    t0 = time.time()
    r = client.chat.completions.create(
        model=model,
        messages=task["messages"],
    )
    u = r.usage
    cost = (u.prompt_tokens * PRICE["in"] + u.completion_tokens * PRICE["out"]) / 1e6
    return {
        "output": r.choices[0].message.content,
        "cost": cost,
        "latency": time.time() - t0,
        "out_tokens": u.completion_tokens,
    }

results = []
for task in json.load(open("eval_tasks.json")):
    res = run(task, "<GLM_MODEL_ID>")
    res["passed"] = task["check"](res["output"])  # your own acceptance test
    results.append(res)

passed = [r for r in results if r["passed"]]
print("pass rate:", len(passed) / len(results))
print("cost per accepted task:", sum(r["cost"] for r in results) / max(len(passed), 1))

Rules for the eval:

1. Use 50-100 real tasks from your logs, not synthetic ones. Include the ugly edge cases.
2. Define acceptance before you run it. Exact-match checks, schema validation, or a rubric scored by a separate model. Decide the threshold first.
3. Track output tokens per task, not just cost. Verbosity is how a cheap rate card turns expensive.
4. Run each model at several effort/reasoning settings if the API exposes them. z.ai says improvements show at every effort level, so test the low settings, which are where the savings usually are.
5. Repeat a few times. Single runs on agentic tasks are noisy.

The metric to report is cost per accepted task, plus the failure modes of the rejected ones. If the failures are cheap to detect (schema errors, failed tests), a cheaper model with a retry or escalate-to-frontier fallback usually wins.

A routing pattern that works

Once you have numbers, the usual outcome is not "replace the frontier model" but "stop sending everything to it." A simple tiered design (the model IDs below are placeholders; look up the exact IDs in z.ai's model documentation and pricing page):

routes:
  - match: {step: classify|extract|route}
    model: <GLM_FLASH_MODEL_ID>   # cheapest tier
  - match: {step: draft|code_edit}
    model: <GLM_MODEL_ID>         # mid-cost, validated by tests/schema
    on_fail: escalate
  - match: {step: plan|high_stakes}
    model: <FRONTIER_MODEL_ID>    # Claude/GPT-class for hard reasoning
validation:
  schema_check: true
  max_retries: 1

The two ingredients that make this safe are a cheap, automatic validator on each step and an escalation path when validation fails. Without those, you're just gambling on a cheaper model.

Also keep your prompts cache-friendly: stable system prompt and tool definitions first, variable content last. With cached input listed at $0.26 per 1M versus $1.40 uncached, a high hit rate cuts the dominant cost line. Remember the free cached-storage promotion is limited-time, so model your costs without it.

How I approach this

I build AI automations and test models on real tasks. The method is the one above: take real tasks from your logs, define acceptance checks up front, measure cost per accepted task at several settings, then assign each step to the cheapest model that clears the bar, with escalation to a stronger model on validation failure. GLM-5.3's pricing makes it a serious candidate for the high-volume, easily validated steps, and the Flash tiers are worth testing for classification and extraction.

What I don't do is declare a winner from a leaderboard. Verbosity, host differences, and licensing details change the real answer per workload, and models and prices shift often enough that routing tables need re-testing on a schedule. If your token bill is the problem, start by measuring your own traffic: pull a sample of real tasks, run them through the harness above, and see what the numbers say.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.