Kimi K3.1 Pro への移行：400 エラー、デフォルト max の思考、Highspeed の ID の落とし穴

Last updated at 2026-10-24Posted at 2026-10-24

この記事は AIHubMix が作成しました。内容は 2026年10月24日時点の情報です。Kimi K3.1 Pro は Kimi Code、Moonshot の API、AIHubMix で公開済みで、AIHubMix による実測も同日に行いました。「K3 のルール」と書いた項目は K3 のガイドによるもので、今回は K3.1 Pro で再確認していません。

TL;DR

Kimi K3.1 Pro のモデル ID は、Moonshot の API と AIHubMix では kimi-k3.1-pro、Kimi Code では k3.1-pro です。Moonshot は K3 と同じパラメータ制約を課しているので、K3 で動いているコードはモデル ID の変更と新しいセッションで移行できます。
Moonshot のプラットフォームでは、K2.x 向けのコードに期限があります。2026年10月31日から同プラットフォームの新規登録ユーザーは K2 シリーズを使えなくなり、12月末までにすべて提供終了の予定です（AIHubMix では10月24日時点で K2.6 と K2.7 Code が提供中で、終了日は示されていません）。
移行で 400 になる主な原因は次のとおりです。
- temperature に 1 以外を送ると 400 invalid temperature: only 1 is allowed for this model になります。AIHubMix のメイン ID で10月24日に実際に返りました。ただし AIHubMix のコーディングチャネルでは同じリクエストが通ります。
- thinking のオフ、effort の off / none / disabled、未知の値は 400 です（Kimi Code のドキュメント）。ただし AIHubMix のメイン ID では 400 にならず、thinking のオフと none は推論なしの 200 が返りました。medium は high、xhigh は max として動きます。
AIHubMix は K3.1 Pro を Chat Completions、Responses、Messages の3つのプロトコルすべてで提供しているので、Codex（Responses）も Claude Code（Messages）も kimi-k3.1-pro で使えます。
effort を省略すると max で動きます。low でも、AIHubMix のメイン ID でのスポットチェックでは、K3.1 Pro が5,561〜7,356トークン、K3 が3,013〜7,051トークン考えてから回答しました。

前提と情報源

K3.1 Pro のルールは、Moonshot の Kimi Code のモデルドキュメントとモデルパラメータリファレンスによります。後者は、K3.1 Pro の2つの ID が kimi-k3 と同じパラメータ制約を持つと書いています。K3 のルールは Moonshot の K3 ガイドと AIHubMix による7月の K3 実測によるもので、エラー文にはそれぞれ出典を書いています。

AIHubMix の API キーを AIHUBMIX_API_KEY に設定しておきます。
モデル ID は kimi-k3.1-pro で、Chat Completions、Responses、Messages のどれでも使えます。
ストリーミングに対応し、タイムアウトを分単位で設定できるクライアントを使います。スポットチェックでは、low でも K3.1 Pro の回答完了まで80〜99秒かかりました。Moonshot の API では、K3.1 Pro の出力上限はデフォルト131,072トークン、最大1,048,576トークンです。

AIHubMix の実測結果（10月24日）

AIHubMix のメイン ID とコーディングチャネルに、短いプロンプトとテスト用キーで1リクエストずつ送りました（中国標準時 01:03〜02:03）。

リクエスト	kimi-k3.1-pro、-highspeed	coding-kimi-k3.1-pro、-highspeed
Chat Completions	200、reasoning_content あり	200、reasoning_content あり
Messages	200、thinking + text	200、thinking + text
effort の low、medium、high、max、xhigh	5つとも 200	5つとも 200
temperature 0.2	400	200
残った thinking: enabled	200	200
Messages で JSON スキーマ	{"city":"Paris"}	{"city":"Paris"}
93トークンのプロンプトを再送	キャッシュなし	全量キャッシュ
7,658トークンのプロンプトを再送	7,424トークンがキャッシュ	未実施
thinking: disabled	200、推論なし	未実施
effort の off か未知の値	200、推論あり	未実施
effort の none	200、推論なし	未実施
停止シーケンス6つ	400、K3 と同じ文言	未実施
公開画像の URL	400	未実施

