GLM-5.2 Reasoning Effort: High, Max, or Off

Evan Brooks

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial Team · Published and editorially reviewed July 18, 2026

How we research and review · Report a correction

Disclosed editorial pen name · AI-generated portrait

The short answer

Z.ai accepts seven reasoning_effort values for GLM-5.2, but its direct API documents only three effective paths. none or minimal skips thinking; low, medium, or high uses high; and xhigh or max uses max. Start with thinking off for simple, cheap-to-check work, high for bounded multi-constraint work, and max only when a harder failure would cost more than the extra reasoning.

The label is easy to misunderstand. Seven accepted strings look like a seven-step quality dial. They are not. On Z.ai’s documented direct API, several values are compatibility aliases, and the default is already max.

That makes the useful question narrower: when should a request use off, high, or max? The answer depends on the cost of a wrong result, the number of constraints, and whether the result has a cheap objective check. It does not depend on the task being called “coding” or “reasoning.”

In this guide

1. The direct answer
2. Seven values, three effective paths
3. Choose by failure cost
4. A reproducible output-cost sensitivity
5. Route effort per turn
6. Set the direct API explicitly
7. Do not confuse effort, output caps, and preserved thinking
8. Coding clients and providers can differ
9. Run a small acceptance test
10. Questions people ask
11. Sources and method

The direct answer

Use this as a starting rule, then replace it with evidence from your own requests:

Effective path	Start here when	Cheap check	Main risk
Thinking off	extraction, rewriting, classification, or a small deterministic transform	parser, schema, exact diff, or unit test	misses hidden constraints
High	bounded debugging, a multi-file edit, tool selection, or a decision with several stated constraints	tests plus review	spends more than an easy task needs
Max	long-horizon planning, ambiguous architecture, difficult root-cause analysis, or a costly irreversible decision	full evaluation or expert review	high token use and latency

This table is an editorial decision rule, not a quality benchmark. Z.ai recommends max as its default deep-reasoning mode. A default is a safe capability choice for a general endpoint; it is not proof that every request earns the extra computation.

Seven values, three effective paths

The Z.ai core-parameters guide and Chat Completion reference document the normalization:

Value sent	Documented behavior
none, minimal	skip thinking
low, medium, high	use high
xhigh, max	use max

The important correction is that low and medium do not create smaller native GLM-5.2 effort levels on this route. They map to high. Likewise, xhigh maps to max. A client may show a familiar OpenAI-style scale while the provider executes one of three paths.

Thinking itself defaults to enabled, and reasoning_effort defaults to max. Set both fields explicitly when reproducibility matters. Otherwise, a missing field, client update, or provider translation can look like a model-quality change.

Choose by failure cost

Use thinking off when all three conditions hold:

1. the request has few interacting constraints;
2. a machine or reviewer can detect failure cheaply;
3. a retry does not cause external side effects.

Examples include extracting named fields, changing copy tone, classifying a support ticket, or converting a small object into another documented schema. Validation still matters. “Off” means less inference work, not trusted output.

Use high when the model must reconcile several constraints or make a bounded sequence of decisions. A bug with a failing test, a small refactor with an explicit API contract, or a tool call with a clear success state fits this path. High is the most useful baseline for comparing whether deeper reasoning improves accepted work.

Use max when ambiguity and downstream damage dominate the request cost: architecture across many modules, a long agent trajectory, a subtle production incident, or a plan whose mistakes would create days of rework. Max still needs tests and approval. It buys a deeper reasoning path, not correctness.

A reproducible output-cost sensitivity

Z.ai listed GLM-5.2 at $1.40 per million fresh input tokens, $0.26 per million cached input tokens, and $4.40 per million output tokens on July 18, 2026. Its deep-thinking guide warns that thinking consumes extra tokens.

The following is an illustration, not a measured GLM52.ai run. Hold input constant and suppose three requests report these total generated-token counts, including reasoning and the visible answer:

Illustrative path	Generated tokens	Output cost at $4.40/M
Off	2,000	2,000 / 1,000,000 × $4.40 = $0.0088
High	10,000	10,000 / 1,000,000 × $4.40 = $0.0440
Max	34,000	34,000 / 1,000,000 × $4.40 = $0.1496

In this sensitivity, max costs $0.1056 more than high:

(34,000 - 10,000) / 1,000,000 × $4.40 = $0.1056

Even two high calls would cost $0.0880, below the illustrative max call. That arithmetic does not make high the winner. Max can still be economical if it avoids enough retries, human repair, latency, or production risk. The correct metric is cost per accepted result, not cost per call.

Do not copy the example token counts into a budget. Effort labels do not promise fixed reasoning length. Log the exact route’s prompt_tokens, cached input, completion_tokens, latency, retries, and accepted-task result.

Route effort per turn

Z.ai documents turn-level thinking: one conversation can use a fast turn for a simple action and a deeper turn for a difficult decision. A coding agent might route a task this way:

Turn	Suggested starting path	Reason
inventory files and read manifests	off	mostly retrieval and summarization
choose an architecture or migration boundary	max	errors propagate across the task
implement a bounded file change	high	several constraints, objective tests
interpret a surprising test failure	high or max	escalate only when evidence stays ambiguous
write the final status summary	off	source facts already exist

This per-turn route is more precise than assigning max to an entire session. It also makes evaluation easier: each phase has a purpose and an observable finish line.

Set the direct API explicitly

For a bounded task on the direct API, send both controls:

