Contents
Z.ai pushed GLM-5.3 live this week, and the interesting part is not the model weights, it is what the release quietly removes from the API surface. GLM-5.3 reuses the GLM-5.2 base model unchanged and gets every reported gain from post-training alone, which is itself a useful data point: a lab treating post-training as a first-class lever rather than a consolation prize while everyone waits for the next pretraining run. But the change that actually touches your code is smaller and easy to miss in the changelog. GLM-5.3 no longer accepts a disabled thinking mode. Send thinking: { type: "disabled" } and the request fails outright instead of quietly falling back to a non-reasoning response.
That is a real API contract change, not a footnote, and it is worth understanding before you point production traffic at the new model tag.
Three things worth understanding
The pricing did not move, but the floor for reasoning did. GLM-5.3 carries the same rate card as GLM-5.2, $1.40 per million input tokens, $0.26 for cached input, $4.40 per million output tokens. If you were previously disabling thinking on simple, latency-sensitive calls to keep costs down and responses fast, that lever is gone on this model. Every request now pays for at least some reasoning overhead, whether the task needs it or not.
Effort levels are the new dial, and max is the default. In place of an on/off switch, GLM-5.3 exposes three effort levels: low, high, and max. Left unset, requests run at max, the most expensive and slowest setting. Anyone migrating from GLM-5.2 without explicitly setting effort: "low" on cheap, high-volume calls is about to see both latency and output-token counts creep up for no functional gain.
The benchmark gains land squarely on agentic and terminal work. Z.ai’s own numbers put GLM-5.3 at 28.3 percent on Terminal-Bench 3.0, against 4.6 percent for GLM-5.2, a jump large enough that it reads less like a tuning improvement and more like the model finally learning to use a shell competently. Paired with the 1,048,576-token context window carried over from 5.2, this is clearly aimed at long-horizon coding agents that read a repo, plan, execute, and self-correct across many tool calls, not at single-turn chat completions.
Try it: effort-level cost estimator
The practical question for anyone budgeting API spend is how much a stray default max effort setting costs across a batch of calls. Enter your expected input, cached input, and output tokens per request below to see the cost, then compare what happens if you pin cheap calls to low effort instead by trimming the output-token estimate.
About the demo
This uses GLM-5.3’s published per-million-token rates and a simple output-token multiplier per effort level to illustrate the shape of the tradeoff. It does not call a live Z.ai endpoint.Enter your numbers and click Estimate.
Where this leaves API consumers
The headline framing is that GLM-5.3 is a stronger coding and terminal-automation model at no extra list price, and on the Terminal-Bench numbers that holds up. But the removal of disabled thinking is the part worth acting on this week, not next quarter. Anyone with GLM-5.2 integrations that leaned on thinking-off for cheap classification calls, simple lookups, or latency-sensitive UI paths needs to either move that traffic to effort: "low" explicitly or budget for the reasoning overhead landing at max by default. My take is that this is Z.ai signaling it wants GLM to be an agent-first model line, one where every call carries at least a little deliberation, and treats pure zero-reasoning completion as a use case for a different, smaller model rather than a mode of this one. The practical move is to audit your GLM call sites this week, tag each one by whether it actually needs max reasoning, and set effort levels explicitly instead of inheriting a default that just got a lot more expensive.