7,658トークンの行から下は kimi-k3.1-pro で試し、thinking のオフは Highspeed でも試しました。AIHubMix は2つの K3.1 Pro の ID を、Codex が使う Responses API でも提供しています。別途、メイン ID で速度のスポットチェック（600語の解説を求めるプロンプト1つ、reasoning_effort: "low"、ストリーミング、モデルごとに3回）も行い、関係する箇所で引用しています。ベンチマークではなく、スポットチェックです。

どの経路で Kimi を使っているか

Kimi の呼び出し方	10月24日時点の状況	変更が必要なもの
Kimi Code（サブスクリプション）	k3.1-pro が公開済み	ID を選ぶ、新しいセッション
Moonshot API、kimi-k3	kimi-k3.1-pro が公開済み	モデル ID
Moonshot API、K2.x	2026年末までに提供終了	ID、thinking、サンプリング
AIHubMix、kimi-k3	kimi-k3.1-pro が公開済み	モデル ID

Highspeed の ID は、Moonshot の API と AIHubMix では kimi-k3.1-pro-highspeed、Kimi Code では k3.1-pro-highspeed です。10月21日に確認されたクライアント設定は k3 と kimi-for-coding を k3.1 というモデルに対応づけていましたが、Kimi Code のドキュメントはいま k3 を K3、kimi-for-coding を K2.8 Preview としています。K3.1 Pro は明示的に選んでください。Kimi Code では、K3.1 Pro は Plus 以上（1M コンテキストは Pro 以上）、Highspeed は Pro 以上のプランが必要です。旧プランでは Moderato 以上で、1M コンテキストと Highspeed には Allegretto が必要です。K3 の提供終了日は発表されていません。K2 の日程は Moonshot のプラットフォームのもので、AIHubMix では10月24日時点で K2.6 と K2.7 Code が提供中、終了日は示されていません。

ハマりどころ

`invalid temperature: only 1 is allowed for this model` で 400 になる

再現リクエストです。

repro.sh

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

10月24日、2つのメイン ID はどちらも 400 invalid temperature: only 1 is allowed for this model（temperature が不正：このモデルでは 1 しか使えません）を返しました。同じ文言は、2026年10月3日に Moonshot の API の K3 で、10月21日に Kimi Code のエンドポイントの k3 で報告されています。モデルを coding-kimi-k3.1-pro に替えると、同じリクエストが 200 になります。

原因： Moonshot のパラメータリファレンスでは、K3.1 Pro は K3 の制約を引き継ぎます。temperature は 1.0、top_p は 0.95、n は 1、2つの penalty は 0 に固定で、ほかの値はエラーになります。K2.6 にも固定値があり、思考オフでは 0.6 でした。0.6 を送り続けているコードがいちばん怪しいところです。

例外が問題を隠す： コーディングチャネルでだけテストしたコードは、メイン ID や Moonshot の API に移ったときに失敗します。

フレームワークが防げない理由： 多くのフレームワークは、kimi- という接頭辞で Kimi のモデルを見分けて temperature を外します。Kimi Code の k3.1-pro と k3.1-pro-highspeed には接頭辞がなく、AIHubMix のコーディングチャネルの ID は coding- で始まります。Hermes Agent の issue は K3 でまさにこのケースでした。メインのチャット経路は temperature を送っていませんでしたが、k3 を呼ぶ補助的な呼び出しが temperature を送り続け、毎回 400 になっていました。

その補助的な呼び出しは、Hermes の「smart approval」（スマート承認）分類器でした。報告者は分類器の動きを次のように書いています。

escalates (fail-open) on every call

（呼び出しのたびにエスカレーションする（フェイルオープン：エラー時に止めずに通す動作）。）

安全チェックは機能しなくなっていましたが、メインのチャットには何もおかしな点が見えませんでした。K3.1 Pro では、速くするために思考をオフにするのも使えません。AIHubMix では推論なしの回答が返りました。安全チェックを K3.1 Pro で動かすなら、速度は reasoning_effort: "low" で稼ぎ、API エラーのときはフェイルクローズ（止める側に倒す）にしてください。

