GLM-5.3 實戰指南：常駐思考、三種推理強度與 API 支援矩陣

標題：GLM-5.3 實戰指南：常駐思考、三種推理強度與 API 支援矩陣

說明：2026 年 8 月 GLM-5.3 指南：常駐思考搭配三種 reasoning_effort 推理強度、推理摘要、平行工具呼叫、結構化輸出與自動快取，並提供經驗證的 AIHubMix Chat / Responses / Messages 範例。

本文涵蓋 GLM-5.3 的重要 API 變更與使用須知。GLM-5.3 是 Z.ai 於 2026-08-14 推出的旗艦模型，採用與 GLM-5.2 完全相同的基礎模型，所有效能提升皆來自後訓練。在 AIHubMix 上，模型 ID 為 coding-glm-5.3（目前為限時預覽路由），可透過 Chat Completions、Responses 和 Claude 相容的 Messages API 使用。另請參閱：Z.ai 官方發布部落格。

各節中的「已驗證」結論與範例回應，均來自 2026-08-14 透過 AIHubMix API（Chat Completions / Responses / Messages）實際發出的呼叫。

1. 模型規格一覽

已驗證：max_tokens: 999999 會回傳 400，錯誤內容會明確列出有效範圍，表示上限確實會經過驗證，而非遭到靜默截斷。

# max_tokens=999999 -> HTTP 400
"max_tokens parameter invalid: value must be within [1,131072]"

2. GLM-5.3 與 GLM-5.2 比較：常駐思考，透過 reasoning_effort 調整強度

相較於 GLM-5.2，GLM-5.3 有兩項最重要的 API 變更：

1. thinking.type 不再支援 disabled — 無法關閉思考。官方遷移建議：過去會傳送 {"type": "disabled"} 的應用程式，應改為傳送 {"type": "enabled"}，並將 reasoning_effort 設為 "low"。
2. reasoning_effort 縮減為三種強度：low（輕度）/ high（增強）/ max（深度，預設值）。GLM-5.2 時期的 7 種值相容性對應不再適用；Z.ai 建議在程式設計任務中使用 max。

已驗證：透過 AIHubMix 傳送 thinking: {"type": "disabled"} 會回傳 200，而且仍然會進行思考（照常回傳 reasoning_content） — 此值會依照官方通道語意自動轉換，而不是遭到拒絕。如果用戶端仰賴「關閉思考以節省 token」，請改用 reasoning_effort: "low"。

已驗證：reasoning_effort 超出列舉範圍的值同樣會回傳 200，不會報錯（依官方文件回退至預設值 max）；在相同的算術問題中，low 相較於 max 確實呈現較輕度思考的趨勢（推理 token 為 27 個，對比 39 個）。

Chat Completions

思考內容會透過 reasoning_content 欄位回傳；串流模式下則會以 delta.reasoning_content 傳回。

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    reasoning_effort="max",          # low / high / max, default max
    extra_body={"thinking": {"type": "enabled"}},
    messages=[
        {"role": "user", "content": "Compute the square root of (17*23-19*11), rounded down. Digits only."}
    ],
)

print(completion.choices[0].message.reasoning_content)
print(completion.choices[0].message.content)   # Observed: "13"

已驗證：usage.completion_tokens_details.reasoning_tokens 會回報思考用量；同一個問題在 reasoning_effort="low" 時為 27 個，在 "max" 時為 39 個。

Responses

思考內容會以 reasoning 輸出項目回傳，文字則位於 summary 陣列中的 summary_text。

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? City name only.",
)

# Observed response.output item types: ["reasoning", "message"]
# reasoning item: {"type": "reasoning", "summary": [{"type": "summary_text", "text": "The user is asking..."}]}
# usage.output_tokens_details.reasoning_tokens: 80

已驗證：預設請求（完全不帶 reasoning 參數）就已包含帶有 summary_text 的 reasoning 項目，不需要明確啟用。

Messages

思考內容會以原生 thinking 內容區塊回傳。

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com"
)

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? City name only."}
    ],
)

# Observed response.content block types: ["thinking", "text"]

已驗證：預設會回傳思考區塊；在此 API 上傳送 thinking: {"type": "disabled"} 同樣會回傳 200，且仍然會進行思考（符合官方通道語意：「disabled」會轉換為 low，請求仍會繼續）。

3. 工具呼叫與平行工具

已驗證三種 API 都能使用函式呼叫；在 Responses API 上，我們也觀察到同一回合中會平行呼叫多個工具（Z.ai 明確宣告 GLM-5.3 的 supports_parallel_tool_calls: true）。上游限制：tools 最多可設定 128 個函式；tool_choice 原生僅支援 auto。

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
)

# Observed: finish_reason "tool_calls", with a get_weather call in tool_calls

已驗證：tool_choice: "none" 可正常運作；同一個天氣問題會回傳純文字，不會呼叫工具。

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="Check today's weather in Shanghai and Beijing",
    parallel_tool_calls=True,
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed: a single turn returns 2 parallel function_call output items (one for each city)

