GLM-5.2 Max Tokens vs Context Window: Set Safe Limits

Independent research — not an official Z.ai publication.Identity and provider disclosure

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial TeamPublished and editorially reviewed August 15, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

Dense teal token reservoir narrowing through a separate cyan output valve, with an amber boundary marking the independent output limit

Original editorial visualization of the budgeting rule. The large reservoir represents total context; the smaller valve represents a separate output cap. The amber boundary marks a hard limit, not a scale conversion.

Set GLM-5.2 max_tokens from the output your task needs—not from the model’s context window. For Z.AI’s documented hosted route, use 65,536 only when you intentionally want the published default, and never request more than 131,072. Then verify that measured input tokens plus requested output plus a safety reserve fit the effective context exposed by your actual route.

That distinction prevents two different failures. A request can exceed the output ceiling even while its total fits inside 1M. It can also stay below 131,072 output tokens yet exceed a smaller provider or self-hosted context window when input and output are added together.

This guide turns the limits into a two-gate validator. It extracts the current official documents, pins the open checkpoint config, and evaluates ten local budget fixtures. It made zero authenticated API calls and zero model calls, so the results prove the published arithmetic—not entitlement or live route behavior.

The short verdict

The current contract has one native context fact and two hosted output facts. They answer different questions.

Setting or observation	Verified value	What it controls	Do not use it as
Open checkpoint `max_position_embeddings`	1,048,576	Native total sequence capacity in the pinned config	An API output request
Z.AI model-guide context label	1M	Total input-plus-output model context	`max_tokens`
Z.AI default `max_tokens`	65,536	Output allowance when the parameter is omitted	A guaranteed amount the model will generate
Z.AI maximum `max_tokens`	131,072	Highest documented hosted output request	A guaranteed route context
Actual `completion_tokens`	Returned after generation	Output the call consumed	A pre-request capacity promise
Actual `total_tokens`	Prompt plus completion usage	Billable/observable total reported by the route	The configured context ceiling

The official GLM-5.2 guide labels context as 1M and maximum output as 128K. The more precise core-parameter table gives 65,536 and 131,072. The pinned open checkpoint config sets max_position_embeddings to 1,048,576.

Those values agree once units and roles are kept separate. “1M” and “128K” are human-readable labels; the exact configuration and request limits are powers of two.

Four numbers, not one token limit

A model client often exposes a single field called “context,” “token limit,” or “max tokens.” That UI can hide four independent bounds:

Native context is the largest sequence described by the checkpoint.
Route context is what a provider or serving process makes available.
Model output ceiling is the largest output the model contract allows.
Client output cap is what the SDK, agent, proxy, or UI will send.

Use the smallest applicable value at each gate. A native 1,048,576-token window does not force a hosted product to expose the full window. A server started with --max-model-len 131072 intentionally exposes less. A client with a 64K output field also cannot safely request 128K merely because the model supports it.

The request parameter has narrower semantics. Z.AI says max_tokens limits generated content and does not include input. Its context definition includes both input and generated text. Therefore, a valid output value can still create an invalid total sequence.

Use two gates for every request

Calculate two effective limits:

effective_context = min(native_context, route_context, client_context)
effective_output  = min(model_output_max, route_output_max, client_output_max)

1 <= requested_output <= effective_output
input_tokens + requested_output + reserve <= effective_context

The first check rejects a context value accidentally mapped into an output field. The second protects the total sequence. Keep a reserve for chat-template wrappers, tool definitions, retrieval expansion, or estimation drift unless the count was taken from the exact final payload.

Do not silently clamp a caller’s value and proceed. Return both the requested and effective limits so the application can decide whether to shorten the answer, trim input, select a larger route, or stop. A hidden clamp can turn a complete code-generation task into a truncated partial patch.

Why context-window mapping causes a 400