対処： どの呼び出し経路でも temperature、top_p、n、presence_penalty、frequency_penalty を一切送らないでください。判定はモデル名の接頭辞ではなくモデルファミリーで行い、使うモデル ID ごとにテストします。

thinking をオフにすると 400 になる（AIHubMix では推論なしの 200）

Moonshot の Kimi Code のドキュメントには次のように書かれています。

only support thinking mode. Requests with thinking disabled are rejected.

（思考モードのみをサポートします。思考を無効にしたリクエストは拒否されます。）

Kimi Code では HTTP 400 になり、エラー本文はドキュメントに載っていません。Moonshot の API では K3.1 Pro は K3 の制約を引き継ぎ、K3 は常に推論します。AIHubMix 経由では 400 になりません。10月24日、thinking: {"type": "disabled"} は2つのメイン ID の Chat Completions と、kimi-k3.1-pro の Messages で 200 を返し、応答に推論が含まれていませんでした。エラーにならないので、応答に推論があるかを確認してください。よくある原因は、extra_body={"thinking": {"type": "disabled"}} のような K2.x のコードと、effort に off、none、disabled を送るツールです。このスイッチを外し、思考を短くしたいときは reasoning_effort: "low" を使ってください。

残った thinking: {"type": "enabled"} ブロックは別の話で、AIHubMix の実測では4つの ID すべてで 200 でした。ただし Moonshot のドキュメントは thinking を次のように説明しています。

a K2.x-only request parameter

（K2.x 専用のリクエストパラメータ。）

サードパーティのトラブルシューティングガイドも、K2.x から K3 に切り替えたあとの 400 の原因の1つとして残った thinking ブロックを挙げているので、削除しておきましょう。

K2.7 Code を提供終了までフォールバックとして残すなら、thinking はオンのままにします。Moonshot の Claude Code ガイドには、K2.7 Code で thinking をオフにすると 400 invalid thinking: only type=enabled is allowed for this model（thinking が不正：このモデルでは type=enabled のみ使えます）になると書かれています。

effort に off / none や未知の値を送ると 400 になる（AIHubMix では 200）

K3.1 Pro のレベルは low、high、max の3つで、デフォルトは max です。Moonshot の Kimi Code のドキュメントは、サードパーティのツールが送る値を次のように対応づけています。

ツールが送る値	K3.1 Pro の実際のレベル
指定なし	max（デフォルト）
ultra、max、xhigh	max
high、medium	high
low、minimum、light	low
off、none、disabled	HTTP 400
それ以外の値	HTTP 400

Moonshot の API のドキュメントは3つのレベルだけを載せていて、対応づけは書いていません。AIHubMix は low、medium、high、max、xhigh を受け付け、この表と一致しました。表で 400 とされている値は、AIHubMix の kimi-k3.1-pro ではすべて 200 で、off と未知の値は推論あり、none は推論なしでした。AIHubMix ではエラーにならず、静かに失敗します。medium は存在しないレベルなので high になり、xhigh は最も高い max になります。low、high、max のどれかを明示し、ツールが実際に送っている値を確認してください。

`stop array too long` / `stop sequence must not be longer than 32` が出る

AIHubMix の7月の K3 実測では、次の2つが返りました。

Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead（stop 配列が長すぎます。最大長は 5 ですが、長さ 6 の配列が渡されました）
Invalid request: stop sequence must not be longer than 32, but got 33 instead（stop シーケンスは 32 以下でなければなりませんが、33 が渡されました）

K3 が受け付ける停止シーケンスは最大5つ、1つあたり32バイトまでで、Messages API も stop_sequences に同じチェックをかけます。K3.1 Pro は K3 と同じパラメータ制約で、10月24日には kimi-k3.1-pro に6つ送ると同じ 400 が返りました。日本語や中国語では、32 バイト は32文字より少なくなります。

Moonshot の API で Codex を使うと `web_search.search_context_size is not supported` が出る

