Kimi K3.1 Proへの移行：400エラーを解消し、デフォルトのMax Effortに注意し、Highspeedの入力ミスを避ける

Kimi K3.1 ProはKimi Codeで利用可能になり、MoonshotのAPIではkimi-k3.1-proとして、AIHubMixでは同じIDで利用できます。MoonshotはKimi K3と同じパラメーター制約を適用しているため、すでにK3で動いているコードは、モデルIDを変更して新しいセッションを開始すれば移行できます。K2.x向けに書かれたコードは、Moonshotのプラットフォームでは期限が迫っています。Moonshotは2026年10月31日に新規登録ユーザーへのK2シリーズの提供を終了し、12月末までに廃止する予定です。また、最も壊れやすいのもこのコードです。temperatureを送信したり、thinkingをオフにしたりする傾向があり、どちらもK3.1 Proでは使えません。Effortレベルを設定していないコードはmaxで動作するため、想定以上にトークンを消費し、Kimi CodeではK3より多くのクォータを使う可能性があります。

この記事では、目に見える形で発生する問題（400エラーと、1つの404エラー）、気づきにくい問題（請求額、キャッシュ、HighspeedのID）、そしてAIHubMix経由でClaude CodeとCodexをK3.1 Pro向けに設定する方法を説明します。K3.1 ProのルールはMoonshotのKimi Codeモデルのドキュメントとモデルパラメーターのリファレンスに基づいており、同資料ではK3.1 Proの両IDについて「kimi-k3と同じパラメーター制約」があるとしています。K3に関するルールはMoonshotのK3ガイドに基づいており、K3.1 Proで再確認したものではありません。エラー文は、ドキュメント、公開報告、AIHubMixによる7月のK3テスト、および2026年10月24日に実施したAIHubMixのK3.1 Pro検証から引用しています。この検証では、メインのIDと、コーディング用チャンネルのIDであるcoding-kimi-k3.1-proおよびcoding-kimi-k3.1-pro-highspeedを確認しました。各項目には情報源を記載しています。

どの経路を使っていますか？

MoonshotのAPIとAIHubMixでは、IDはkimi-k3.1-proとkimi-k3.1-pro-highspeedです。Kimi Codeではk3.1-proと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が必要です。

K2の提供終了日はMoonshotが発表したものです。2026年10月31日以降、新規登録ユーザーはK2シリーズのモデルを利用できなくなり、すべてのモデルが2026年12月末までに廃止される予定です。MoonshotはK3の廃止日を発表していません。10月24日時点で、AIHubMixではK2.6とK2.7 Codeが引き続き掲載されており、廃止日は設定されていませんでした。

目に見える形で発生する問題

ThinkingをオフにするとHTTP 400、またはreasoningが一切返らない

発生すること：Kimi CodeでHTTP 400が返ります。MoonshotのKimi Codeドキュメントには、K3.1 Proモデルは「thinkingモードのみをサポートし、thinkingを無効にしたリクエストは拒否される」とあります。エラー本文はドキュメントに記載されていません。MoonshotのAPIでは、K3.1 ProにはK3の制約が適用され、K3は常にreasoningを行います。AIHubMix経由では400エラーになりません。10月24日、thinking: {"type": "disabled"}を指定すると、メインの両IDでChat CompletionsとMessagesのどちらも200を返しましたが、応答にはreasoningが含まれませんでした。こちらは気づきにくい失敗なので、reasoningが欠落していないか応答を確認してください。

発生する原因：たとえばextra_body={"thinking": {"type": "disabled"}}のように、応答を速くするためにthinkingをオフにするK2.x向けコードや、off、none、disabledをEffortとして送信するツール（次のセクションを参照）。

対処法：切り替え指定を削除します。thinkingを短く保ちたい場合は、代わりにreasoning_effort: "low"を送信してください。

