GLM-4-9B-Chat is the dialogue-aligned edition of Z.ai’s open GLM-4-9B language model. Its preparation combines a multilingual foundation with alignment to human preferences. The model works with text: questions, documents, code and conversation history become the input, and the visible result is text or a requested tool action. Its stated areas include language understanding, mathematics, reasoning, programming and knowledge-based questions.
The GLM-4 report describes the 9B model as pre-trained on approximately ten trillion tokens of multilingual material, initially with an 8K context, and then post-trained with the pipeline and data used for GLM-4-0520. The initial training length is not the context limit of this Chat release: its published user-facing window is 128K. This distinction matters when choosing between a training specification and the named model’s actual profile.
A useful coding task is to supply a function, its intended behavior and a failing input, then ask for an explanation followed by a corrected fragment. For a document assistant, provide the relevant sections and ask it to extract requirements, compare passages or explain an unfamiliar term. These are applications of the model’s language and coding capabilities, rather than a separate product or file-generation mode.
This Chat edition supports a 128K-token context. The capacity lets an assistant carry source material and earlier dialogue into the same task. Give long documents clear section names and state whether the answer should be a summary, a comparison or an explanation of a particular passage. In follow-up messages, identify the passage being changed instead of silently replacing the task.
GLM-4-9B-Chat-1M is a separately named long-context edition. The ordinary Chat entry does not acquire its million-token window. Likewise, the visual GLM-4V-9B is a separate model: this edition’s input remains text. The published generation examples use request-specific length settings; they do not establish a single universal maximum response length.
The model supports 26 languages, with Japanese, Korean and German among the named examples. The GLM-4 training report describes Chinese and English as the principal alignment languages, alongside a broader multilingual corpus. For translation or support dialogue, specify the target language, terminology and tone, and provide the material that should remain unchanged. For instance, an assistant can explain a passage in the requested language while preserving product names and code identifiers.
GLM-4-9B-Chat is prepared for web browsing, code execution and custom function calls. The GLM-4 all-tools approach links task planning to external actions and their returned observations. A document assistant can request a lookup, use the returned excerpt and continue its explanation; a numerical task can use a Python tool supplied by the surrounding application.
The application defines and executes these tools. The model’s text does not by itself browse a site, run a program or create an image. If the application supplies an image-generation function, that external function produces the image; this text model plans the call and discusses the returned result. Give each function a clear purpose and argument definition, and feed the result back into the dialogue before requesting the final answer.
The edition uses a role-based chat template. Preserve the user’s instructions, the relevant assistant replies and tool results as distinct turns. A practical request is: “Using these named document sections, list the requirements, explain contradictions and quote the section labels that support each conclusion.” Another is: “Explain how this function processes the supplied input, then propose a change that preserves the listed interface.” The requested deliverable should be explicit, so the response can be checked against the source material and the program’s intended behavior.
", "aboutText": "### Model introduction\n\nGLM-4-9B-Chat is the dialogue-aligned edition of Z.ai’s open GLM-4-9B language model. Its preparation combines a multilingual foundation with alignment to human preferences. The model works with text: questions, documents, code and conversation history become the input, and the visible result is text or a requested tool action. Its stated areas include language understanding, mathematics, reasoning, programming and knowledge-based questions.\n\nThe GLM-4 report describes the 9B model as pre-trained on approximately ten trillion tokens of multilingual material, initially with an 8K context, and then post-trained with the pipeline and data used for GLM-4-0520. The initial training length is not the context limit of this Chat release: its published user-facing window is 128K. This distinction matters when choosing between a training specification and the named model’s actual profile.\n\nA useful coding task is to supply a function, its intended behavior and a failing input, then ask for an explanation followed by a corrected fragment. For a document assistant, provide the relevant sections and ask it to extract requirements, compare passages or explain an unfamiliar term. These are applications of the model’s language and coding capabilities, rather than a separate product or file-generation mode.\n\n### Long context\n\nThis Chat edition supports a 128K-token context. The capacity lets an assistant carry source material and earlier dialogue into the same task. Give long documents clear section names and state whether the answer should be a summary, a comparison or an explanation of a particular passage. In follow-up messages, identify the passage being changed instead of silently replacing the task.\n\nGLM-4-9B-Chat-1M is a separately named long-context edition. The ordinary Chat entry does not acquire its million-token window. Likewise, the visual GLM-4V-9B is a separate model: this edition’s input remains text. The published generation examples use request-specific length settings; they do not establish a single universal maximum response length.\n\n### Multilingual work\n\nThe model supports 26 languages, with Japanese, Korean and German among the named examples. The GLM-4 training report describes Chinese and English as the principal alignment languages, alongside a broader multilingual corpus. For translation or support dialogue, specify the target language, terminology and tone, and provide the material that should remain unchanged. For instance, an assistant can explain a passage in the requested language while preserving product names and code identifiers.\n\n### Function calls and application tools\n\nGLM-4-9B-Chat is prepared for web browsing, code execution and custom function calls. The GLM-4 all-tools approach links task planning to external actions and their returned observations. A document assistant can request a lookup, use the returned excerpt and continue its explanation; a numerical task can use a Python tool supplied by the surrounding application.\n\nThe application defines and executes these tools. The model’s text does not by itself browse a site, run a program or create an image. If the application supplies an image-generation function, that external function produces the image; this text model plans the call and discusses the returned result. Give each function a clear purpose and argument definition, and feed the result back into the dialogue before requesting the final answer.\n\n### Preparing a conversation\n\nThe edition uses a role-based chat template. Preserve the user’s instructions, the relevant assistant replies and tool results as distinct turns. A practical request is: “Using these named document sections, list the requirements, explain contradictions and quote the section labels that support each conclusion.” Another is: “Explain how this function processes the supplied input, then propose a change that preserves the listed interface.” The requested deliverable should be explicit, so the response can be checked against the source material and the program’s intended behavior.", "editorialOverlay": { "copy_fields": { "practical_html": "Technical example in English
Explain a conditional leave procedure\n\nExplain this procedure to a colleague. Section L1: 'Submit a leave request to the team lead.' L2: 'Trips over five working days also require department approval.' L3: 'A calendar invitation is sent only after approval.' The colleague requests eight working days. Return the required sequence and identify why an invitation alone does not demonstrate approval.A section-linked sequence and a short explanation of the invitation condition.The eight-day request must retain both the team-lead and department requirements.Pro/THUDM/glm-4-9b-chatGLM-4-9B-Chat is a multilingual text model for sustained dialogue, document analysis and coding, with a 128K context. It can select browser, code-execution and custom-function actions supplied by an application, then use their results in its reply.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
GLM-4-9B-Chat is the dialogue-aligned edition of Z.ai’s open GLM-4-9B language model. Its preparation combines a multilingual foundation with alignment to human preferences. The model works with text: questions, documents, code and conversation history become the input, and the visible result is text or a requested tool action. Its stated areas include language understanding, mathematics, reasoning, programming and knowledge-based questions.
The GLM-4 report describes the 9B model as pre-trained on approximately ten trillion tokens of multilingual material, initially with an 8K context, and then post-trained with the pipeline and data used for GLM-4-0520. The initial training length is not the context limit of this Chat release: its published user-facing window is 128K. This distinction matters when choosing between a training specification and the named model’s actual profile.
A useful coding task is to supply a function, its intended behavior and a failing input, then ask for an explanation followed by a corrected fragment. For a document assistant, provide the relevant sections and ask it to extract requirements, compare passages or explain an unfamiliar term. These are applications of the model’s language and coding capabilities, rather than a separate product or file-generation mode.
This Chat edition supports a 128K-token context. The capacity lets an assistant carry source material and earlier dialogue into the same task. Give long documents clear section names and state whether the answer should be a summary, a comparison or an explanation of a particular passage. In follow-up messages, identify the passage being changed instead of silently replacing the task.
GLM-4-9B-Chat-1M is a separately named long-context edition. The ordinary Chat entry does not acquire its million-token window. Likewise, the visual GLM-4V-9B is a separate model: this edition’s input remains text. The published generation examples use request-specific length settings; they do not establish a single universal maximum response length.
The model supports 26 languages, with Japanese, Korean and German among the named examples. The GLM-4 training report describes Chinese and English as the principal alignment languages, alongside a broader multilingual corpus. For translation or support dialogue, specify the target language, terminology and tone, and provide the material that should remain unchanged. For instance, an assistant can explain a passage in the requested language while preserving product names and code identifiers.
GLM-4-9B-Chat is prepared for web browsing, code execution and custom function calls. The GLM-4 all-tools approach links task planning to external actions and their returned observations. A document assistant can request a lookup, use the returned excerpt and continue its explanation; a numerical task can use a Python tool supplied by the surrounding application.
The application defines and executes these tools. The model’s text does not by itself browse a site, run a program or create an image. If the application supplies an image-generation function, that external function produces the image; this text model plans the call and discusses the returned result. Give each function a clear purpose and argument definition, and feed the result back into the dialogue before requesting the final answer.
The edition uses a role-based chat template. Preserve the user’s instructions, the relevant assistant replies and tool results as distinct turns. A practical request is: “Using these named document sections, list the requirements, explain contradictions and quote the section labels that support each conclusion.” Another is: “Explain how this function processes the supplied input, then propose a change that preserves the listed interface.” The requested deliverable should be explicit, so the response can be checked against the source material and the program’s intended behavior.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits Pro/THUDM/glm-4-9b-chat | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits Examples: system, user, assistant, tool, function Conditions: These roles are explicitly represented by Source compatibility types; the exact model role set remains model-specific. Model-specific | Default— |
Fieldmessages[].content | Typestring|content_part[]|null | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_calls | Typetool_call[] | RequirementOptional | Values & limits | Default— |
Fieldmessages[].tool_call_id | Typestring | RequirementOptional | Values & limits Applies when: role=tool; use actual returned ID | Default— |
Fieldmessages[].name | Typestring | RequirementOptional | Values & limits | Default— |
Fieldmessages[].reasoning_content | Typestring | RequirementOptional | Values & limits Applies when: Round-trip actual returned reasoning where this model uses it | Default— |
Fieldmessages[].reasoning_details | Typeobject|array | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmax_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldmax_completion_tokens | Typeinteger | RequirementOptional | Values & limits Minimum: 1 Model-specific | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Fieldstream_options.include_usage | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtemperature | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtop_p | Typenumber | RequirementOptional | Values & limits Model-specific | Default— |
Fieldstop | Typestring|string[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools | Typefunction_tool[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldtools[].type | Typestring | RequirementOptional | Values & limits function Model-specific | Default— |
Fieldtools[].function.name | Typestring | RequirementRequired | Values & limits Applies when: function tool supplied | Default— |
Fieldtools[].function.description | Typestring | RequirementOptional | Values & limits | Default— |
Fieldtools[].function.parameters | TypeJSON_schema | RequirementOptional | Values & limits | Default— |
Fieldtool_choice | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldparallel_tool_calls | Typeboolean | RequirementOptional | Values & limits Model-specific | Default— |
Fieldresponse_format | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning_effort | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldreasoning | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldservice_tier | Typestring | RequirementOptional | Values & limits Model-specific | Default— |
Fieldinstructions | Typestring | RequirementOptional | Values & limits Compatibility field | Default— |
Fieldfunctions | Typefunction[] | RequirementOptional | Values & limits Model-specific | Default— |
Fieldfunction_call | Typestring|object | RequirementOptional | Values & limits Model-specific | Default— |
Fieldprompt_cache_options | Typeobject | RequirementOptional | Values & limits Model-specific | Default— |
Fieldmodalities | Typestring[] | RequirementOptional | Values & limits text | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options is rejected on this Ultra text route | Default— |
Fieldcache_control.ttl | Typestring | RequirementOptional | Values & limits Conditions: 1h is rejected in actual prompt-cache locations | Default— |
Text · UTF8 text
messages[].content
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages |
Parametermaterial_types | Contracttext |
Parametermessages | Contractmessage array with role/content shape |
Parameterfile_material | Contractactual UTF-8 document inserted as literal text; no file ID inferred |
Parameteroptional_controls | Contractstream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parametercontrol_scope | Contractmodel-specific; user function tools differ from hosted tools |
Parameteroutput_modalities | Contracttext |
Parameterhosted_operations | Contractfalse |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous_or_streamed
Send exact model ID with messages.
Context length is not an output cap.
A text file may supply literal text; image/audio/file-object inputs need exact binding.
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.000172 / 1K tokens Output · Output tokens $0.000172 / 1K tokens Input · Cache read $0 / 1K tokens Input · Cache write $0 / 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,os\nfrom pathlib import Path\np=json.loads('{"model": "Pro/THUDM/glm-4-9b-chat", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='Pro/THUDM/glm-4-9b-chat',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='Pro/THUDM/glm-4-9b-chat',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson or SSE
Keep every complete returned response, file and content part.
Keep every choice and its content/tool calls/reasoning. In SSE assemble deltas by choice/tool index, retain the final finish reason and usage.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldchoices[].index | Typeinteger |
Fieldchoices[].message.content | Typestring|null |
Fieldchoices[].message.tool_calls | Typetool_call[] |
Fieldchoices[].message.reasoning_content | Typestring |
Fieldchoices[].message.reasoning_details | Typeobject|array |
Fieldchoices[].finish_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra Pro/THUDM/glm-4-9b-chat
Use the method paths shown above.
Pro/THUDM/glm-4-9b-chatGLM-4-9B-Chat is a multilingual text model for sustained dialogue, document analysis and coding, with a 128K context. It can select browser, code-execution and custom-function actions supplied by an application, then use their results in its reply.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
GLM-4-9B-Chat is the dialogue-aligned edition of Z.ai’s open GLM-4-9B language model. Its preparation combines a multilingual foundation with alignment to human preferences. The model works with text: questions, documents, code and conversation history become the input, and the visible result is text or a requested tool action. Its stated areas include language understanding, mathematics, reasoning, programming and knowledge-based questions.
The GLM-4 report describes the 9B model as pre-trained on approximately ten trillion tokens of multilingual material, initially with an 8K context, and then post-trained with the pipeline and data used for GLM-4-0520. The initial training length is not the context limit of this Chat release: its published user-facing window is 128K. This distinction matters when choosing between a training specification and the named model’s actual profile.
A useful coding task is to supply a function, its intended behavior and a failing input, then ask for an explanation followed by a corrected fragment. For a document assistant, provide the relevant sections and ask it to extract requirements, compare passages or explain an unfamiliar term. These are applications of the model’s language and coding capabilities, rather than a separate product or file-generation mode.
This Chat edition supports a 128K-token context. The capacity lets an assistant carry source material and earlier dialogue into the same task. Give long documents clear section names and state whether the answer should be a summary, a comparison or an explanation of a particular passage. In follow-up messages, identify the passage being changed instead of silently replacing the task.
GLM-4-9B-Chat-1M is a separately named long-context edition. The ordinary Chat entry does not acquire its million-token window. Likewise, the visual GLM-4V-9B is a separate model: this edition’s input remains text. The published generation examples use request-specific length settings; they do not establish a single universal maximum response length.
The model supports 26 languages, with Japanese, Korean and German among the named examples. The GLM-4 training report describes Chinese and English as the principal alignment languages, alongside a broader multilingual corpus. For translation or support dialogue, specify the target language, terminology and tone, and provide the material that should remain unchanged. For instance, an assistant can explain a passage in the requested language while preserving product names and code identifiers.
GLM-4-9B-Chat is prepared for web browsing, code execution and custom function calls. The GLM-4 all-tools approach links task planning to external actions and their returned observations. A document assistant can request a lookup, use the returned excerpt and continue its explanation; a numerical task can use a Python tool supplied by the surrounding application.
The application defines and executes these tools. The model’s text does not by itself browse a site, run a program or create an image. If the application supplies an image-generation function, that external function produces the image; this text model plans the call and discusses the returned result. Give each function a clear purpose and argument definition, and feed the result back into the dialogue before requesting the final answer.
The edition uses a role-based chat template. Preserve the user’s instructions, the relevant assistant replies and tool results as distinct turns. A practical request is: “Using these named document sections, list the requirements, explain contradictions and quote the section labels that support each conclusion.” Another is: “Explain how this function processes the supplied input, then propose a change that preserves the listed interface.” The requested deliverable should be explicit, so the response can be checked against the source material and the program’s intended behavior.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits Pro/THUDM/glm-4-9b-chat | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits user, assistant | Default— |
Fieldmessages[].content | Typestring | RequirementRequired | Values & limits | Default— |
Fieldmax_tokens | Typeinteger | RequirementRequired | Values & limits | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
Text · UTF-8 text
messages[].content string
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, messages, max_tokens |
Parameteroptional_controls | Contractstream |
Parametermaterial_types | Contracttext |
Parametertext_file_material | ContractRead the actual UTF-8 document and put its text in the indicated input or message content string. |
Lifecycle: synchronous_or_streamed
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.000172 / 1K tokens Output · Output tokens $0.000172 / 1K tokens Input · Cache read $0 / 1K tokens Input · Cache write $0 / 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 →
{\n "model": "Pro/THUDM/glm-4-9b-chat",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'Pro/THUDM/glm-4-9b-chat', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'Pro/THUDM/glm-4-9b-chat', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON or SSE
Keep every complete returned response, file and content part.
Keep all content blocks, thinking signatures and actual tool-use IDs. Assemble all SSE block deltas; a first text block is not the complete output.
Keep request/response IDs and headers. No generic text job retrieval URL is supplied.
| Field | Type |
|---|---|
Fieldid | Typestring |
Fieldmodel | Typestring |
Fieldcontent[] | Typetext|thinking|tool_use|other content block |
Fieldstop_reason | Typestring|null |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra Pro/THUDM/glm-4-9b-chat
Use the method paths shown above.
Technical example in English
Explain a conditional leave procedure\n\nExplain this procedure to a colleague. Section L1: 'Submit a leave request to the team lead.' L2: 'Trips over five working days also require department approval.' L3: 'A calendar invitation is sent only after approval.' The colleague requests eight working days. Return the required sequence and identify why an invitation alone does not demonstrate approval.A section-linked sequence and a short explanation of the invitation condition.The eight-day request must retain both the team-lead and department requirements.