CodeGeeX4 is a multilingual coding-model family built around programming assistance and work across related source files. The maker publishes CodeGeeX4-ALL-9B as an open-source member of the series, developed through continued training of GLM-4-9B. Its documentation covers code generation and completion, programming questions, repository analysis and connected workflows involving a code interpreter, web search or function calls. The ordinary output is text: code, explanations, answers or file-labelled changes, according to the task instruction.
Start by choosing the operation and giving the model the code it needs. The native system-prompt guide has separate instructions for adding comments, explaining a program, translating between programming languages, reviewing or repairing code, generating tests and answering questions about a file. For a repair, include the failing code, the observed behaviour and the intended result. For translation, state the target programming language and supply the complete relevant function. For comments, the maker’s task instruction preserves the code and adds comments; for several code-producing tasks, it asks for code only. These distinctions help make the result usable as a code artifact or an explanation, rather than leaving the output format implicit.
The guides provide Chinese and English system prompts. The language of the system instruction does not by itself determine the language of the answer, so request the response language explicitly when an explanation is needed. The specialised review guidance describes Chinese output; the general programming-assistant prompt provides a separate way to ask for a review in another response language. Some task templates set the comment language to match the source and exclude mixed Chinese and English output. In a continuing conversation, repeat the relevant task instruction when switching operations so that a request for an explanation is not confused with the preceding request for code-only output.
For contextual completion, the native format describes the target file, its programming language and the code on both sides of the insertion point. Use the relative file path with ###PATH: and include ###LANGUAGE:; the guide permits an empty language value when it is unknown. ###MODE: selects LINE for a single-line completion or BLOCK for multiple lines, with BLOCK as the documented default. The fill-in-the-middle sequence is suffix first, then prefix, then the missing middle, marked with <|code_suffix|>, <|code_prefix|> and <|code_middle|>. The maker’s infilling template omits the system prompt. Keeping the suffix gives the model the surrounding control flow and the code that must remain after the insertion. The result is the proposed missing code, which can then be checked in its original location.
Cross-file completion adds related snippets as reference material, each introduced by ###REFERENCE: and its own ###PATH:. Keep these references separate from the target file and its insertion point. For example, when completing a function that calls an existing helper, provide the helper’s signature and implementation alongside the target function’s prefix and suffix. The project-level completion guide extends this approach to generating a new file from the project requirements and relevant existing code. Clear paths and selected dependencies make it possible to distinguish code supplied as evidence from the file the model is asked to complete.
Repository questions use a different native layout: list each file under ###PATH:, include its code, then ask the question. A useful brief can ask where a value is defined or how a call passes between the supplied modules. Repository editing uses its own system instruction for adding, deleting or modifying files and requests output in ###PATH: {PATH} followed by the code. Prepare the relevant files and describe the required change, including the file to add or the behaviour to preserve. Read the returned path-labelled blocks as proposed changes; they are not evidence that a repository has already been modified or that the code has run.
For the published CodeGeeX4-ALL-9B member, the maker documents a 128K context and recommends selecting relevant repository content when a project exceeds that window. Retrieval of related snippets and trimming oversized inputs are preparation steps in the repository guide. Context must accommodate the instructions, supplied code and generated continuation, so a targeted set of files is often more useful than an undifferentiated project dump. The maker’s example generation settings control the length of a particular run; they do not define a universal maximum answer length for every CodeGeeX4 edition.
The series also describes connected programming workflows with interpreters, search and function calls. Such a workflow needs the surrounding application to provide the named tools and return their results to the conversation. When asking for runnable code, state the intended language, dependencies and expected behaviour; when asking for an analysis, request the relevant file or function references. Compile or run the proposed changes in the intended environment and check the behaviour against the supplied requirement before incorporating them into a project.
", "aboutText": "CodeGeeX4 is a multilingual coding-model family built around programming assistance and work across related source files. The maker publishes CodeGeeX4-ALL-9B as an open-source member of the series, developed through continued training of GLM-4-9B. Its documentation covers code generation and completion, programming questions, repository analysis and connected workflows involving a code interpreter, web search or function calls. The ordinary output is text: code, explanations, answers or file-labelled changes, according to the task instruction.\n\nStart by choosing the operation and giving the model the code it needs. The native system-prompt guide has separate instructions for adding comments, explaining a program, translating between programming languages, reviewing or repairing code, generating tests and answering questions about a file. For a repair, include the failing code, the observed behaviour and the intended result. For translation, state the target programming language and supply the complete relevant function. For comments, the maker’s task instruction preserves the code and adds comments; for several code-producing tasks, it asks for code only. These distinctions help make the result usable as a code artifact or an explanation, rather than leaving the output format implicit.\n\nThe guides provide Chinese and English system prompts. The language of the system instruction does not by itself determine the language of the answer, so request the response language explicitly when an explanation is needed. The specialised review guidance describes Chinese output; the general programming-assistant prompt provides a separate way to ask for a review in another response language. Some task templates set the comment language to match the source and exclude mixed Chinese and English output. In a continuing conversation, repeat the relevant task instruction when switching operations so that a request for an explanation is not confused with the preceding request for code-only output.\n\nFor contextual completion, the native format describes the target file, its programming language and the code on both sides of the insertion point. Use the relative file path with ###PATH: and include ###LANGUAGE:; the guide permits an empty language value when it is unknown. ###MODE: selects LINE for a single-line completion or BLOCK for multiple lines, with BLOCK as the documented default. The fill-in-the-middle sequence is suffix first, then prefix, then the missing middle, marked with <|code_suffix|>, <|code_prefix|> and <|code_middle|>. The maker’s infilling template omits the system prompt. Keeping the suffix gives the model the surrounding control flow and the code that must remain after the insertion. The result is the proposed missing code, which can then be checked in its original location.\n\nCross-file completion adds related snippets as reference material, each introduced by ###REFERENCE: and its own ###PATH:. Keep these references separate from the target file and its insertion point. For example, when completing a function that calls an existing helper, provide the helper’s signature and implementation alongside the target function’s prefix and suffix. The project-level completion guide extends this approach to generating a new file from the project requirements and relevant existing code. Clear paths and selected dependencies make it possible to distinguish code supplied as evidence from the file the model is asked to complete.\n\nRepository questions use a different native layout: list each file under ###PATH:, include its code, then ask the question. A useful brief can ask where a value is defined or how a call passes between the supplied modules. Repository editing uses its own system instruction for adding, deleting or modifying files and requests output in ###PATH: {PATH} followed by the code. Prepare the relevant files and describe the required change, including the file to add or the behaviour to preserve. Read the returned path-labelled blocks as proposed changes; they are not evidence that a repository has already been modified or that the code has run.\n\nFor the published CodeGeeX4-ALL-9B member, the maker documents a 128K context and recommends selecting relevant repository content when a project exceeds that window. Retrieval of related snippets and trimming oversized inputs are preparation steps in the repository guide. Context must accommodate the instructions, supplied code and generated continuation, so a targeted set of files is often more useful than an undifferentiated project dump. The maker’s example generation settings control the length of a particular run; they do not define a universal maximum answer length for every CodeGeeX4 edition.\n\nThe series also describes connected programming workflows with interpreters, search and function calls. Such a workflow needs the surrounding application to provide the named tools and return their results to the conversation. When asking for runnable code, state the intended language, dependencies and expected behaviour; when asking for an analysis, request the relevant file or function references. Compile or run the proposed changes in the intended environment and check the behaviour against the supplied requirement before incorporating them into a project.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "d69a807223b5d92dc703b802e6094ba7b5400a5af554fb148cc4de88f0f9eabe", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "codegeex-4CodeGeeX4 is a multilingual coding-model family for code generation, completion, explanation, repair and repository questions. Its native guides cover task-specific prompts, filling gaps between existing code and using related files to prepare changes with explicit file paths.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
CodeGeeX4 is a multilingual coding-model family built around programming assistance and work across related source files. The maker publishes CodeGeeX4-ALL-9B as an open-source member of the series, developed through continued training of GLM-4-9B. Its documentation covers code generation and completion, programming questions, repository analysis and connected workflows involving a code interpreter, web search or function calls. The ordinary output is text: code, explanations, answers or file-labelled changes, according to the task instruction.
Start by choosing the operation and giving the model the code it needs. The native system-prompt guide has separate instructions for adding comments, explaining a program, translating between programming languages, reviewing or repairing code, generating tests and answering questions about a file. For a repair, include the failing code, the observed behaviour and the intended result. For translation, state the target programming language and supply the complete relevant function. For comments, the maker’s task instruction preserves the code and adds comments; for several code-producing tasks, it asks for code only. These distinctions help make the result usable as a code artifact or an explanation, rather than leaving the output format implicit.
The guides provide Chinese and English system prompts. The language of the system instruction does not by itself determine the language of the answer, so request the response language explicitly when an explanation is needed. The specialised review guidance describes Chinese output; the general programming-assistant prompt provides a separate way to ask for a review in another response language. Some task templates set the comment language to match the source and exclude mixed Chinese and English output. In a continuing conversation, repeat the relevant task instruction when switching operations so that a request for an explanation is not confused with the preceding request for code-only output.
For contextual completion, the native format describes the target file, its programming language and the code on both sides of the insertion point. Use the relative file path with ###PATH: and include ###LANGUAGE:; the guide permits an empty language value when it is unknown. ###MODE: selects LINE for a single-line completion or BLOCK for multiple lines, with BLOCK as the documented default. The fill-in-the-middle sequence is suffix first, then prefix, then the missing middle, marked with <|code_suffix|>, <|code_prefix|> and <|code_middle|>. The maker’s infilling template omits the system prompt. Keeping the suffix gives the model the surrounding control flow and the code that must remain after the insertion. The result is the proposed missing code, which can then be checked in its original location.
Cross-file completion adds related snippets as reference material, each introduced by ###REFERENCE: and its own ###PATH:. Keep these references separate from the target file and its insertion point. For example, when completing a function that calls an existing helper, provide the helper’s signature and implementation alongside the target function’s prefix and suffix. The project-level completion guide extends this approach to generating a new file from the project requirements and relevant existing code. Clear paths and selected dependencies make it possible to distinguish code supplied as evidence from the file the model is asked to complete.
Repository questions use a different native layout: list each file under ###PATH:, include its code, then ask the question. A useful brief can ask where a value is defined or how a call passes between the supplied modules. Repository editing uses its own system instruction for adding, deleting or modifying files and requests output in ###PATH: {PATH} followed by the code. Prepare the relevant files and describe the required change, including the file to add or the behaviour to preserve. Read the returned path-labelled blocks as proposed changes; they are not evidence that a repository has already been modified or that the code has run.
For the published CodeGeeX4-ALL-9B member, the maker documents a 128K context and recommends selecting relevant repository content when a project exceeds that window. Retrieval of related snippets and trimming oversized inputs are preparation steps in the repository guide. Context must accommodate the instructions, supplied code and generated continuation, so a targeted set of files is often more useful than an undifferentiated project dump. The maker’s example generation settings control the length of a particular run; they do not define a universal maximum answer length for every CodeGeeX4 edition.
The series also describes connected programming workflows with interpreters, search and function calls. Such a workflow needs the surrounding application to provide the named tools and return their results to the conversation. When asking for runnable code, state the intended language, dependencies and expected behaviour; when asking for an analysis, request the relevant file or function references. Compile or run the proposed changes in the intended environment and check the behaviour against the supplied requirement before incorporating them into a project.
POST /v1/chat/completionstexttext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits codegeex-4 | Default— |
Fieldmessages | Typemessage[] | RequirementRequired | Values & limits Minimum items: 1 | Default— |
Fieldmessages[].role | Typestring | RequirementRequired | Values & limits Model-specific | Default— |
Fieldmessages[].content | Typestring | RequirementOptional | Values & limits Applies when: Text conversation | Default— |
Fieldstream | Typeboolean | RequirementOptional | Values & limits | Defaultfalse |
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 |
Parametercontrol_scope | ContractText conversation; stream is a boolean and defaults to false. |
Parameteroutput_modalities | Contracttext |
Parameterhosted_operations | Contractfalse |
Parametermultimodal_input_binding | Contractnull |
Method aliases: /chat/completions
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.028 / 1K tokens Output · Output tokens $0.028 / 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":"codegeex-4","messages":[{"role":"user","content":"hello"}],"stream":false}')\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="codegeex-4", messages=[{"role":"user","content":"hello"}], stream=False)\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"))\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 codegeex-4
/chat/completions
codegeex-4CodeGeeX4 is a multilingual coding-model family for code generation, completion, explanation, repair and repository questions. Its native guides cover task-specific prompts, filling gaps between existing code and using related files to prepare changes with explicit file paths.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
CodeGeeX4 is a multilingual coding-model family built around programming assistance and work across related source files. The maker publishes CodeGeeX4-ALL-9B as an open-source member of the series, developed through continued training of GLM-4-9B. Its documentation covers code generation and completion, programming questions, repository analysis and connected workflows involving a code interpreter, web search or function calls. The ordinary output is text: code, explanations, answers or file-labelled changes, according to the task instruction.
Start by choosing the operation and giving the model the code it needs. The native system-prompt guide has separate instructions for adding comments, explaining a program, translating between programming languages, reviewing or repairing code, generating tests and answering questions about a file. For a repair, include the failing code, the observed behaviour and the intended result. For translation, state the target programming language and supply the complete relevant function. For comments, the maker’s task instruction preserves the code and adds comments; for several code-producing tasks, it asks for code only. These distinctions help make the result usable as a code artifact or an explanation, rather than leaving the output format implicit.
The guides provide Chinese and English system prompts. The language of the system instruction does not by itself determine the language of the answer, so request the response language explicitly when an explanation is needed. The specialised review guidance describes Chinese output; the general programming-assistant prompt provides a separate way to ask for a review in another response language. Some task templates set the comment language to match the source and exclude mixed Chinese and English output. In a continuing conversation, repeat the relevant task instruction when switching operations so that a request for an explanation is not confused with the preceding request for code-only output.
For contextual completion, the native format describes the target file, its programming language and the code on both sides of the insertion point. Use the relative file path with ###PATH: and include ###LANGUAGE:; the guide permits an empty language value when it is unknown. ###MODE: selects LINE for a single-line completion or BLOCK for multiple lines, with BLOCK as the documented default. The fill-in-the-middle sequence is suffix first, then prefix, then the missing middle, marked with <|code_suffix|>, <|code_prefix|> and <|code_middle|>. The maker’s infilling template omits the system prompt. Keeping the suffix gives the model the surrounding control flow and the code that must remain after the insertion. The result is the proposed missing code, which can then be checked in its original location.
Cross-file completion adds related snippets as reference material, each introduced by ###REFERENCE: and its own ###PATH:. Keep these references separate from the target file and its insertion point. For example, when completing a function that calls an existing helper, provide the helper’s signature and implementation alongside the target function’s prefix and suffix. The project-level completion guide extends this approach to generating a new file from the project requirements and relevant existing code. Clear paths and selected dependencies make it possible to distinguish code supplied as evidence from the file the model is asked to complete.
Repository questions use a different native layout: list each file under ###PATH:, include its code, then ask the question. A useful brief can ask where a value is defined or how a call passes between the supplied modules. Repository editing uses its own system instruction for adding, deleting or modifying files and requests output in ###PATH: {PATH} followed by the code. Prepare the relevant files and describe the required change, including the file to add or the behaviour to preserve. Read the returned path-labelled blocks as proposed changes; they are not evidence that a repository has already been modified or that the code has run.
For the published CodeGeeX4-ALL-9B member, the maker documents a 128K context and recommends selecting relevant repository content when a project exceeds that window. Retrieval of related snippets and trimming oversized inputs are preparation steps in the repository guide. Context must accommodate the instructions, supplied code and generated continuation, so a targeted set of files is often more useful than an undifferentiated project dump. The maker’s example generation settings control the length of a particular run; they do not define a universal maximum answer length for every CodeGeeX4 edition.
The series also describes connected programming workflows with interpreters, search and function calls. Such a workflow needs the surrounding application to provide the named tools and return their results to the conversation. When asking for runnable code, state the intended language, dependencies and expected behaviour; when asking for an analysis, request the relevant file or function references. Compile or run the proposed changes in the intended environment and check the behaviour against the supplied requirement before incorporating them into a project.
POST /v1/messagestextjson, sse| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits codegeex-4 | 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.028 / 1K tokens Output · Output tokens $0.028 / 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": "codegeex-4",\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': 'codegeex-4', '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': 'codegeex-4', '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 codegeex-4
/chat/completions