Z.ai GLM 5.3 is a large-scale text reasoning model designed for complex software engineering and long-horizon agent work. The manufacturer states that it uses the same base model as GLM 5.2, with the new gains coming from post-training. The release focuses on stronger programming, terminal operations and broader tasks that involve several dependent steps. It accepts text and produces text, including code, explanations, plans and tool-call requests in a tool-connected application.
The documented reasoning mode is always enabled. GLM 5.3 offers three effort levels: low, high and max, with max as the default. The maker recommends max for complex coding work; low provides a lighter reasoning option for simpler steps. Use the selected level together with a clear final deliverable and completion criteria. For example: “Inspect these files and failing results, trace the cause across the affected modules, propose a correction that preserves the public interface, and explain which checks establish that the regression is resolved.”
The maker specifies a 1M-token context window and a maximum output length of 128K tokens. Organize long material around the relationship the model needs to investigate. Preserve file names, relevant definitions, source labels and the order of observations, and leave room for the reasoning and final answer within the applicable working context. A large window is useful for cross-module dependencies or a long sequence of agent observations; it does not make an undirected archive of unrelated material a well-defined task.
For repository work, provide the expected behavior, relevant source text, dependency versions and actual error output. Ask the model to identify the affected behavior before proposing a patch. For a refactor, name the interface and invariants that must remain intact. A useful response contains the revised code, why the change addresses the observed problem, and the cases needed to check the result. Feed actual results back into a tool-connected workflow so the next step is based on the changed state rather than on the earlier proposal.
For performance work, supply a workload, a baseline and measurements such as timings, profiles or allocation records. Z.ai describes training tasks involving bottleneck diagnosis, optimization, experiments and correctness-preserving results. A practical request is: “Use this profile to identify the most consequential bottleneck, propose one measurable change, and explain what result would justify keeping it.” Distinguish a hypothesis about performance from a recorded improvement. Preserve the same workload and relevant conditions when inspecting a result.
The release also develops vulnerability-analysis capability. For defensive source review, provide the relevant code, its intended trust boundaries and the conditions under which it runs. Ask for a finding that connects a suspected issue to the affected input, behavior and a focused remediation. Separate a potential weakness from a reproduced fault, and retain the observation used to validate it. A report is more useful when it prioritizes concrete evidence and proposed corrections rather than treating every suspicious pattern as a confirmed vulnerability.
Function calling lets a surrounding application expose external operations to the model. Define each tool’s purpose, arguments and expected result, then return the actual tool observation for the next step. The model can reason over that result and decide how it changes the task. Keep proposed actions, executed operations and unresolved checks distinguishable. The maker also documents streaming responses, which return reasoning and answer fragments separately; assemble the completed answer before treating it as the final report or code explanation.
The local model card provides a specific history-setting detail: its chat template keeps thinking by default, while the maker recommends explicitly clearing old thinking for ordinary chat scenarios. Apply the appropriate conversation structure for the use case, preserving the actual completed answers and tool results needed for continuation. Avoid treating reasoning-control settings from GLM 5.2 or the separate GLM 5.3 Flash editions as interchangeable with this model’s low/high/max controls.
For structured results, specify the expected fields, types and source rules. A useful artifact might be a defect table, a change plan or a JSON object summarizing observations. Validate both the structure and the values before an application uses them. The final result should identify the answer or revised artifact, the evidence supporting it and the remaining assumptions. More reasoning effort does not establish that a tool ran, that a proposed patch passed its checks, or that a factual claim has support beyond the supplied material.
", "aboutText": "Z.ai GLM 5.3 is a large-scale text reasoning model designed for complex software engineering and long-horizon agent work. The manufacturer states that it uses the same base model as GLM 5.2, with the new gains coming from post-training. The release focuses on stronger programming, terminal operations and broader tasks that involve several dependent steps. It accepts text and produces text, including code, explanations, plans and tool-call requests in a tool-connected application.\n\nThe documented reasoning mode is always enabled. GLM 5.3 offers three effort levels: low, high and max, with max as the default. The maker recommends max for complex coding work; low provides a lighter reasoning option for simpler steps. Use the selected level together with a clear final deliverable and completion criteria. For example: “Inspect these files and failing results, trace the cause across the affected modules, propose a correction that preserves the public interface, and explain which checks establish that the regression is resolved.”\n\nThe maker specifies a 1M-token context window and a maximum output length of 128K tokens. Organize long material around the relationship the model needs to investigate. Preserve file names, relevant definitions, source labels and the order of observations, and leave room for the reasoning and final answer within the applicable working context. A large window is useful for cross-module dependencies or a long sequence of agent observations; it does not make an undirected archive of unrelated material a well-defined task.\n\nFor repository work, provide the expected behavior, relevant source text, dependency versions and actual error output. Ask the model to identify the affected behavior before proposing a patch. For a refactor, name the interface and invariants that must remain intact. A useful response contains the revised code, why the change addresses the observed problem, and the cases needed to check the result. Feed actual results back into a tool-connected workflow so the next step is based on the changed state rather than on the earlier proposal.\n\nFor performance work, supply a workload, a baseline and measurements such as timings, profiles or allocation records. Z.ai describes training tasks involving bottleneck diagnosis, optimization, experiments and correctness-preserving results. A practical request is: “Use this profile to identify the most consequential bottleneck, propose one measurable change, and explain what result would justify keeping it.” Distinguish a hypothesis about performance from a recorded improvement. Preserve the same workload and relevant conditions when inspecting a result.\n\nThe release also develops vulnerability-analysis capability. For defensive source review, provide the relevant code, its intended trust boundaries and the conditions under which it runs. Ask for a finding that connects a suspected issue to the affected input, behavior and a focused remediation. Separate a potential weakness from a reproduced fault, and retain the observation used to validate it. A report is more useful when it prioritizes concrete evidence and proposed corrections rather than treating every suspicious pattern as a confirmed vulnerability.\n\nFunction calling lets a surrounding application expose external operations to the model. Define each tool’s purpose, arguments and expected result, then return the actual tool observation for the next step. The model can reason over that result and decide how it changes the task. Keep proposed actions, executed operations and unresolved checks distinguishable. The maker also documents streaming responses, which return reasoning and answer fragments separately; assemble the completed answer before treating it as the final report or code explanation.\n\nThe local model card provides a specific history-setting detail: its chat template keeps thinking by default, while the maker recommends explicitly clearing old thinking for ordinary chat scenarios. Apply the appropriate conversation structure for the use case, preserving the actual completed answers and tool results needed for continuation. Avoid treating reasoning-control settings from GLM 5.2 or the separate GLM 5.3 Flash editions as interchangeable with this model’s low/high/max controls.\n\nFor structured results, specify the expected fields, types and source rules. A useful artifact might be a defect table, a change plan or a JSON object summarizing observations. Validate both the structure and the values before an application uses them. The final result should identify the answer or revised artifact, the evidence supporting it and the remaining assumptions. More reasoning effort does not establish that a tool ran, that a proposed patch passed its checks, or that a factual claim has support beyond the supplied material.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "f038d64d8ca9f80d4ab0c5a9418dc943ac19deb86e2e38f64db989a593e4090e", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "z-ai/glm-5.3:batchZ.ai GLM 5.3 is a text reasoning model for complex software engineering, terminal work and long-horizon agents. It supports a maker-documented 1M-token context, up to 128K output tokens, function calling and low/high/max reasoning effort, with reasoning enabled throughout.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Z.ai GLM 5.3 is a large-scale text reasoning model designed for complex software engineering and long-horizon agent work. The manufacturer states that it uses the same base model as GLM 5.2, with the new gains coming from post-training. The release focuses on stronger programming, terminal operations and broader tasks that involve several dependent steps. It accepts text and produces text, including code, explanations, plans and tool-call requests in a tool-connected application.
The documented reasoning mode is always enabled. GLM 5.3 offers three effort levels: low, high and max, with max as the default. The maker recommends max for complex coding work; low provides a lighter reasoning option for simpler steps. Use the selected level together with a clear final deliverable and completion criteria. For example: “Inspect these files and failing results, trace the cause across the affected modules, propose a correction that preserves the public interface, and explain which checks establish that the regression is resolved.”
The maker specifies a 1M-token context window and a maximum output length of 128K tokens. Organize long material around the relationship the model needs to investigate. Preserve file names, relevant definitions, source labels and the order of observations, and leave room for the reasoning and final answer within the applicable working context. A large window is useful for cross-module dependencies or a long sequence of agent observations; it does not make an undirected archive of unrelated material a well-defined task.
For repository work, provide the expected behavior, relevant source text, dependency versions and actual error output. Ask the model to identify the affected behavior before proposing a patch. For a refactor, name the interface and invariants that must remain intact. A useful response contains the revised code, why the change addresses the observed problem, and the cases needed to check the result. Feed actual results back into a tool-connected workflow so the next step is based on the changed state rather than on the earlier proposal.
For performance work, supply a workload, a baseline and measurements such as timings, profiles or allocation records. Z.ai describes training tasks involving bottleneck diagnosis, optimization, experiments and correctness-preserving results. A practical request is: “Use this profile to identify the most consequential bottleneck, propose one measurable change, and explain what result would justify keeping it.” Distinguish a hypothesis about performance from a recorded improvement. Preserve the same workload and relevant conditions when inspecting a result.
The release also develops vulnerability-analysis capability. For defensive source review, provide the relevant code, its intended trust boundaries and the conditions under which it runs. Ask for a finding that connects a suspected issue to the affected input, behavior and a focused remediation. Separate a potential weakness from a reproduced fault, and retain the observation used to validate it. A report is more useful when it prioritizes concrete evidence and proposed corrections rather than treating every suspicious pattern as a confirmed vulnerability.
Function calling lets a surrounding application expose external operations to the model. Define each tool’s purpose, arguments and expected result, then return the actual tool observation for the next step. The model can reason over that result and decide how it changes the task. Keep proposed actions, executed operations and unresolved checks distinguishable. The maker also documents streaming responses, which return reasoning and answer fragments separately; assemble the completed answer before treating it as the final report or code explanation.
The local model card provides a specific history-setting detail: its chat template keeps thinking by default, while the maker recommends explicitly clearing old thinking for ordinary chat scenarios. Apply the appropriate conversation structure for the use case, preserving the actual completed answers and tool results needed for continuation. Avoid treating reasoning-control settings from GLM 5.2 or the separate GLM 5.3 Flash editions as interchangeable with this model’s low/high/max controls.
For structured results, specify the expected fields, types and source rules. A useful artifact might be a defect table, a change plan or a JSON object summarizing observations. Validate both the structure and the values before an application uses them. The final result should identify the answer or revised artifact, the evidence supporting it and the remaining assumptions. More reasoning effort does not establish that a tool ran, that a proposed patch passed its checks, or that a factual claim has support beyond the supplied material.
POST /v1/batchestexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldendpoint | Typestring | RequirementRequired | Values & limits /v1/chat/completions | Default— |
Fieldmodel | Typestring | RequirementRequired | Values & limits z-ai/glm-5.3:batch | Default— |
Fieldrequests | Typebatch_item[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldrequests[].custom_id | Typestring | RequirementRequired | Values & limits | Default— |
Fieldrequests[].body.messages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldcompletion_window | Typestring | RequirementOptional | Values & limits 24h | Default— |
Fieldprovider | Typeobject|null | RequirementOptional | Values & limits | Default— |
Fieldrequests[].body.model | Typestring | RequirementOptional | Values & limits z-ai/glm-5.3:batch, z-ai/glm-5.3 | Default— |
Fieldprovider.only | Typestring[] | RequirementOptional | Values & limits deepinfra/fp4 | Default— |
Fieldprovider.allow_fallbacks | Typeboolean|null | RequirementOptional | Values & limits false, null | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractendpoint, model, requests |
Parametermaterial_types | Contracttext |
Parameterrepresentation | Contractinline requests[]; each item has custom_id and body |
Parameterrequest_endpoint_profile | Contract/v1/chat/completions |
Parameterfile_material | ContractCaller may read actual UTF-8 JSONL locally into requests[]. No upload purpose, input_file_id or file reference is used. Missing/empty customer material stops preparation before POST. |
Parameterserialization_order | Contractendpoint, model, provider (if supplied), completion_window (if supplied), requests last |
Parameteroptional_controls | Contractprovider.only, provider.allow_fallbacks, completion_window |
Parameterschema_scope | ContractText Chat Completions bodies in the documented inline Batch envelope. |
Lifecycle: asynchronous
GET /v1/batches/{operation_id} · actual original create response.id; same user/key/group
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0009 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.0002 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.0009 / 1K tokens Output · Output tokens $0.004 / 1K tokens Input · Cache read $0.0002 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json\nfrom pathlib import Path\nbody=json.loads('{"endpoint":"/v1/chat/completions","model":"z-ai/glm-5.3:batch","requests":[{"custom_id":"req-0001","body":{"messages":[{"role":"user","content":"Hello!"}],"max_tokens":16}}]}')\nPath("batch-request.json").write_text(json.dumps(body,ensure_ascii=False),encoding="utf-8")\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/batches \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @batch-request.json -D batch-response-headers.txt -o batch-create-response.json\nimport json, os\nfrom pathlib import Path\nfrom urllib.request import Request, urlopen\n\ndef prepare_requests(customer_path):\n path = Path(customer_path)\n if not path.is_file(): raise ValueError("Customer JSONL file is missing")\n items = [json.loads(line) for line in path.read_text(encoding="utf-8").splitlines() if line.strip()]\n if not items: raise ValueError("Customer JSONL contains no requests")\n ids = set()\n for item in items:\n if set(item) != {"custom_id", "body"}: raise ValueError("Each item needs custom_id and body")\n cid = item["custom_id"]\n if not isinstance(cid, str) or not cid.strip() or cid in ids: raise ValueError("custom_id must be nonempty and unique")\n ids.add(cid)\n if not isinstance(item["body"], dict) or not item["body"].get("messages"): raise ValueError("Supply actual text messages")\n supplied_model = item["body"].get("model")\n if supplied_model is not None and supplied_model not in ['z-ai/glm-5.3:batch', 'z-ai/glm-5.3']: raise ValueError("body.model must be an exact documented caller or wire ID")\n return {"endpoint":"/v1/chat/completions", "model":"z-ai/glm-5.3:batch", "requests":items}\n\nif __name__ == "__main__":\n material = os.environ.get("AILOOT_BATCH_REQUESTS_JSONL", "")\n if not material: raise SystemExit("Set AILOOT_BATCH_REQUESTS_JSONL to your actual customer file")\n body = prepare_requests(material)\n key = os.environ.get("AILOOT_API_KEY", "")\n if not key: raise SystemExit("Set AILOOT_API_KEY")\n request = Request("https://api.ailoot.ai/v1/batches", data=json.dumps(body, ensure_ascii=False).encode("utf-8"), headers={"Authorization":"Bearer " + key, "Content-Type":"application/json"}, method="POST")\n with urlopen(request) as response:\n raw = response.read()\n Path("batch-create-response.json").write_bytes(raw)\n print(raw.decode("utf-8"))\nimport json\nfrom pathlib import Path\nraw = Path("batch-status-response.json").read_bytes()\nresponse = json.loads(raw)\nif response.get("status") != "completed":\n raise SystemExit("Keep the original operation; read its status without resubmitting")\nresults = response.get("results")\nif not isinstance(results, list) or not results:\n raise SystemExit("Preserve the original response; completed results are missing")\nPath("batch-results.jsonl").write_text("".join(json.dumps(item, ensure_ascii=False) + "\\n" for item in results), encoding="utf-8")\n# Preserve batch-status-response.json with aggregate usage and every result/error.\ninline results[].response.body JSON
GET /v1/batches/{operation_id}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nBATCH_OPERATION_ID="$(python3 - <<'PY_ID'\nimport json\nfrom pathlib import Path\nfrom urllib.parse import quote\nresponse = json.loads(Path("batch-create-response.json").read_text(encoding="utf-8"))\noperation = response.get("id")\nif not isinstance(operation, str) or not operation: raise SystemExit("No actual original operation ID; preserve the response and do not resubmit")\nprint(quote(operation, safe=""))\nPY_ID\n)"\ncurl --fail-with-body --silent --show-error "https://api.ailoot.ai/v1/batches/$BATCH_OPERATION_ID" \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -o batch-status-response.json\nKeep every complete returned response, file and content part.
Preserve the full original status JSON, every result/custom_id and complete response or error body. Save completed results[] as JSONL without filtering.
Preserve the original operation ID. 503 result_pending_check has X-Should-Retry:false; never resubmit an unknown original batch.
| Field | Type |
|---|---|
Fieldresults[].custom_id | Typestring |
Fieldresults[].response.body.choices[].message.content | Typestring|null |
Fieldresults[].error | Typeobject|null |
Fieldusage | Typeobject|null |
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldendpoint | Typestring |
Fieldstatus | Typestring |
Fieldrequest_counts | Typeobject |
Fieldresults[].id | Typestring |
Fieldresults[].response.status_code | Typeinteger |
Fieldresults[].response.request_id | Typestring |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid documented inline envelope, duplicate keys, item identity, or configured model capabilities conflict. | Next stepCorrect the indicated fields before any new submission. |
Response401 · authentication_error | ConditionInvalid API key. | Next stepUse the authorized Ailoot key. |
Response403 · permission_error | ConditionBatch group unavailable. | Next stepCheck key/group entitlement. |
Response422 · invalid_request_error | ConditionBatch uses balance billing; subscription creation is rejected. | Next stepUse the authorized balance-billed group. |
Response422 · price_unavailable | ConditionBatch input cannot be quoted. | Next stepPreserve response; use documented family input. |
Response402 · billing_error | ConditionBatch reserve unavailable. | Next stepResolve admission before a new request. |
Response503 · price_unavailable | ConditionBatch method price/native rates unavailable. | Next stepPreserve response; do not substitute prices. |
Response503 · api_error | ConditionExact supplier route unavailable. | Next stepPreserve response for route repair. |
Response503 · result_pending_check | ConditionOriginal result requires checking; X-Should-Retry:false. | Next stepKeep original operation_id/id and read its status; never repeat original POST. |
Response404 · not_found | ConditionBatch status operation absent or owned by another identity. | Next stepUse exact original id and same user/key/group. |
Ailoot Ultra z-ai/glm-5.3:batch
Use the method paths shown above.