「enabled」が残っている場合は別のケースです。AIHubMixが10月24日に行った検証では、K2.xのthinking: {"type": "enabled"}をK3.1 Proに送信したところ、メインIDとコーディング用チャンネルの両方で200が返りました。Moonshotのドキュメントではthinkingを「K2.x専用のリクエストパラメーター」としています。また、K2.xからK3への切り替え後に400エラーが発生する原因として、第三者のトラブルシューティングガイドはこの指定の残存を挙げています。そのため、いずれにしても削除してください。

K2.7 Codeを廃止まで予備の階層として使い続ける場合は、thinkingをオンにしておいてください。MoonshotのClaude Codeガイドには、thinkingをオフにしたK2.7 Codeで400 invalid thinking: only type=enabled is allowed for this modelが発生すると記載されています。

Effortの値：off、none、未対応の値は400エラーを返す

発生すること：Effortがoff、none、disabledの場合、またはKimi Codeが認識しない値の場合、HTTP 400が返ります。K3.1 Proのレベルはlow、high、maxの3つです。MoonshotのKimi Codeドキュメントでは、サードパーティ製ツールから送信される値は次のように割り当てられます。

MoonshotのAPIドキュメントでは、K3.1 Proで使える値としてlow、high、maxのみを記載しており、デフォルトはmaxです。値の割り当てについては説明されていません。AIHubMixでは10月24日、すべてのK3.1 Proの4つのIDでlow、medium、high、max、xhighのいずれも200が返りました。kimi-k3.1-proではoffと未対応の値でもreasoning付きで200が返り、noneではreasoningなしで200が返りました。AIHubMixでは400エラーにならず、気づきにくい形で失敗します。

気づきにくい点：mediumレベルはありません。mediumに設定したツールはhighで、xhighに設定したツールは、最もコストの高いmaxで動作します。

対処法：low、high、maxのいずれかを明示的に送信し、ツールが実際に送信している値を確認してください。

"invalid temperature: only 1 is allowed for this model"

発生すること：400 invalid temperature: only 1 is allowed for this modelが返ります。AIHubMixが10月24日に行った検証では、temperature: 0.2を送信すると、kimi-k3.1-proとkimi-k3.1-pro-highspeedの両方でまったく同じエラーが返りました。2026年10月3日にはMoonshotのAPIでK3に対して、10月21日にはKimi Codeのk3エンドポイントに対して、同じ文面のエラーが報告されています。

原因：Moonshotのパラメーターリファレンスによると、K3.1 ProにはK3の制約が適用され、temperatureは1.0固定、top_pは0.95、nは1、両方のpenaltyは0に固定されます。それ以外の値を指定するとエラーになります。K2.6にも固定値があり、thinkingがオフの場合は0.6でした。そのため、0.6を送信し続けるコードが典型的な原因です。

問題が隠れる例外：同じ検証で、AIHubMixのコーディング用チャンネルはtemperature: 0.2を受け付けました。このチャンネルだけでテストしたコードは、メインIDやMoonshotのAPIでは依然として失敗する可能性があります。

さらに問題を隠す落とし穴：多くのフレームワークはkimi-というプレフィックスを使ってKimiモデルを判別し、それらのモデル向けのtemperature指定を削除します。Kimi Codeのk3.1-proとk3.1-pro-highspeedにはこのプレフィックスがなく、coding-で始まるAIHubMixのコーディング用チャンネルのIDにもありません。Hermes Agentのissueでは、K3でまさにこの問題が確認されました。メインのチャット処理ではtemperatureが省かれていましたが、k3へのヘルパー呼び出しでは送信され、毎回400エラーになっていました。

対処法：temperature、top_p、n、presence_penalty、frequency_penaltyは一切送信しないでください。名前のプレフィックスではなく、モデルファミリーに基づいて判定します。

ルートを確認するには、temperatureを指定したリクエストを1件送信します。

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日の検証では、上記の400エラーが返りました。コードで使うモデルIDごとに実行してください。同じリクエストに対して、コーディング用チャンネルは200を返しました。

AIHubMix経由のCodex：Responses APIで404

