GLM-5.2 pricing: what a token actually costs.

Quick answer: the published rates, and the multiplier that matters.

As published on Z.ai's international pricing page in July 2026, GLM-5.2 lists at $1.40 per million input tokens and $4.40 per million output tokens, with cached input at $0.26 per million and cache storage marked limited-time free. GLM-5.1 lists at the same rates; GLM-5 sits lower at $1 input and $3.20 output. Vendor list prices vary by platform and currency; the Official Price column in the catalog table further down is the list rate the catalog tracks, and the Our Price column is what a request through APIsRouter actually bills. Per-token rates are only half the bill for this model. GLM-5.2 is a reasoning model, and its internal thinking tokens bill as output, the expensive side of the meter. One independent reviewer measured GLM-5.2 consuming around 43K output tokens per task on his agent benchmark against roughly 26K for GLM-5.1 on the same tasks. That is one benchmark, not a law, but the direction is worth pricing in: a 5.2 upgrade can raise output volume at the same time it raises output quality.

Token math: three request shapes at Z.ai list rates.

The table below prices three representative request shapes at Z.ai's published international rates ($1.40 in / $4.40 out per million, July 2026). Output figures include reasoning tokens, which is why the agent-step row carries more output than its visible answer would suggest. Your own token counts will differ; the usage block on every response gives the exact numbers to rerun this table against.

Where reasoning tokens show up on the bill.

None of this makes GLM-5.2 expensive in absolute terms; its list rate sits well under Western flagship pricing. It makes GLM-5.2 mispriceable: teams that project costs from visible answer lengths underestimate, and teams that watch usage for a day price it right.

• Reasoning tokens bill as output. On a hard prompt, GLM-5.2 can spend more tokens thinking than answering, and completion_tokens counts both. The visible answer length is not the billed length.
• finish_reason=length is a paid failure. If max_tokens is set for the answer you expect from a non-reasoning model, the call can burn its whole budget on reasoning and stop before visible content appears. You pay for the truncated call and again for the retry.
• Thinking is tunable upstream. Z.ai's API exposes a thinking toggle and an effort setting; lower effort trims reasoning volume at some quality cost on hard tasks. Through a plain OpenAI-compatible surface, test which behavior your requests get rather than assuming.
• Output caps are your throttle. A max_tokens value with real headroom (two to four times the expected visible answer) avoids truncation; a per-request log of completion_tokens catches drift before it compounds across a batch.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Five ways to cut a GLM-5.2 bill without changing models.

The common thread is measurement. Every response carries prompt_tokens and completion_tokens, and the per-key usage view in the console turns a day of real traffic into a per-workload price list. Optimize against that, not against list rates.

• Downshift inside the family. glm-5 and glm-5.1 share the request shape at lower rates. Route hard coding and agent steps to glm-5.2 and everything that passes evals on a sibling to that sibling.
• Trim the resent context. Chat and agent workloads resend history every turn, so input volume grows quadratically with conversation length unless you summarize or truncate. Input is the larger share of most GLM bills.
• Exploit cached input where you call Z.ai directly. The published cached-input rate is $0.26 per million against $1.40 uncached (July 2026), which rewards stable prompt prefixes. Catalog pricing through the gateway is the flat input rate in the table above, so treat the cache discount as direct-platform behavior.
• Budget max_tokens once, correctly. Truncated reasoning calls that get retried are pure waste; generous budgets with a retry cap of one are consistently the lower-cost policy.
• Batch the batchable. Classification and extraction prompts with short outputs barely touch the expensive side of the meter; grouping them onto glm-5 keeps the family's strongest rate on the highest volume.

How GLM-5.2 pricing compares across the catalog.

Against its nearest value competitor, the DeepSeek V4 family lists dramatically lower per token (DeepSeek publishes $0.14 input and $0.28 output per million for V4 Flash, July 2026), while GLM-5.2 counters with stronger reported coding-benchmark results at launch. The honest comparison is workload-level, not rate-level, and the dedicated GLM-5.2 vs DeepSeek V4 page works through it. Against Western flagships, the gap runs the other way: GLM-5.2's list rate is a fraction of Claude Sonnet or GPT-5.5 pricing, which is exactly why the reasoning-token overhead is worth managing rather than avoiding. For chat-heavy loads where Kimi K2.6 competes, its catalog rate lands in the same band as the GLM mid-family, and the Kimi reasoning guide covers when its thinking style earns the tokens it spends. Whichever way that comparison lands for your workload, running it through one endpoint keeps it fast to answer: each candidate is a model-string edit, and the usage log prices every candidate run against the same traffic.

Who prices GLM-5.2 this carefully.

The shared thread across all four: the input/output split of the workload decides which lever matters. Input-heavy shapes (agents, long chats) are dominated by resent context, where trimming and family downshifts pay; output-heavy shapes (generation, hard reasoning) are dominated by the $4.40-side of the meter, where thinking-volume management pays. Classify the workload first and the optimization order falls out on its own.

• Coding-agent teams, because agent loops multiply both context resends and reasoning tokens, so a per-step cost error compounds across every run.
• AI SaaS builders working out token COGS, where the input/output split and the reasoning overhead decide unit economics per user.
• Teams migrating from glm-5 or glm-5.1, who need to know whether 5.2's quality lift covers its higher rate and heavier output volume on their tasks.
• Anyone comparing Chinese-model value picks, where GLM, DeepSeek, and Kimi ids sit one string apart behind the same endpoint.

FAQ