Moonshot が K3.1 Pro 向けに書いた Codex ガイドに 400 web_search.search_context_size is not supported（web_search.search_context_size はサポートされていません）が載っています。Codex の設定やツール定義から search_context_size を削除してください。Codex はデフォルトではこれを送りません。AIHubMix のコーディングチャネルでは、このフィールド付きの Responses リクエストが10月24日に 200 を返したので、このエラーは Moonshot 側のものです。

Highspeed にしたのに速くならない

原因はおもに2つです。

ID の打ち間違い： Kimi Code では、Highspeed の ID を間違えると次のようになります。

silently falls back to K2.8 Preview without thinking — no speedup.

（思考なしの K2.8 Preview に黙ってフォールバックし、速くなりません。）

AIHubMix では、間違えた ID は 400（This model ID is incorrect）になります。ID はそのままコピーし、利用ログで実際のモデルを確認してください。
速くなるのは出力だけ： Moonshot によると、K3.1 Pro Highspeed は同じ性能で K3.1 Pro の約2〜3倍の速さです。AIHubMix のメイン ID でのスポットチェック（effort は low、モデルごとに3回）では、出力速度は Pro の約1.6〜1.75倍でした。ツール呼び出しやスクリプトの実行は速くならないので、ファイルの読み書きやテストが大半を占めるターンでは差が小さくなります。Kimi Code のプランでは、クォータを約2倍消費します。

200 が返るのに、請求額や出力品質がおかしい

コードの状態	起きること	対処
reasoning_effort を省略	max で動く	用途ごとに effort を設定
medium か xhigh を送る	high か max で動く	low、high、max だけを送る
thinking をオフにする（AIHubMix）	推論なしの 200	代わりに low を使う
low なら短いと思い込む	数千トークン考える	自分のプロンプトで測る
古いセッションで切り替える	品質低下、キャッシュ減	新しいセッション
モデルか effort を途中で変更	キャッシュが無効になる	セッションごとに固定
プロキシでプロトコル変換	挙動が変わることがある	ネイティブのプロトコル
60秒でタイムアウト	失敗し、再試行で再課金	ストリーミング、分単位
content だけを保持	複数ターンが不安定	メッセージ全体を返す
動的ツールのメッセージを削除	ツールが消える	毎回のリクエストで再送

表の補足です。

デフォルトの effort： Kimi Code では K3 のデフォルトが high だったので、同じセッションでもトークンとクォータの消費が増えます。Moonshot の API では、K3 ももともと max でした。思考は出力として課金され、AIHubMix の7月のゲーム生成テストでは、K3 の completion トークン74,994のうち73%が思考でした。
low のとき： スポットチェックでは、K3.1 Pro は low でも回答前に5,561〜7,356トークン考え、1回は8,192トークンの上限に達しました。同じプロンプトで K3 も3,013〜7,051トークン考えたので、K3.1 Pro で始まった問題ではありませんが、どちらでも low は安いモードではありません。max_completion_tokens には余裕を持たせてください。
セッションとキャッシュ： Moonshot の Kimi Code のドキュメントは、次のように勧めています。

avoid switching to the new models within an existing K3 series, K2.8 Preview, or K2.7 Code Highspeed session

（既存の K3 シリーズ、K2.8 Preview、K2.7 Code Highspeed のセッション内で新しいモデルに切り替えないでください。）

切り替えると出力品質が下がり、キャッシュのヒットも減ります。モデルや effort を変えると、キャッシュも無効になります。
プロキシ： Kimi Code のドキュメントには次のように書かれています。

Protocol translation through proxy tools may cause model behavior to vary.

（プロキシツールでプロトコルを変換すると、モデルの挙動が変わる場合があります。）

Claude Code は Messages、Codex は Responses を使います。AIHubMix は2つの K3.1 Pro の ID で、3つのプロトコルをすべて提供しています。
タイムアウト： 回答全体を待つ60秒タイムアウトのクライアントは、スポットチェックの K3.1 Pro の実行（80〜99秒）でいずれも失敗していたはずです。AIHubMix の7月の K3 ゲーム生成では、1リクエストに2,541秒かかりました。
複数ターンと動的ツール（K3 のガイド）： reasoning_content と tool_calls を含む assistant メッセージ全体をそのまま返す必要があり、動的ツールの system メッセージはサーバーが保持しないので毎回送り直します。AIHubMix では、動的ツールは Chat Completions で動きます。10月24日、kimi-k3.1-pro はこの方法で読み込んだツールを呼び出しました。AIHubMix の7月の K3 テストでは、Messages API は読み込んだツールを無視しました。