発生すること：HTTP 404とThe model kimi-k3.1-pro is not available on this endpoint.が返ります。AIHubMixが10月24日に行った検証では、メインIDの両方でResponses APIを使うとこのエラーが返りましたが、Chat CompletionsとMessagesは正常に応答しました。

対処法：Codexが使用できるのはResponses APIのみなので、同じ検証でResponsesリクエストに応答したcoding-kimi-k3.1-proを指定してください。AIHubMixはコーディング用チャンネルを評価プレビューと位置づけ、本番環境での利用を推奨していません。また、「The requested resource was not found」という一時的な404が返るリクエストもいくつかありました。デバッグする前に一度リトライしてください。AIHubMixがメインIDにResponses APIを追加するまで、このIDを使用してください。Claude CodeはMessagesを使用するため、メインIDで動作します。

stopシーケンスの制限

発生すること：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
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

原因：K3ではstopシーケンスは最大5個で、それぞれ最大32バイトです。Messages APIではstop_sequencesにも同じ制限が適用されます。MoonshotはK3.1 Proにも同じパラメーター制約を適用しているため、同じ制限があると考えてください。

対処法：リストを短くしてください。32バイトは、中国語や日本語では32文字より少ないことに注意してください。

MoonshotのAPIでCodexを使うと「web_search.search_context_size is not supported」（K3ガイド）

発生すること：400 web_search.search_context_size is not supportedが返ります。K3向けに書かれたMoonshotのCodexガイドからの引用です。10月24日、AIHubMixのコーディング用チャンネルでは、このフィールドを含むResponsesリクエストが200を返したため、このエラーはMoonshot独自のエンドポイントで発生します。

対処法：Codexの設定またはツール定義からsearch_context_sizeを削除してください。Codexはデフォルトではこの値を送信しません。

気づきにくい問題

これらはエラーを返しません。後になって請求額やプランのクォータに影響したり、出力品質に表れたりします。

Effortとセッション

• デフォルトはmaxで、Kimi Codeでは今回から変更されています。K3.1 Proのデフォルトはmaxです。Kimi CodeではK3のデフォルトがhighだったため、Effortを設定していないセッションは以前より深く思考し、より多くのトークンを使って、クォータの消費が速くなります。MoonshotのAPIでは、K3とK3.1 Proのどちらもデフォルトはmaxです。Thinkingは出力として課金されます。AIHubMixが7月にK3で実施した、1つのプロンプトだけでゲームを構築するテストでは、74,994個のcompletionトークンのうち73%がthinkingでした。
• lowでも、思考トークンが数千に達することがあります。10月24日にAIHubMixでスポットチェックを行ったところ、600語の説明を求めるプロンプトに対し、K3.1 Proはlowでも回答する前に5,561～7,356トークンを推論に使い、1回は8,192トークンの上限に達しました。同じプロンプトでK3が使った推論トークンは3,013～7,051でした。この傾向はK3.1 Proで始まったわけではありませんが、どちらのモデルでもlowは低コストモードではありません。max_completion_tokensには余裕を持たせてください。これはAIHubMixのメインIDで、各モデルにつき1つのプロンプトを3回実行した結果です。実際のワークロードでも測定してください。
• 古いセッション内でK3.1 Proに切り替えると、品質が低下します。MoonshotのKimi Codeドキュメントでは、「既存のK3シリーズ、K2.8 Preview、またはK2.7 Code Highspeedのセッション内」で新しいモデルに切り替えないよう推奨しています。出力品質が低下し、キャッシュヒットも減るためです。新しいセッションを開始してください。
• モデルやeffortを変えるとキャッシュが無効になります。MoonshotのKimi Codeドキュメントでは、どちらを変更した場合もそうなると記載されています。また、K3のドキュメントにも、effortの切り替えは「prefix-cache hitsを無効にする」とありました。セッション開始時にモデルとレベルを選んでください。

Highspeed

