hiapi API で glm-5.3 を使う方法：curl、Python、そして実行可能なリクエスト

構築するもの

hiapi の OpenAI 互換 Chat Completions API を通じて glm-5.3 を呼び出す実行可能な統合——1 回のリクエストで実際の補完結果が返り、このモデルを使う際に実際にもっとも踏みやすい落とし穴を説明します。それは、推論トークンが max_tokens の予算を消費してしまうという点です。

前提条件：hiapi API key が必要です。dashboard から取得してください——これは sk-... 文字列であり、同じ key がこのモデルに限らずアカウント内のすべての有効化済みモデルで使用できます。

以下のすべてのリクエストとレスポンスは、執筆時点で実際にオンライン API に対して実行して得られたものです。

最小限の実行可能な例

glm-5.3 は標準の Chat Completions エンドポイント上のテキストモデルです——hiapi の画像/動画/音声モデルで使われる非同期の /v1/tasks フローではありません。1 回のリクエスト、1 回のレスポンスで、ポーリングは不要です。

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-<your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Reply with exactly: OK"}
    ],
    "max_tokens": 200
  }'

レスポンス（一部抜粋）：

{
  "id": "8be5f07603f0407c90734e8b4c2f02f0",
  "object": "chat.completion",
  "model": "glm-5.3",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "OK",
        "reasoning_content": "The user wants me to reply with exactly \"OK\" ..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 17,
    "completion_tokens": 35,
    "total_tokens": 52,
    "completion_tokens_details": { "reasoning_tokens": 32 }
  }
}

同じ呼び出しを Python で、requests のみを使って行う場合：

import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/chat/completions",
    headers={"Authorization": "Bearer sk-<your-api-key>"},
    json={
        "model": "glm-5.3",
        "messages": [
            {"role": "user", "content": "Reply with exactly: OK"}
        ],
        "max_tokens": 200,
    },
    timeout=60,
)
resp.raise_for_status()
data = resp.json()
print(data["choices"][0]["message"]["content"])
print(data["usage"])

OpenAI と構造互換なので、このコードは公式の openai Python/JS SDK でも変更なしに動作します——base_url を https://api.hiapi.ai/v1 に設定し、hiapi key を渡すだけです。

本番環境でのパターン

推論トークンが低めの max_tokens 予算を食い尽くす

glm-5.3 は回答する前に必ず思考します——すべてのレスポンスは content の隣に reasoning_content フィールドを持ち、これを無効化するリクエストフラグはありません。この推論内容は可視の回答より先に max_tokens に計上されます。予算を低く設定しすぎると、モデルが全クォータを思考に費やし、回答の執筆まで到達しないため、content: null と finish_reason: "length" が返ります：

{
  "choices": [{
    "message": { "content": null, "reasoning_content": "The user has given a very simple instruction: \"" },
    "finish_reason": "length"
  }],
  "usage": { "completion_tokens": 10, "completion_tokens_details": { "reasoning_tokens": 9 } }
}

プロンプトが単純であっても余裕を持たせてください（200+ トークンが安全な下限です）。そして content を信頼する前に必ず finish_reason を確認してください——"length" は回答が切り詰められたこと、場合によっては始まる前にすでに切り詰められたことを意味します。

ストリーミング出力

"stream": true を設定し、Server-Sent Events を読み取ります。推論内容と回答テキストは独立した delta フィールドとして届きます——まず delta.reasoning_content のチャンク、次にモデルが実際の返答を始めると delta.content が届き、ストリームは最後のチャンクで finish_reason: "stop" を伴って終了します：

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-<your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [{"role": "user", "content": "Count to 3."}],
    "max_tokens": 200,
    "stream": true
  }'

data: {"choices":[{"delta":{"role":"assistant","content":"","reasoning_content":null},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":null,"reasoning_content":"The"},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":"1, ","reasoning_content":null},"finish_reason":null}]}

data: {"choices":[{"delta":{"content":"2, 3.","reasoning_content":null},"finish_reason":null}]}

data: {"choices":[{"delta":{},"finish_reason":"stop"}]}

UI にストリーミングする場合は、reasoning_content と content を連結せず、別々のパネルに振り分けてください——これらは同じテキストストリームではありません。

ツール呼び出し

関数呼び出しは標準の OpenAI 構造に従います。tools を宣言すると、モデルがツールを呼び出すと判断したときに finish_reason が "tool_calls" で返り、tool_calls 配列が埋められます（これもまず推論するため、reasoning_content も現れます）：

{
  "message": {
    "role": "assistant",
    "content": null,
    "reasoning_content": "The user wants to know the weather in Paris. I have a tool available for that. Let me call it.",
    "tool_calls": [{
      "id": "call_12e21fe488f046bc9edb4488",
      "type": "function",
      "function": { "name": "get_weather", "arguments": "{\"city\": \"Paris\"}" }
    }]
  },
  "finish_reason": "tool_calls"
}

次のターンでアシスタントの tool_calls メッセージと、role: "tool" の結果メッセージを再生します。これは他の OpenAI 互換統合と同じです。

エラー処理

無効または欠落した key は HTTP 401 を返し、一貫したエラー構造を持ちます——choices を解析する前にステータスコードを確認してください：

{
  "error": {
    "code": "permission_denied",
    "message": "This API key is invalid. Check that it is correct or use another API key and try again.",
    "type": "hiapi_error"
  }
}

関連リソース

• glm-5.3 モデルページ——機能と現在の可用性
• hiapi 価格——現在のトークン単価
• API keys ダッシュボード——key の作成と管理
• hiapi API で kimi-k3 を使う方法——hiapi 上のもう一つの Chat Completions テキストモデル
• hiapi API で deepseek-v4.1-flash を使う方法——同じ統合パターンで、モデルが異なる

よくある質問

glm-5.3 はストリーミング出力をサポートしていますか？ はい——"stream": true を設定し、SSE チャンクを読み取ります。推論内容と回答内容は独立した delta フィールドとしてストリーミングされます。

レスポンスの content が null なのはなぜですか？ ほぼ常に、max_tokens 予算が推論と回答の両方をカバーするには小さすぎるためです。finish_reason を確認してください："length" は実際の回答の前に（またはその途中で）レスポンスが切り詰められたことを意味します。max_tokens を増やしてください。

推論ステップを無効化できますか？ リクエストパラメータでは無効化できません——glm-5.3 は毎回のレスポンス前に推論し、reasoning_content は常に埋められます。無効化しようとするのではなく、そのための予算を確保してください。

glm-5.3 は関数/ツール呼び出しをサポートしていますか？ はい、標準の OpenAI tools / tool_calls 構造を使用し、オンラインエンドポイントで検証済みです。

生の HTTP ではなく公式 OpenAI SDK を使用できますか？ はい。SDK の base_url を https://api.hiapi.ai/v1 に設定し、hiapi の sk-... key を API key として使用します——他の変更は不要です。

glm-5.3 の課金はどうなりますか？ 他の hiapi テキストモデルと同様にトークン単位で課金されます。本文中の特定の数値に頼らず、価格で現在の料金を確認してください。