A July 2026 report in Z.AI’s official feedback repository describes an OpenAI-compatible custom-model setting that reused its context-window value as max_tokens. Values of 200,000 and 1,000,000 were reported as rejected because they exceeded the 131,072 output maximum. The reporter says 131,072 and 120,000 were accepted by that Ollama route.

Treat this as a user-submitted reproduction, not a Z.AI-hosted response or a resolved product guarantee. It is still a useful failure shape because the mapping error is visible and deterministic:

{
  "model": "glm-5.2",
  "max_tokens": 1000000
}

The correct data model keeps the fields independent:

{
  "limits": {
    "context_tokens": 1048576,
    "output_tokens": 16384
  }
}

Only output_tokens should map to Chat Completions max_tokens. A Responses adapter may call the request field max_output_tokens; that naming change does not turn context into output.

What the ten budget fixtures prove

Our local audit uses the published 1,048,576 native context, 65,536 hosted default, and 131,072 hosted maximum. It makes no network generation request.

Fixture	Input	Requested output	Other limit	Result	Reason
Hosted default	100,000	omitted → 65,536	native context	pass	both gates have room
Exact output ceiling	400,000	131,072	native context	pass	output equals, not exceeds, the ceiling
Exact native boundary	917,504	131,072	native context	pass	total equals 1,048,576
One over output	1,000	131,073	native context	reject	`OUTPUT_LIMIT_EXCEEDED`
200K context copied to output	1,000	200,000	native context	reject	output gate fails first
1M context copied to output	0	1,000,000	native context	reject	output gate fails despite total fitting
Default near full context	990,000	omitted → 65,536	native context	reject	`CONTEXT_BUDGET_EXCEEDED`; total reaches 1,055,536
Lower served context	150,000	64,000	200,000 route	reject	`CONTEXT_BUDGET_EXCEEDED`; total reaches 214,000
Lower client output cap	10,000	128,000	64,000 client	reject	client output gate is smaller
Reserved overflow	950,000	90,000	10,000 reserve	reject	`CONTEXT_BUDGET_EXCEEDED`; planned total reaches 1,050,000

The exact-boundary positive controls matter. They show that the validator does not merely reject large numbers. The negative controls isolate output overflow, total-context overflow, and a lower client cap as distinct causes.

These fixtures do not prove that a particular account admits a 131,072-token generation, that the model will use the whole allowance, or that such a call is economical. They prove the arithmetic against the dated documents.

Validate the budget before network I/O

Use this compact JavaScript gate before creating the provider request:

const GLM52_NATIVE_CONTEXT = 1_048_576;
const GLM52_DEFAULT_OUTPUT = 65_536;
const GLM52_MAX_OUTPUT = 131_072;

export function validateGlm52Budget({
  inputTokens,
  maxTokens = GLM52_DEFAULT_OUTPUT,
  routeContext = GLM52_NATIVE_CONTEXT,
  routeOutput = GLM52_MAX_OUTPUT,
  clientOutput = Number.POSITIVE_INFINITY,
  reserveTokens = 0,
}) {
  const effectiveContext = Math.min(GLM52_NATIVE_CONTEXT, routeContext);
  const effectiveOutput = Math.min(
    GLM52_MAX_OUTPUT,
    routeOutput,
    clientOutput,
  );

  if (!Number.isInteger(maxTokens) || maxTokens < 1) {
    throw new RangeError('max_tokens must be a positive integer');
  }
  if (maxTokens > effectiveOutput) {
    throw new RangeError(
      `max_tokens ${maxTokens} exceeds output limit ${effectiveOutput}`,
    );
  }
  if (inputTokens + maxTokens + reserveTokens > effectiveContext) {
    throw new RangeError('input + output + reserve exceeds context');
  }

  return { maxTokens, effectiveContext, effectiveOutput };
}

Version the constants with their source hashes. Re-run the audit when Z.AI, your provider, serving image, or client changes. A route-specific receipt can lower the constants; do not raise them above the model contract from an undocumented successful request.