• HighspeedのIDを間違えると、低速なモデルに切り替わります。Kimi Codeでは、HighspeedのIDを間違えると「通知なしにK2.8 Previewへフォールバックし、thinkingなしで実行されます。速度向上はありません」。IDを正確にコピーし、ログに表示されるモデルを確認してください。
• Highspeedが高速化するのは、モデルの出力だけです。Moonshotによると、K3.1 Pro HighspeedはK3.1 Proの約2～3倍の速度で、機能は同一です。AIHubMixのスポットチェックでは、出力速度はProの約1.6～1.8倍でした。ツール呼び出しやスクリプトはまったく速くならないため、ファイルの読み込みやテスト実行が大半を占めるターンでは効果は小さい一方、Kimi Codeのプランではクォータが約2倍消費されます。

プロトコル

• プロキシによって挙動が変わることがあります。MoonshotのKimi Codeドキュメントは、「プロキシツールによるプロトコル変換によって、モデルの挙動が変わる場合があります」と警告しています。各ツールには、そのツールが使うプロトコルを指定してください。Claude CodeにはMessages、CodexにはResponsesを使います。10月24日、AIHubMixでは4つのK3.1 Pro IDすべてで、推論を含むChat CompletionsとMessagesへの応答が確認できました。推論はreasoning_contentとして、またthinkingブロックとして返されました。Responsesはコーディング用チャンネルではreasoning項目とともに動作し、メインIDでは前述の404を返しました。
• Messages APIの構造化出力は改善されました。7月にAIHubMixでK3をテストした際、/v1/messagesはスキーマを無視し、自由形式のテキストを返しました。10月24日、JSONを求めないプロンプトにoutput_config.formatでJSONスキーマを指定し、K3.1 Proに同種のリクエストを送ったところ、4つのIDすべてで{"city":"Paris"}が返されました。これは1フィールドのスキーマでの結果です。JSONをMessagesに戻す前に、出力を検証してください。7月に確認されたMessagesのもう1つの癖、つまりstop sequenceに一致してもend_turnとして返され、stop_sequence: nullとなる挙動は再テストしていません。

長時間のリクエスト

• 短いタイムアウトでは、さほど大きくないリクエストでも失敗します。スポットチェックでは、K3.1 Proがlowで完全な回答を返すまでに80～99秒かかりました。タイムアウトを60秒に設定した非ストリーミングクライアントでは、すべての実行が失敗し、リトライすると同じ推論に再び料金がかかっていたでしょう。Moonshot APIでのK3.1 Proのデフォルト出力上限は131,072トークンで、最大1,048,576トークンです。また、AIHubMixが7月にK3で行ったゲーム構築のリクエストは、1回のリクエストで2,541秒かかりました。ストリーミングを使い、タイムアウトは分単位で設定してください。

K3のガイドから引き継がれる注意点

以下はK3のガイドに由来する注意点です。

• reasoning_contentを削除すると、複数ターンの品質が低下します。reasoning_contentとtool_callsを含むassistantメッセージ全体を、変更せずに返す必要があります。contentだけを保持するコードでも動作はしますが、Moonshotは出力品質が不安定になると警告しています。
• メッセージを削除すると、動的ツールが失われます。K3では、コンテンツのないsystemメッセージを使って、会話の途中でツールを読み込めます。このメッセージはサーバーに保持されないため、リクエストごとに再送する必要があります。AIHubMixではChat Completions経由で動作します。10月24日、kimi-k3.1-proはこの方法で追加したツールを呼び出しました。一方、AIHubMixで7月に行ったK3のテストでは、Messages APIは追加したツールを無視しました。

見落としやすい課金ルール

以下の価格は、AIHubMixのモデルページに掲載されている100万トークンあたりの料金です。

AIHubMixでは、K3.1 Proの入力とキャッシュ済み入力はK3より30%安く、出力は26%安くなっています。Highspeedは入力と出力がProの2倍の料金で、キャッシュ済み入力の料金は同じです。コーディング用チャンネルのIDは別料金で、入力が$0.88、出力が$3.23、キャッシュ済み入力が$0.132です。

