Z.ai's GLM-5.3, released August 14, drops the ability to turn reasoning off entirely. Its documentation states that the model supports reasoning only and that disabling reasoning is not supported. The one lever left is reasoning_effort, which accepts low, high and max, and defaults to max. If you port a GLM-5.2 integration without touching it, every call you make, including trivial ones, now runs at the most expensive setting available.
Most frontier models released this year give you two dials: a switch that turns thinking on or off, and a knob that controls how much thinking happens when it is on. Teams build around that shape. Cheap classification and extraction calls go through the thinking off path, hard agentic work goes through thinking on, and the routing logic in between is where a lot of inference budget gets saved. GLM-5.3 removes the switch. Z.ai's documentation says plainly that the model supports reasoning only and that disabling reasoning is not supported.
That matters most for anyone upgrading from GLM-5.2, which did support turning thinking off. The model identifier changes from one string to another, the API surface otherwise looks familiar, and a request that used to run without reasoning will now run with it, silently. Nothing errors. Your latency and your cost both move, and the only visible symptom is a bill.
The second half of the problem is the default. GLM-5.3 exposes reasoning_effort with three values, low, high and max, and the documented default is max. Not low, not a middle setting, max. That default is defensible given what the model is built for. Z.ai says GLM-5.3 uses the same base model as GLM-5.2 with all improvements coming from post training, and the gains it reports are concentrated in long horizon coding and security work, exactly the tasks where more deliberation pays. It is a poor default for the other eighty percent of what a production system actually asks a model to do.
There is a third constraint worth knowing before you architect around this model. The context window is 1 million tokens, but the documented maximum output length is 128K tokens. Those two numbers get conflated constantly. You can feed GLM-5.3 an entire repository; you cannot ask it to emit one in a single response. Any workflow that assumes a large context implies a large generation, such as whole codebase rewrites or full document translation in one pass, needs explicit chunking on the output side.
Put together, the practical posture is straightforward. Treat GLM-5.3 as a deliberation model rather than a general purpose one, set reasoning_effort explicitly on every call path rather than inheriting the default, and keep a cheaper model in the routing table for the work that never needed reasoning in the first place.
Try it today
- Grep your codebase for every place you disable or toggle thinking on a Z.ai call. Those code paths become no ops on GLM-5.3, and any cost model built on them is now wrong.
- Set reasoning_effort explicitly at every call site instead of relying on the default. Start at low for extraction, classification, routing and formatting; reserve high and max for long horizon coding, security review and multi step agent runs.
- Run an A/B on one representative workload at low versus max before rolling out. If low is good enough for that task, the default was costing you the entire difference for no measurable gain.
- Cap generation explicitly and chunk anything that could exceed 128K output tokens, regardless of how much room the 1M token context leaves on the input side.
- Keep a non reasoning model in your routing tier. GLM-5.3 no longer gives you a fast path internally, so the fast path has to live in your router.