よくなった点もあります。AIHubMix の7月の K3 テストでは、Messages API が JSON スキーマを無視して自由形式のテキストを返しました。10月24日は、output_config.format に1フィールドのスキーマを入れると、K3.1 Pro は4つの ID すべてで {"city":"Paris"} を返しました。Messages に JSON を戻す前に、出力を検証してください。7月に見つかった Messages の停止シーケンスの問題（end_turn が返り、stop_sequence が null）は再テストしていません。

料金：単価、キャッシュ、推論トークン

Moonshot の公式料金表にある価格（100万トークンあたり）は次のとおりです。キャッシュの書き込みは TTL（デフォルトは5分、1時間も選べます）ごとに課金されます。

Moonshot のモデル ID	入力	出力	キャッシュ入力	書き込み 5分	書き込み 1時間
kimi-k3.1-pro	$2.00	$10.00	$0.20	$2.00	$4.00
kimi-k3.1-pro-highspeed	$4.00	$20.00	$0.20	$4.00	$8.00
kimi-k3	$3.00	$15.00	$0.30	$3.00	$6.00

K3.1 Pro はどの項目も K3 より3分の1安く、Highspeed はキャッシュ入力以外のすべてで Pro のちょうど2倍です。

単価が下がっても、請求額が下がるとは限りません。AIHubMix が7月に K3 で1つのプロンプトからゲームを作らせたテスト（出力74,994トークン、入力は5,000トークンと仮定）は、K3 で約 $1.14 です。トークン数が同じなら、K3.1 Pro では約 $0.76（5,000 × $2.00 + 74,994 × $10.00、100万トークンあたり）、Highspeed では約 $1.52 になります。トークン数はプロンプトによって変わり、スポットチェックでは K3.1 Pro と K3 が同じ程度考えていたので、まず自分のトークン数を測ってください。

K3 と同じく、5分の書き込みはキャッシュなしの入力と同じ価格です。Moonshot によると、書き込みのコストはもともと入力の価格に含まれていたため、デフォルトの TTL のリクエストが以前より高くなることはありません。
AIHubMix は TTL をそのまま渡します。10月24日、トップレベルの cache_control で TTL を 1h にした Messages リクエストは書き込みを1時間キャッシュのトークンとして返し、prompt_cache_options を付けた Chat Completions リクエストも受け付けられました。
K3.1 Pro の TTL 1時間の書き込みは100万トークンあたり $2.00 高く（$4.00 と $2.00）、ヒットするたびにキャッシュなしの入力より $1.80 安くなるので、Moonshot のキャッシュのガイドの計算では2回目のヒットで元が取れます。TTL は最初の書き込み時に固定されます。
K3 では、キャッシュ書き込みに専用の usage フィールドがあります。Chat Completions は prompt_tokens_details.cache_write_tokens、Responses は input_tokens_details.cache_write_tokens、Messages は cache_creation_input_tokens です。コスト集計を更新してください。
キャッシュは自動で効きます。10月24日の実測では、再送した93トークンのプロンプトはコーディングチャネルでは全量キャッシュされ、メイン ID ではされませんでした。7,658トークンのプロンプトでは、kimi-k3.1-pro への2回目の呼び出しで7,424トークンがキャッシュされ、Chat Completions でも Messages でも同じでした。

請求額を下げる手順です。

max をそのまま使わず、用途ごとに reasoning_effort を設定します。調べものや分類は low、日常的なコーディングは high から試してください。
セッションごとにモデルと effort を固定し、どちらかを変えるときは新しいセッションにします。
変わらない部分（システムプロンプト、ツール定義、リポジトリのコンテキスト）を先に置き、毎ターン変わる部分をあとに置きます。
Highspeed はモデルの出力を待つ場面で使い、ツール呼び出しが多いループには使いません。
completion トークンに占める思考の割合を見てください。簡単なタスクで半分を超え続けるなら、effort を下げます。