{
  "model": "glm-5.2",
  "messages": [{ "role": "user", "content": "Diagnose this failing test and propose the smallest safe fix." }],
  "thinking": { "type": "enabled" },
  "reasoning_effort": "high"
}

For a lightweight turn, set thinking.type to disabled. Sending reasoning_effort: "none" or "minimal" also skips thinking on the documented direct route, but an explicit thinking switch makes the intention easier to audit.

Treat model-generated tool calls and JSON as untrusted input. Validate arguments, set timeouts, require approval for destructive operations, and cap retries. More reasoning does not expand the model’s permissions.

Do not confuse effort, output caps, and preserved thinking

reasoning_effort selects a reasoning path. max_tokens caps how much the model may generate. A low output cap can truncate reasoning or the answer; it does not turn max into high. Z.ai currently documents a 131,072-token maximum output for GLM-5.2, while the request default is 65,536. Your client or host may expose less.

Preserved thinking is another control. The thinking-mode guide says the standard API clears prior reasoning by default. If clear_thinking is false, the application must return every historical reasoning_content block complete, unchanged, and in order. Editing or dropping those blocks can hurt continuity and cache behavior.

Do not enable preserved thinking just to chase cache hits. It can add history to the prompt. Measure total billed input, cached input, output, latency, and task acceptance together.

Coding clients and providers can differ

Z.ai’s GLM-5.2 launch article tells Coding Plan users to choose High or Max. The direct API documents the broader seven-value compatibility surface. A gateway, self-hosted runtime, or coding client may translate the field, expose only a subset, or use another default.

Check the outgoing request and response usage before comparing two modes. Pin the model ID, endpoint, precision, client version, prompt, tools, context, and sampling settings. The temperature, top P, and do_sample guide shows why hosted and direct-Transformers defaults can select different decoding modes even when the visible numeric values match. Our GLM-5.2 API provider comparison explains why routes with the same model name can still differ. Use the API cost calculator after you have observed token counts.

Test reasoning in a supported coding agent

Use the Coding Plan only when a supported coding agent fits your workflow. Confirm which model identifier and effort controls the client actually sends before comparing latency or quality.

Review GLM Coding Plan access →

Affiliate disclosure: This is an affiliate link. GLM52.ai may earn a benefit after a qualifying purchase at no added charge from us. The relationship does not change the reasoning-mode mapping, effort calculations, or test advice.

Run a small acceptance test

Build a set of 20 to 30 real tasks with a clear finish line. Include easy transformations, bounded debugging, and difficult planning. Freeze the endpoint and all settings except effort.

For each run, record:

• effective mode and full request parameters;
• fresh, cached, and completion tokens;
• time to first token and total latency;
• tool-call count, retries, and terminal errors;
• pass/fail against tests or a fixed rubric;
• reviewer repair minutes and any unsafe action.

Compare off against high on the easy group and high against max on the harder groups. Use:

cost per accepted result = (API cost + repair cost) / accepted tasks

A mode earns promotion only when its higher accepted-task value exceeds its extra token, latency, and review cost. Keep a rollback setting. Provider behavior and model versions can change.

Questions people ask

Does low cost less than high on GLM-5.2?

Not as a distinct documented direct-API mode. Z.ai maps low and medium to high. Actual token counts can still vary from run to run, so compare response usage instead of assuming equal bills.

Is max always the best GLM-5.2 reasoning effort?

No. It is the documented default and deepest path, but simple tasks can spend more tokens and time without creating more accepted value. Test high against max on your difficult tasks.

Can I disable GLM-5.2 thinking?

Yes. Set thinking.type to disabled. The direct API also documents none and minimal as values that skip thinking.

Does max_tokens control reasoning effort?

No. It caps generated output. reasoning_effort selects the path. A cap that is too small can truncate the result at any effort level.

Does prompt caching make max reasoning cheap?

Prompt caching discounts eligible input. Generated reasoning remains output work. Preserved thinking may improve continuity and cache hits, but it can also lengthen history. Measure the complete usage response.

Is Coding Plan behavior identical to the standard API?

Do not assume it is. Z.ai documents different preserved-thinking defaults, and clients may expose only High and Max. Inspect the selected model, client controls, quota display, and request trace available on your surface.

Sources and method

We checked first-party documentation and current search results on July 18, 2026. We did not call a paid GLM endpoint, measure latency, or run an independent quality benchmark. The token table is a labeled sensitivity calculation, not observed model behavior. Recommendations are editorial inferences from task risk and testability.

• Z.ai core parameters — default, accepted values, compatibility mappings, and output limits.
• Z.ai Chat Completion reference — request fields, defaults, usage fields, tools, and response formats.
• Z.ai thinking mode — turn-level, interleaved, and preserved-thinking behavior.
• Z.ai deep thinking guide — mode examples, task guidance, and token/latency cautions.
• Z.ai pricing — direct GLM-5.2 list rates checked for the calculation.
• Official GLM-5.2 model guide and launch article — capability positioning, evaluation settings, and Coding Plan surface.
• Reasoning-max question and token-use discussion — interest signals only, not product evidence.

About the editorial role

Evan Brooks

AI Infrastructure Editor

Evan Brooks serves as GLM52.ai’s disclosed editorial pen name for infrastructure, deployment, and training guides. The role examines checkpoint size, memory math, provider limits, implementation evidence, and operational risk. The GLM52.ai Editorial Team produces and fact-checks every article under this byline.

The GLM52.ai Editorial Team accepts responsibility for this article. Read our editorial policy or request a correction.

An AI image tool created this portrait. It does not depict a real individual.