Set max_tokens on the request

The official GLM-5.2 examples use 4,096 output tokens. A production request can choose a different value after the two gates pass:

const limits = validateGlm52Budget({
  inputTokens: measuredPromptTokens,
  maxTokens: 16_384,
  routeContext: documentedRouteContext,
  reserveTokens: 2_048,
});

const completion = await client.chat.completions.create({
  model: 'glm-5.2',
  messages,
  thinking: { type: 'enabled' },
  reasoning_effort: 'high',
  max_tokens: limits.maxTokens,
  stream: false,
});

Do not hard-code documentedRouteContext from the checkpoint alone. Obtain it from the selected product, deployment manifest, or a controlled capability receipt. The GLM-5.2 API provider comparison helps separate model facts from provider exposure.

Verify usage and finish_reason

Preflight protects the request. The response tells you what happened. Z.AI’s Chat Completion schema exposes prompt_tokens, completion_tokens, and total_tokens, plus these termination reasons: stop, tool_calls, length, sensitive, model_context_window_exceeded, and network_error.

Record at least:

const usage = completion.usage;
const finish = completion.choices[0]?.finish_reason;

if (usage.total_tokens !== usage.prompt_tokens + usage.completion_tokens) {
  throw new Error('Unexpected token accounting');
}
if (finish === 'length') {
  throw new Error('Output hit max_tokens; do not treat it as complete');
}
if (finish === 'model_context_window_exceeded') {
  throw new Error('Effective context was smaller than the planned budget');
}

A stop result can finish far below the allowance. max_tokens is a ceiling, not a minimum and not a reservation guarantee. For streamed responses, use the GLM-5.2 SSE parser guide to assemble usage and termination state without confusing a disconnect with a clean finish.

Reserve output for reasoning and the visible answer

GLM-5.2 can return reasoning_content separately from visible content. The public response schema reports one completion_tokens total rather than a separate documented reasoning-token quota. A conservative client should therefore assume that reasoning and the visible answer compete for the output allowance unless its route publishes a more specific receipt.

This is an operational inference from the response shape, not a claim about hidden provider internals. Validate it on your route by preserving the usage object and measuring representative tasks at each reasoning-effort level.

Do not solve truncation by immediately jumping to 131,072. First decide whether the task needs more visible answer, less retained history, a lower reasoning effort, or a different decomposition. A large cap can increase worst-case latency and spend even when typical responses stop early.

Route, client, and server limits can be lower

The official vLLM GLM-5.2 recipe records a native context of 1,048,576, but its standard FP8 launch example sets --max-model-len 131072. It separately sends max_tokens=4096 in an example request. That is the same two-level design: server context and request output are not one value.

Self-hosted limits also depend on KV-cache memory, concurrency, precision, and the serving image. Raising --max-model-len does not create memory. See the local GLM-5.2 hardware guide before exposing a larger context to clients.

For every route, record this tuple:

model revision + server version + served context + output ceiling + client cap

If any member is unknown, use a lower tested value or stop. Do not combine the largest number from one provider with the price, entitlement, or server settings of another.

Choose the smallest cap that completes the task

Start from a task-level acceptance test, not the model maximum.

Workload	Sensible first cap	What to measure before raising it
Short answer or extraction	1,024–4,096	completion rate and JSON validity
Tool selection or bounded code edit	4,096–16,384	tool-call completion and patch acceptance
Repository plan or multi-file patch	16,384–32,768	truncation, latency, review burden
Long agent episode	32,768–65,536	reasoning share, retries, cost, state checkpoints
Exceptional long-form generation	up to 131,072	route admission, human review, timeout, rollback

These are starting recommendations, not published Z.AI quality tiers. The right cap is the smallest one that completes a representative task with the required margin. Use the cost calculator to model worst-case completion usage and the prompt-caching guide to reduce repeated input cost; caching does not enlarge the context window.