単価が下がっても、請求額が下がるとは限りません。AIHubMixが7月にK3で行った、1つのプロンプトによるゲーム構築を例にします。出力トークンは74,994で、入力トークンを5,000と仮定します。同じトークン数の場合、料金はK3で約$1.08、K3.1 Proで約$0.80（100万トークンあたり、5,000 × $2.00 + 74,994 × $10.50）、Highspeedで約$1.59です。トークン数はプロンプトによって変わります（スポットチェックでは、lowのK3.1 ProとK3は同程度でした）。予算を組む前に測定してください。

MoonshotのAPIドキュメントによると、K3.1 Proのキャッシュ書き込みはK3と同様に、5分または1時間のTTLに基づいて課金されます。Moonshotのコンテキストキャッシュガイドに記載されたK3の料金から、料金体系が分かります。

Moonshotによると、キャッシュ書き込みを別項目に分けても、K3の合計料金は上がりませんでした。書き込み料金はすでに入力料金に含まれていたため、デフォルトのTTL 5分でのリクエスト料金は以前と同じです。

これらはMoonshotの直接提供料金です。AIHubMixのモデルページには入力、出力、キャッシュ済み入力の料金のみが掲載されており、キャッシュ書き込みの料金は別途記載されていません。また、1時間の書き込みがどのように課金されるかも明記されていません。AIHubMixはTTLを引き継ぎます。10月24日、トップレベルにcache_controlのTTLとして1hを指定したMessagesリクエストでは、書き込みが1時間のキャッシュトークンとして報告されました。また、prompt_cache_optionsを指定したChat Completionsリクエストも受け付けられました。

• キャッシュは自動で行われます。K3のデフォルトTTLは5分です。AIHubMixで10月24日に確認したところ、93トークンのプロンプトを繰り返した際、コーディング用チャンネルではすべてキャッシュされて返されましたが、メインIDではそうなりませんでした。7,658トークンのプロンプトでは、kimi-k3.1-proへの2回目の呼び出しで7,424トークンがキャッシュ済みとして返されました。Chat CompletionsとMessagesの両方で同じ結果でした。
• MoonshotのAPIでの1時間TTLは、K3の料金では100万トークンあたりの書き込みに$3.00の追加料金がかかります。ヒットごとに$2.70節約できるため、Moonshot自身の計算では、2回目のヒットから元が取れます。
• TTLは最初の書き込み時に固定されます（K3）。5分のエントリを1時間に延長することはできません。いったん有効期限が切れるのを待つ必要があります。
• コストダッシュボードには新しい項目が必要です（K3）。キャッシュ書き込みは、Chat Completionsではprompt_tokens_details.cache_write_tokens、Responsesではinput_tokens_details.cache_write_tokens、Messagesではcache_creation_input_tokensとして表示されます。
• 推論は出力として課金されます。K3では、どのeffortレベルでも思考トークンは出力料金で課金されます。AIHubMixはK3.1 Proの推論に別料金を設定していません。

料金を抑える方法：

1. すべての作業でmaxを引き継ぐのではなく、用途ごとにreasoning_effortを設定してください。検索や分類にはlow、日常的なコーディングにはhighを試してください。
2. セッションごとにモデルとeffortを固定し、どちらかを変更するときは新しいセッションを開始してください。
3. 変わらない要素は先に配置します。systemプロンプト、ツール定義、リポジトリのコンテキストを置いてから、変化するターンを続けてください。
4. Highspeedは、待ち時間のボトルネックがモデル出力にある場合に使い、ツール呼び出しが大半を占めるループでは使わないでください。
5. completionトークンに占める思考トークンの割合を確認してください。簡単なタスクでも半分を超え続ける場合は、effortを下げましょう。

実際の権限を持つエージェント

Hermes Agentの問題は、移行時の不具合が安全性の問題に発展する例です。「smart approval」分類器は、temperatureを指定してk3を呼び出しており、毎回400が返されていました。報告者の言葉では、分類器は「呼び出しのたびにエスカレーション（フェイルオープン）する」とのことです。安全性チェックは機能を停止していたのに、メインチャットでは何も問題がないように見えていました。