Claude Code と Codex の設定

AIHubMix は kimi-k3.1-pro を、Claude Code が使う Messages でも、Codex が使う Responses でも提供しています。Moonshot 自身の Codex ガイドも、Responses で Codex を K3.1 Pro につないでいます。インストールと基本設定は AIHubMix のドキュメントにあります。ここでは K3.1 Pro で変わる部分だけを書きます。

	Claude Code	Codex
プロトコル	Anthropic Messages	Responses
使うモデル ID	kimi-k3.1-pro	kimi-k3.1-pro
Base URL	https://aihubmix.com	https://aihubmix.com/v1
宣言するコンテキスト	1M	1048576
設定する effort	low、high、max	low、high、max

Claude Code

AIHubMix の Claude Code ガイドで設定したあと、メインのモデルだけでなく、すべての階層のモデルを指定します。

settings.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Moonshot の Kimi Code のドキュメント、K3 向けの Claude Code ガイド、AIHubMix の実測からわかっている注意点です。

古いセッション： K3 のセッションを切り替えず、新しいセッションを始めます。切り替えると出力品質とキャッシュのヒットが落ちます。
設定していない階層は黙って失敗します。 Claude Code は、メインのチャット、要約、サブエージェントで別々の階層を使います。Moonshot は、一部だけを設定すると残りの場面が次のようになると警告しています。

fail silently

（エラーを出さずに失敗する。）

バックグラウンド処理用に、Haiku の階層を安いモデルに向けることもできます。
古い設定が優先されます。 ~/.claude/settings.json の env ブロックに残った古い値は、シェルで export した変数より優先されます。
1M コンテキスト： Moonshot の K3 ガイドは、Claude Code にウィンドウを 1M として扱わせるために kimi-k3[1m] を使っています。AIHubMix 経由でも kimi-k3.1-pro[1m] は同じように使えます。Claude Code は送信前に接尾辞を外し、10月24日、AIHubMix は 1M コンテキストのヘッダー付きのそのリクエストに応答しました。接尾辞を理解するのは Claude Code だけで、ほかのクライアントから kimi-k3.1-pro[1m] をモデル ID として送ると 400 になります。
effort： K3.1 Pro のデフォルトは max で、Moonshot の K3 ガイドが CLAUDE_CODE_EFFORT_LEVEL=max で勧めていたレベルと同じです。日常的な作業では high のほうがトークンを節約できます。ほかの値は effort の対応表のとおりに扱われます。
Highspeed： ある階層を kimi-k3.1-pro-highspeed に向けるなら、ID はそのままコピーしてください。Kimi Code では打ち間違いが黙ってフォールバックし、AIHubMix では 400 になります。

Codex

Codex は Responses API しか使わないため、wire_api = "responses" が必須です。そのほかの設定は AIHubMix の Codex ガイドにあります。K3.1 Pro 向けの設定は次のとおりです。

config.toml

model = "kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

コンテキストウィンドウを宣言します。 model_context_window がないと、Codex は知らないモデルに対してデフォルトのメタデータを使います。Moonshot の Codex ガイドによると、Model metadata for kimi-k3.1-pro not found（kimi-k3.1-pro のモデルメタデータが見つかりません）という警告は想定どおりで、害はありません。
effort： Kimi Code の対応表では、Codex の medium と xhigh はそれぞれ high と max として動き、AIHubMix もどちらも受け付けました。どのレベルに払っているかがわかるよう、low、high、max のどれかを明示してください。
編集したら再起動します。 Codex は config.toml を起動時にしか読みません。CC Switch で Codex の設定を管理している場合、編集が上書きされることがあります。

動作確認（約15分）

テストスイートのある小さなリポジトリで、ツールごとに1回ずつ、K3.1 Pro の新しいセッションを始めて次のように頼みます。

Add a unit test for one function in this repo, run the tests, and fix anything that fails.

（このリポジトリの関数1つに単体テストを追加し、テストを実行して、失敗したものを直してください。）

合格の基準です。