已驗證：單一回合中平行呼叫 2 個工具，符合官方宣告的 supports_parallel_tool_calls: true。

Messages

response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    messages=[{"role": "user", "content": "What's the weather in Beijing today?"}],
)

# Observed: stop_reason "tool_use"; content contains a tool_use block

❗ 已驗證：在此 API 上，即使設定 tool_choice: {"type": "none"}，模型仍會產生工具呼叫。若要停用工具，請完全移除 tools 參數，或改在 Chat Completions API 上使用 tool_choice: "none"。

4. 結構化輸出

response_format 支援 text 和 json_object；上游未列出 json_schema 模式。若需要嚴格符合結構描述，請將 JSON Schema 放入提示詞，並在用戶端驗證。

Chat Completions

completion = client.chat.completions.create(
    model="coding-glm-5.3",
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
    response_format={"type": "json_object"},
)

# Observed response content: {"answer": "Paris"}

已驗證：輸出為有效 JSON，且包含要求的索引鍵。

Responses

response = client.responses.create(
    model="coding-glm-5.3",
    input="What is the capital of France? Answer in JSON with the key \"answer\".",
    text={"format": {"type": "json_object"}},
)

# Observed output text: {"answer": "Paris"}

Messages

# Specify the JSON structure in the prompt; observed output is valid JSON
response = client.messages.create(
    model="coding-glm-5.3",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "What is the capital of France? Answer in JSON with the key \"answer\"."}
    ],
)

# Observed response text: {"answer": "Paris"}

5. 上下文快取會自動進行

預設會啟用隱式快取，不需要傳入任何參數；重複使用較長的前綴時，使用量資訊會回報快取命中（欄位名稱依 API 而異）。

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 960}

已驗證：連續兩次呼叫中，第二次命中 960 個快取 token。

Responses

# usage of the second call with an identical long prefix
"input_tokens_details": {"cached_tokens": 960}

Messages

# hits are reported via usage.cache_read_input_tokens
"cache_read_input_tokens": 0

已驗證：本輪測試未能在此 API 上重現快取命中（快取會依通道預熱；若切換負載平衡器，可能會未命中）。命中計算欄位遵循 Anthropic 語意。

6. 取樣與參數驗證

取樣設定遵循 GLM 系列端點慣例：temperature 範圍為 [0, 1]，預設值為 1.0（注意：比 OpenAI 協定的 [0, 2] 範圍更窄）；top_p 範圍為 [0.01, 1]，預設值為 0.95。Z.ai 建議只調整兩者其中之一。

已驗證：不同 API 的參數驗證方式有所差異。Messages API 會以 400 拒絕超出範圍的 temperature: 3，並明確列出有效範圍 [0,1]；而 Chat Completions / Responses 對相同的超出範圍值會靜默接受並回傳 200。遷移至其他 API 時，請勿依賴閘道替你攔截超出範圍的取樣值。

# Messages API with temperature=3 -> HTTP 400
"temperature parameter invalid: value must be within [0,1]"

7. 能力 × API 支援矩陣

下方每個儲存格都已於 2026-08-14 透過 AIHubMix 線上 API 實際呼叫驗證；各儲存格列出該 API 對應的參數／欄位名稱。

常見問題

AIHubMix 上 GLM-5.3 的模型 ID 是什麼？需要加上 [1m] 後綴嗎？
模型 ID 是 coding-glm-5.3，直接使用即可。glm-5.3[1m] 是 Z.ai 提供給 Claude Code 用戶端的模型名稱語法，與 AIHubMix 呼叫無關；三種 API 都不需要加上任何後綴。

可以關閉思考嗎？
不行。GLM-5.3 一律會進行思考，且 thinking.type 只支援 enabled；我們的測試中，傳送 disabled 會回傳 200，但思考仍會繼續（依官方語意轉換為 low 強度）。若要節省思考 token，請傳送 reasoning_effort: "low"。

GLM-5.3 與 GLM-5.2 有什麼關係？
基礎模型相同，所有提升皆來自後訓練（官方說法：「它採用與 GLM-5.2 相同的基礎模型，所有提升皆來自後訓練」）。有兩項重要的 API 變更：思考無法再停用，且 reasoning_effort 縮減為 low/high/max 三種強度（預設為 max）。

如果需要嚴格符合 json_schema 的結構化輸出，該怎麼辦？
上游未列出 response_format: json_schema 模式。我們的測試中，三種 API 在 json_object JSON 模式下都能產生有效 JSON；若需要嚴格符合結構描述，請將 JSON Schema 放入提示詞，並在用戶端驗證。

coding-glm-5.3是正式上線的版本嗎？
目前這是限時預覽路由（Z.ai 的模型 API 文件標示官方 API「即將推出」）；商用 API 上線後，AIHubMix 會立即跟進。定價與最新狀態請參閱模型頁面。

定價與即時狀態請參閱GLM-5.3 模型頁面；如需瀏覽更多模型，請前往模型庫。