K3.1 Proではそのトリガーが引き継がれ、さらにもう1つ加わります。分類器の呼び出しでは、temperatureを低く設定したり、thinkingをオフにしたりして、高速かつ低コストにすることがよくあります。しかし、K3.1 Proではどちらも機能しません。temperatureを指定すると毎回400が返される場合があり、AIHubMixではthinkingをオフにしたリクエストに推論が含まれませんでした。K3.1 Proで安全性チェックを実行する場合は、速度を優先してreasoning_effort: "low"を使い、APIエラー時の動作を決めたうえで、フェイルクローズにしてください。

自律的に動作するエージェントでは、ほかにも重要な点があります。

• ツール呼び出しの強制は動作します。K3.1 Proはtool_choice: "required"をサポートしています。K2.xでは拒否されていたため、ツール呼び出しを強制するK2.x向けの回避策は不要になります。
• 組み込みのウェブ検索は、まだ本番利用できる状態ではありません（K3）。MoonshotのK3ガイドでは、ウェブ検索について「現在更新中で、近い将来の本番ワークフローでの使用は推奨されません」としています。Moonshotが別途案内するまでは、K3.1 Proでも同様に扱ってください。AIHubMix経由では、10月24日にK3.1 Proの検索ループが完了しませんでした。モデルは$web_searchを要求し、その結果を返送すると400 Invalid request: tokenization failedが返されました。
• 画像入力にはbase64が必要です。K3は公開画像URLを取得できません。10月24日にはAIHubMix上のkimi-k3.1-proも画像URLを1つ拒否し、400 Invalid request: unsupported image urlを返したため、スクリーンショットのリンクを渡すエージェントはエラーになります。Moonshotが提供するもう1つの方法である、自社のファイルアップロードから取得したファイルIDは、AIHubMixでは利用できません。ms://参照を指定すると404が返されました。base64形式の画像は動作しました。Kimi Codeでは、K3.1 Proは動画入力にも対応しています。

コーディングツール：Claude CodeとCodex

Claude CodeはAnthropic Messages APIを使い、10月24日にはAIHubMixのメインIDで応答が確認できました。CodexはResponses APIを使い、応答したのはコーディング用チャンネルのみでした。インストールと基本設定については、AIHubMixの常設ガイドで説明しています。以下ではK3.1 Proで変わる点だけを取り上げます。

Codex列では、Responses APIでメインIDが応答するようになるまでは、codingチャネルのIDを使います。ツールがこの3つ以外のeffort値を送信した場合は、上記のeffort表に従ってマッピングされます。

Claude Code

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で実行中のセッションをK3.1 Proに切り替えないでください。キャッシュと出力品質をクリーンな状態で始められるよう、新しいセッションを開きましょう。
• 未設定のティアは、エラーを出さずに失敗する。Claude Codeでは、メインチャット、要約、サブエージェントで異なるティアを使用します。一部だけ設定すると、残りは「エラーを出さずに失敗する」とMoonshotは警告しています。バックグラウンド処理には、Haikuティアをより安価なモデルに割り当てることもできます。
• 古い設定が優先されます。envブロック内の~/.claude/settings.jsonにある古い値が、シェルでエクスポートした変数より優先されます。
• 1Mコンテキスト。MoonshotのK3ガイドでは、Claude Codeがウィンドウを1Mとして扱うようkimi-k3[1m]を使用しています。AIHubMixでもkimi-k3.1-pro[1m]は同様に動作します。Claude Codeは送信前にサフィックスを取り除き、10月24日にはAIHubMixが1Mコンテキストのヘッダーを含むリクエストに応答しました。このサフィックスを理解するのはClaude Codeだけです。他のクライアントからモデルIDとして送ると、kimi-k3.1-pro[1m]は400を返します。
• Effort。K3.1 Proのデフォルトはすでにmaxです。MoonshotのK3ガイドでもCLAUDE_CODE_EFFORT_LEVEL=maxと推奨されていたレベルです。通常の作業ならhighのほうがトークン消費を抑えられます。Claude Codeが送信するレベルは、effort表に従ってマッピングされます。AIHubMixではテストした5つの値すべてが受け付けられました。
• Highspeedのティア。ティアにkimi-k3.1-pro-highspeedを指定する場合は、IDを正確にコピーしてください。Kimi Codeでは、入力ミスがあってもエラーを出さずにフォールバックしますが、AIHubMixではIDを間違えると400が返ります。