モデルがファイルを読み、テストを実行する（ツール呼び出しが動いている）。
結果を見たあとも作業を続ける（推論とツールの結果が正しく返されている）。
最後にテストがすべて通り、セッション中に 400 が1回も出ない。
AIHubMix の利用ログに設定したモデル ID が記録され、以降のリクエストで変わらないプレフィックスにキャッシュされた入力トークンが記録されている。一度も記録されなければ、プレフィックスのどこかが毎ターン変わっています。

1ターンの時間と completion トークン数を記録しておくと、effort を選ぶときや Highspeed の価値を判断するときの基準になります。

エージェントに任せる前に

安全チェックはフェイルクローズにします。 上で紹介した Hermes の分類器の例を参照してください。K3.1 Pro では、分類器を速くするための低い temperature も思考のオフも使えません。前者は呼び出しのたびに 400 になりえ、後者は AIHubMix では推論なしで返りました。
ツール呼び出しの強制が使えます。 K3.1 Pro は tool_choice: "required" に対応しています。K2.x では拒否されていました。
組み込みの Web 検索は、まだ本番向けではありません（K3）。 Moonshot の K3 ガイドには次のように書かれています。

is being updated and is not recommended for production workflows in the near term

（更新中であり、当面は本番のワークフローでの利用は推奨されません。）

Moonshot から別の案内があるまでは、K3.1 Pro でも同じように扱ってください。AIHubMix 経由では、10月24日に K3.1 Pro の検索ループが完了しませんでした。モデルが $web_search を求め、その結果を送り返すと 400 Invalid request: tokenization failed が返りました。
画像は base64 で渡します。 10月24日、AIHubMix の kimi-k3.1-pro は公開画像の URL を 400 Invalid request: unsupported image url で拒否しました。Moonshot のファイル ID は Moonshot 自身のアップロードで発行されるもので、AIHubMix では使えません。ms:// の参照は 404 でした。base64 の画像は使えました。

検証できていないこと

AIHubMix で思考オフのリクエストに応答しているもの。 K3.1 Pro の ID で推論なしの 200 が返りましたが、どの経路が応答したのかは文書化されていません。
AIHubMix のキャッシュ書き込みの課金。 モデルページにキャッシュ書き込みの料金がなく、1時間の書き込みの課金方法も書かれていません。
Moonshot の API で思考をオフにした場合。 400 は Kimi Code で文書化されたもので、従量課金の API は直接検証していません。
K3.1 Pro の stop の32バイト上限。 5つまでの上限は再テストしました。長さの上限は「kimi-k3 と同じパラメータ制約」から推測したものです。
スポットチェック。 プロンプト1つ、モデルごとに3回の実行で、メイン ID を使いました。
構造化出力。 1フィールドのスキーマで、ID ごとに1リクエストです。
thinking が残っているときの 400。 Moonshot はエラー文を公開しておらず、原因はサードパーティのトラブルシューティングガイドによるものです。AIHubMix の実測では 200 でした。

まとめ

モデル ID は、Moonshot の API と AIHubMix では kimi-k3.1-pro、Kimi Code では k3.1-pro です。AIHubMix 経由の Codex も kimi-k3.1-pro を使います。
Moonshot で K2.x を使っているコードは、K2 シリーズが提供終了する2026年12月末までに移行します。
temperature、top_p、n、2つの penalty は、補助的な呼び出しも含めてすべての経路から外し、使うモデル ID ごとにテストします。
思考をオフにする設定をなくし、reasoning_effort を low、high、max のどれかで明示します。
モデルと effort はセッションごとに固定し、K3.1 Pro は新しいセッションで始めます。
Highspeed の ID はそのままコピーし、利用ログで確認します。
長いリクエストはストリーミングにし、タイムアウトは分単位にします。
安全チェックは API エラー時にフェイルクローズにします。

AIHubMix のキー1つで上の curl を実行し、使うモデル ID ごとに temperature の扱いを確かめてから切り替えてください。

参考

Model Configuration（Kimi Code）
Model parameter reference（Moonshot AI）
Kimi K3.1 Pro（AIHubMix）
Kimi K3 実測呼び出しガイド（AIHubMix）
Issue #142365: Kimi Code endpoint profile drift（Hermes Agent）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up