Count the request you will actually send

Input must include the rendered system message, retained history, retrieval chunks, assistant reasoning retained by policy, tool definitions, and template tokens. Counting only the latest user sentence can make a passing budget meaningless.

Z.AI’s core guide points to its Tokenizer API, but our Tokenizer contract audit found that the published auxiliary endpoint enum did not yet list glm-5.2 on August 14. That gap is not proof of live rejection; it is a reason to avoid claiming a hosted GLM-5.2 count without a documented or authorized receipt.

For self-hosted checks, render the pinned GLM-5.2 chat template and count the resulting token IDs. Keep a reserve when provider wrappers are unknown. Recalculate after adding or changing tools: schemas and descriptions consume context even when the user message stays the same.

Choose access after the budget is correct

A correct budget does not grant model entitlement or select the best product. Choose the Z.AI API when you need usage receipts and metered application calls; choose Coding Plan for supported interactive coding clients; choose self-hosting only when the infrastructure can honor the served context and output policy you advertise.

Sources, method, and limits

Primary and authoritative sources checked on August 15, 2026:

Z.AI core parameters — max_tokens semantics, 65,536 default, 131,072 maximum, and the input-plus-output context definition;
Z.AI GLM-5.2 guide — 1M context, 128K maximum output, and official request examples;
Z.AI Chat Completion reference — request maximum, usage fields, and finish reasons;
official GLM-5.2 model repository at revision b4734de4facf877f85769a911abafc5283eab3d9 — exact 1,048,576 config value and model card;
official vLLM GLM-5.2 recipe — separate native context, served context, and request-output settings;
Z.AI feedback issue #96 — a user-submitted reproduction of the context-to-output mapping bug, treated as incident evidence rather than an official service guarantee;
Z.AI GLM-5.2 release page and Zhipu AI research index — fixed first-party discovery checks.

The reproducible audit fetched public artifacts with an identifiable user agent and 30-second bounds, pinned the current model revision, hashed every response, and ran ten deterministic budget fixtures. The local and public evidence receipt contain no credential, cookie, prompt corpus, account identifier, or provider response.

No authenticated API, tokenizer, generation, or grader call was made. The audit does not prove route entitlement, tokenization parity, latency, cost, quality, or that a client accepts a particular field name. Recheck official documents and run one bounded, authorized route test before raising production limits.

GLM-5.2 max tokens FAQ

Does GLM-5.2 have a 1M-token output limit?

No. Z.AI labels the context window as 1M and the maximum output as 128K. The exact pinned native context is 1,048,576, while the current documented hosted max_tokens ceiling is 131,072.

What happens if I omit max_tokens?

The current Z.AI core-parameter table lists 65,536 as the GLM-5.2 default. Omission does not guarantee a 65,536-token response; generation can stop earlier. It can also leave too little room near a full context, so validate the default as an explicit planned output.

Is max_tokens 131072 always safe?

Only at the model-output gate. It still fails if input plus output exceeds the effective context, or if the route or client imposes a lower output cap. Verify all applicable limits before sending it.

Does max_tokens include the input prompt?

Z.AI documents max_tokens as generated output excluding input. The context window includes both. That is why the validator checks output and total context separately.

Do reasoning tokens use the same budget?

The public response schema returns reasoning_content and visible content but documents one completion_tokens output count. Treat both as sharing the output allowance unless your exact route publishes and verifies a more specific accounting rule. For self-hosted vLLM, the GLM-5.2 thinking-budget guide shows how to place a numeric reasoning sub-limit inside that same outer allowance while preserving an explicit final-answer reserve; it is a vLLM-only control, not a replacement for this route-level capacity check.

Should an OpenAI Responses client use max_output_tokens instead?

Use the field required by that endpoint or adapter, but keep its value sourced from the output limit. Never map the context-window setting directly to max_tokens or max_output_tokens.