Codex

Codexが対応しているのはResponses APIだけなので、wire_api = "responses"が必須です。その他の設定についてはCodexのconfig.tomlガイドを参照してください。K3.1 Proの場合は次のとおりです。

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-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は認識していないモデルに対するデフォルトのメタデータにフォールバックします。K3向けに書かれたMoonshotのCodexガイドによると、その結果表示されるModel metadata for kimi-k3 not foundという警告は想定内で、問題ありません。
• Effort。Codex独自のレベルにはmediumとxhighがあります。Kimi Codeのマッピングでは、それぞれhighとmaxとして実行され、10月24日にはAIHubMixで両方が受け付けられました。どのレベルの料金が発生するか把握できるよう、low、high、またはmaxを設定してください。
• チャネルによって挙動が異なる。codingチャネルでは、メインIDでは拒否されたtemperatureが受け付けられました。メインIDがResponsesで応答するようになったら、切り替える前にもう一度スモークテストを実施してください。
• search_context_sizeは使わない。設定に含まれている場合は削除してください（重大なエラーの項を参照）。
• 編集後に再起動する。Codexがconfig.tomlを読み込むのは起動時だけです。CC SwitchでCodexの設定を管理している場合、編集内容が上書きされることがあります。

15分でできるスモークテスト

テストスイートのある小規模なリポジトリで、各ツールにつき一度、次の手順を実行してください。

1. K3.1 Proで新しいセッションを開始します。K3や別のモデルで実行したセッションを続けてはいけません。
2. 「このリポジトリ内の関数を1つ選んでユニットテストを追加し、テストを実行して、失敗したものがあれば修正してください」と依頼します。
3. 成功の目安は次のとおりです。モデルがファイルを読み込み、テストを実行する（ツール呼び出しが機能する）。結果を確認した後も処理を続ける（推論とツールの結果がモデルに返されている）。テストがすべて成功し、セッション内のどこにも400や404が表示されない。
4. AIHubMixの使用ログで、設定したモデルIDが使われていること、また後続のリクエストで安定したプレフィックスに対するキャッシュ入力トークンが表示されることを確認してください。いつまでも表示されない場合は、プレフィックス内の何かがターンごとに変化しています。
5. ターンの所要時間と生成トークン数を記録してください。これはeffortレベルを選ぶときや、Highspeedに価値があるか判断するときの基準になります。

移行チェックリスト

• K3.1 ProのIDを使用する。Moonshot APIとAIHubMixではkimi-k3.1-pro、Kimi Codeではk3.1-pro、AIHubMix経由のCodexでは現時点でcoding-kimi-k3.1-proを使います。
• MoonshotがK2シリーズを2026年12月末に提供終了する前に、K2.xのコードを移行する。新規のMoonshotアカウントでは10月31日からK2を利用できなくなります。
• 古いセッションを切り替えるのではなく、K3.1 Pro用に新しいセッションを開始する。
• ヘルパー呼び出しを含む、すべての呼び出し経路からtemperature、top_p、n、2種類のペナルティを削除する。
• effortのoff、none、disabledなどの値を含む、thinkingをオフにする設定をすべて削除し、残っているK2.xのthinkingブロックも削除する。
• effortにはlow、high、またはmaxを指定する。mediumはhighとして、xhighはmaxとして実行されます。
• セッション中はモデルとeffortを固定する。
• HighspeedのIDを正確にコピーし、使用ログでモデルを確認する。
• stopリストは、32バイト以下の項目を5つまでにする。
• reasoning_contentとtool_callsを含むアシスタントメッセージ全体を返し、動的なツールメッセージも再送する。
• 長いリクエストはストリーミングし、タイムアウトは分単位で設定する。
• 構造化出力を検証してから、JSONをMessages APIに戻す。
• キャッシュ書き込み専用のフィールドを考慮して、コスト追跡を更新する。
• APIエラー時は安全側に倒して、チェックを必ず失敗扱いにする。
• 各コーディングツールでスモークテストを実行する。

よくある質問

K3.1 ProがHTTP 400を返すのはなぜですか？
よくある原因は、temperatureが1以外、thinkingがオフ、またはeffortがoff、none、disabled、あるいは不明な値になっていることです。最初の原因はK3の固定サンプリングルールに由来し、K3.1 Proでも引き継がれています。残りはMoonshotのKimi Codeドキュメントに記載されています。10月24日にAIHubMixのメインIDで400を返したのはtemperatureだけで、他の設定では200が返り、thinkingをoffまたはnoneにすると推論なしの応答になりました。

thinkingをオフにできますか？
いいえ。K3.1 Proはthinkingモードでのみ動作します。thinkingを短くするには、reasoning_effortをlowに設定してください。

temperatureは引き続き拒否されますか？
はい。MoonshotのAPIとAIHubMixのメインIDでは、2026年10月24日に「invalid temperature: only 1 is allowed for this model」が返されました。同じテストでAIHubMixのcodingチャネルは、temperatureが0.2でも受け付けました。どの経路でもtemperatureは指定しないでください。

K2モデルはいつ使えなくなりますか？
2026年10月31日以降、新規登録したMoonshotユーザーはK2シリーズのモデルを利用できなくなり、Moonshotは2026年12月末までにすべてのK2モデルを提供終了する予定です。10月24日時点でAIHubMixにはK2.6とK2.7 Codeが掲載されており、提供終了日は発表されていません。

Kimi Codeのクォータ消費が速くなったのはなぜですか？
K3.1 Proはデフォルトでeffortがmaxですが、Kimi CodeのK3ではhighがデフォルトでした。また、Highspeedは通常モデルのおよそ2倍のクォータを消費します。通常の作業には低いeffortを設定し、セッション中は固定してください。

Highspeedが速くないのはなぜですか？
IDの入力ミスにより、Kimi CodeがthinkingなしのK2.8 Previewへエラーを出さずにフォールバックしているか、ターンの大部分をツール呼び出しが占めている可能性があります。Highspeedが高速化するのはモデルの出力だけです。

CodexではどのAIHubMixモデルIDを使えばよいですか？
現時点ではResponses APIでcoding-kimi-k3.1-proを使用し、エンドポイントをaihubmix.com/v1、wire_apiをresponsesに設定してください。10月24日時点で、メインIDはResponses APIで404を返しました。AIHubMixはcodingチャネルを評価プレビューとしており、本番環境向けではありません。

続きを読む：Kimi K3.1 Proシリーズ

• 移行する前に、何が変わったのか、実際のタスク1件にいくらかかるのかを確認し、アップグレードする価値があるか検討しましょう。Kimi K3.1 Pro vs K3：変更点、コスト、乗り換えるべきユーザー
• 移行にあたって他の選択肢も検討している方へ。K3.1 Pro、Qwen 4、Claude Fable 5.5を比較し、それぞれでフロントエンドを1つ構築するコストを紹介します。Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5：フロントエンドの品質、タスクあたりのコスト、そして誇大広告の検証
• Highspeedのクォータと価格を見て、高速版に価値があるのか気になっている方へ。速度と価格のトレードオフを扱った記事はこちらです。Kimi K3.1 Pro vs K3.1 Pro Highspeed：速度が2～3倍でも価格が2倍なら価値はある？

出典

• Kimi Code：モデル設定
• Moonshot AI：モデルパラメーターのリファレンス
• AIHubMix：Kimi K3.1 Proのモデルページ
• AIHubMix：Kimi K3の実践ガイド
• Hermes Agent issue #142365：Kimi Codeのエンドポイントプロファイルのずれ