遷移至 Kimi K3.1 Pro：修正 400 錯誤、留意 max 推理強度預設值，別把 Highspeed 打錯

Kimi K3.1 Pro 已在 Kimi Code 上線，也可透過 Moonshot 的 API 使用，ID 為 kimi-k3.1-pro；在 AIHubMix 上的 ID 也相同。Moonshot 對它採用與 Kimi K3 相同的參數限制，因此已能在 K3 上執行的程式碼，只要更換模型 ID 並開啟新工作階段即可。原本為 K2.x 撰寫的程式碼，現在在 Moonshot 平台上有了期限：Moonshot 將於 2026 年 10 月 31 日起，停止向新註冊使用者提供 K2 系列，並計畫在 12 月底前將其退役。這類程式碼也最容易出問題，因為往往會傳入 temperature，或關閉思考模式，而這兩種做法在 K3.1 Pro 上都行不通。若程式碼未設定推理強度，則會以 max 運行，消耗的 token 可能比你預期更多；在 Kimi Code 中，所用配額也會比 K3 更多。

本文列出會直接出錯的項目（400 錯誤，以及一種 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 的測試，以及 AIHubMix 在 2026 年 10 月 24 日對 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，且未標示退役日期。

會直接顯現的錯誤

關閉思考模式：HTTP 400，或完全沒有推理內容

你會看到的情況：Kimi Code 回傳 HTTP 400。Moonshot 的 Kimi Code 文件指出，K3.1 Pro 模型「僅支援思考模式。停用思考模式的請求會遭到拒絕。」文件並未提供錯誤內容。在 Moonshot API 上，K3.1 Pro 採用 K3 的限制，而 K3 一律會進行推理。透過 AIHubMix 使用則不會出現 400：10 月 24 日，thinking: {"type": "disabled"} 在兩個主要 ID 上，透過 Chat Completions 和 Messages 測試時都回傳 200，但回應中沒有推理內容。這是個不易察覺的失敗，因此請檢查回應是否缺少推理內容。

可能的原因：從 K2.x 沿用的程式碼為了加快回覆速度而關閉思考模式，例如使用 extra_body={"thinking": {"type": "disabled"}}；以及傳送 off、none 或 disabled 推理強度的工具（見下一節）。

修正方式：移除這項設定。若要縮短思考時間，改為傳送 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 退役前，仍將它保留為備援層級，請確保思考模式保持開啟。Moonshot 的 Claude Code 指南記錄了 K2.7 Code 關閉思考模式時出現的錯誤：400 invalid thinking: only type=enabled is allowed for this model。

推理強度值：off、none 和未知值會回傳 400

你會看到的情況：推理強度設為 off、none、disabled，或 Kimi Code 不認得的值時，會收到 HTTP 400。K3.1 Pro 有三種推理強度：low、high 和 max。Moonshot 的 Kimi Code 文件說明了第三方工具傳入的值會如何對應：

Moonshot 的 API 文件只為 K3.1 Pro 列出 low、high 和 max，並以 max 為預設值，沒有說明對應方式。10 月 24 日，AIHubMix 上的四個 K3.1 Pro ID 對 low、medium、high、max 和 xhigh 都回傳 200。對 kimi-k3.1-pro 而言，off 和未知值也回傳 200，且有推理內容；none 則回傳 200，但完全沒有推理內容。在 AIHubMix 上，這些情況會悄悄失敗，而不是回傳 400。

不易察覺的部分：沒有 medium 這個層級。工具設定為 medium 時會使用 high；設定為 xhigh 時則會使用 max，也就是成本最高的層級。

修正方式：明確傳送 low、high 或 max，並確認工具實際傳送了什麼。

「無效的 temperature：此模型僅允許 1」

你會看到的情況：400 invalid temperature: only 1 is allowed for this model。AIHubMix 在 10 月 24 日進行的檢查中，對 kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed 傳送 temperature: 0.2 時，收到的正是這則錯誤訊息。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 也有固定值，但設定不同：思考模式關閉時為 0.6，因此仍傳送 0.6 的程式碼最可能是問題來源。

可能掩蓋問題的例外情況：在同一項檢查中，AIHubMix 的編碼頻道接受了 temperature: 0.2。如果只在該頻道測試，程式碼仍可能在主要 ID 或 Moonshot API 上出錯。

更不容易察覺的陷阱：許多框架會根據 kimi- 前綴辨識 Kimi 模型，並在這些模型的請求中移除 temperature。Kimi Code 的 k3.1-pro 和 k3.1-pro-highspeed 沒有這個前綴，AIHubMix 的編碼頻道 ID 也沒有，因為它們是以 coding- 開頭。某個 Hermes Agent 問題回報在 K3 上發現了完全相同的狀況：主要聊天路徑沒有傳入 temperature，但呼叫 k3 的輔助請求仍傳送了 temperature，結果每次都收到 400。

修正方式：完全不要傳送 temperature、top_p、n、presence_penalty 或 frequency_penalty。請依模型家族判斷，而不是依名稱前綴。

若要檢查端點，請傳送一個含有 temperature 的請求：

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，因此請將端點設為 coding-kimi-k3.1-pro；同一項檢查中，此 ID 能正常回應 Responses 請求。AIHubMix 將編碼頻道標示為不建議用於正式環境的評估預覽版，且部分請求曾短暫回傳 404「The requested resource was not found」，因此開始除錯前請先重試一次。在 AIHubMix 為主要 ID 加入 Responses API 支援前，請使用此頻道。Claude Code 使用 Messages，因此可搭配主要 ID 正常運作。

stop 限制

你會看到的情況：AIHubMix 7 月對 K3 進行的測試回傳了以下兩則訊息：

• 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 序列，每個最多 32 bytes；Messages API 對 stop_sequences 也採用相同限制。Moonshot 為 K3.1 Pro 設定相同的參數限制，因此預期限制也相同。

修正方式：縮短清單。請注意，32 bytes 在中文或日文中所代表的字元數不到 32 個。

在 Moonshot API 上使用 Codex：「不支援 web_search.search_context_size」（K3 指南）

你會看到的情況：400 web_search.search_context_size is not supported，引自 Moonshot 的 Codex 指南；該指南是為 K3 撰寫的。10 月 24 日，透過 AIHubMix 編碼頻道傳送含有該欄位的 Responses 請求時，回傳了 200，因此此錯誤來自 Moonshot 自己的端點。

修正方式：從 Codex 設定或工具定義中移除 search_context_size。Codex 預設不會傳送此參數。

不易察覺的問題

這些問題不會回傳錯誤，而是稍後才會顯現，反映在帳單、方案配額或輸出品質上。

推理強度與工作階段

• 預設值是 max，而且這對 Kimi Code 來說是新的變化。K3.1 Pro 的預設推理強度為 max。Kimi Code 中的 K3 預設值是 high，因此若工作階段從未設定推理強度，現在會進行更深入的思考、使用更多 token，並更快消耗配額。在 Moonshot API 上，K3 和 K3.1 Pro 的預設值都是 max。思考過程會計入輸出用量：AIHubMix 7 月使用 K3、透過單一提示詞產生遊戲的測試中，74,994 個 completion token 有 73% 用於思考。
• 低推理強度仍可能代表數千個思考 token。在 10 月 24 日 AIHubMix 的抽查中，一則要求撰寫 600 字說明的提示詞，讓 K3.1 Pro 在回答前以 low 推理了 5,561 到 7,356 個 token，其中一次執行達到 8,192 個 token 的上限。同一則提示詞讓 K3 推理了 3,013 到 7,051 個 token，因此這不是 K3.1 Pro 才有的新狀況，但兩者的 low 都不是省錢模式；請將 max_completion_tokens 設得寬裕一些。這只是 AIHubMix 主要 ID 上每個模型使用一則提示詞、執行三次的結果，請以自己的工作負載進行測量。
• 在舊有工作階段中切換至 K3.1 Pro 會降低品質。Moonshot 的 Kimi Code 文件建議，不要「在現有的 K3 系列、K2.8 Preview 或 K2.7 Code Highspeed 工作階段中」切換至新模型：這會降低輸出品質並減少快取命中。請開啟新的工作階段。
• 變更模型或推理強度會使快取失效。Moonshot 的 Kimi Code 文件指出，這兩種變更都會造成此情況；K3 的文件也提到，切換推理強度「會使 prefix-cache 命中失效」。請在工作階段開始時選定模型和推理強度。

Highspeed

• Highspeed ID 打錯，得到的會是較慢的模型。在 Kimi Code 中，輸入錯誤的 Highspeed ID 會「默默退回 K2.8 Preview，而且不會思考——毫無加速效果。」請準確複製 ID，並確認記錄中顯示的是哪個模型。
• Highspeed 只會加快模型輸出。Moonshot 表示，K3.1 Pro Highspeed 的速度約為 K3.1 Pro 的 2–3 倍，功能則完全相同。在 AIHubMix 的抽查中，其輸出速度約為 Pro 的 1.6–1.8 倍。工具呼叫和指令碼完全不會因此加快，因此若一個回合大多花在讀取檔案和執行測試上，提升就很有限；而 Kimi Code 的方案所需額度約為兩倍。

通訊協定

• 代理可能改變模型行為。Moonshot 的 Kimi Code 文件提醒：「透過代理工具進行通訊協定轉換，可能導致模型行為有所差異。」請依照各工具支援的通訊協定使用：Claude Code 用 Messages，Codex 用 Responses。10 月 24 日，AIHubMix 的四個 K3.1 Pro ID 都能透過 Chat Completions 和 Messages 回傳推理內容，分別以 reasoning_content 和 thinking 區塊呈現。Responses 在 coding channel 上可正常運作，並回傳 reasoning 項目；但在主要 ID 上則回傳前述 404。
• Messages API 的結構化輸出已有改善。在 AIHubMix 7 月對 K3 的測試中，/v1/messages 忽略了 schema，並回傳一般文字。10 月 24 日，向 K3.1 Pro 傳送類似請求，在 output_config.format 中加入 JSON schema，且提示詞沒有要求輸出 JSON，四個 ID 卻都回傳了 {"city":"Paris"}。這只是單欄位 schema，因此在將 JSON 工作負載移回 Messages 前，請先驗證輸出。7 月 Messages 的另一個特殊狀況——遇到 stop sequence 時以 end_turn 回傳，且 stop_sequence: null——本次並未重新測試。

長請求

• 逾時時間太短，連不算大的請求也會失敗。在抽查中，K3.1 Pro 以 low 產生完整回答需要 80 到 99 秒。非串流用戶端若設為 60 秒逾時，每次執行都會失敗，而重試則會再次支付相同的思考成本。Moonshot API 上，K3.1 Pro 的預設輸出上限為 131,072 個 token，最高可達 1,048,576 個 token；AIHubMix 7 月的一次 K3 遊戲建置請求則執行了 2,541 秒。請使用串流，並將逾時設為數分鐘。

沿用自 K3 指南的注意事項

以下注意事項來自 K3 指南：

• 丟棄 reasoning_content 會降低多輪對話的品質。必須原樣傳回完整的 assistant 訊息，包括 reasoning_content 和 tool_calls。只保留 content 的程式碼仍可執行，但 Moonshot 警告，輸出品質會不穩定。
• 若丟棄動態工具的訊息，工具就會消失。K3 可透過不含內容的 system 訊息，在對話中途載入工具。伺服器不會保留這類訊息，因此每次請求都必須重新傳送。在 AIHubMix 上，這可透過 Chat Completions 運作：10 月 24 日，kimi-k3.1-pro 呼叫了以此方式注入的工具。在 AIHubMix 7 月對 K3 的測試中，Messages API 則忽略了注入的工具。

容易忽略的計費規則

以下價格為 AIHubMix 模型頁面所列，每百萬個 token 的價格：

在 AIHubMix 上，K3.1 Pro 的輸入和快取輸入價格比 K3 低 30%，輸出價格則低 26%。Highspeed 的輸入和輸出價格都是 Pro 的兩倍，快取價格則相同。coding channel ID 另有獨立定價：輸入 $0.88、輸出 $3.23、快取 $0.132。

費率較低，不代表帳單一定比較少。以 AIHubMix 7 月用 K3 建置遊戲的一次提示詞為例：輸出 74,994 個 token，假設輸入 5,000 個 token。若 token 數相同，K3 費用約為 $1.08，K3.1 Pro 約為 $0.80（每百萬個 token，5,000 × $2.00 + 74,994 × $10.50），Highspeed 則約為 $1.59。token 數會因提示詞而異（抽查中，K3.1 Pro 和 K3 在 low 下的 token 數相近），因此請先測量再編列預算。

Moonshot 的 API 文件指出，K3.1 Pro 的快取寫入會依 TTL 計費，可選 5 分鐘或 1 小時，與 K3 相同。Moonshot 的上下文快取指南所列 K3 價格，說明了其計費結構：

Moonshot 表示，將快取寫入費用獨立列出，並未提高 K3 的總費用：寫入成本原本就包含在輸入價格中，因此使用預設 5 分鐘 TTL 的請求，費用與以往相同。

以上是 Moonshot 的直接定價。AIHubMix 的模型頁面只列出輸入、輸出和快取輸入價格，沒有另列快取寫入費率，也未說明 1 小時寫入的計費方式。AIHubMix 確實會傳遞 TTL：10 月 24 日，一個頂層 cache_control TTL 設為 1h 的 Messages 請求，將寫入記錄為 1 小時快取 token；而含有 prompt_cache_options 的 Chat Completions 請求也獲得接受。

• 快取會自動運作。K3 的預設 TTL 為 5 分鐘。在 AIHubMix 10 月 24 日的測試中，重複傳送含 93 個 token 的提示詞，在 coding channel 上完全命中快取，但在主要 ID 上則沒有。使用含 7,658 個 token 的提示詞時，第二次呼叫 kimi-k3.1-pro 回傳了 7,424 個快取 token，Chat Completions 和 Messages 都是如此。
• 在 Moonshot API 上，1 小時 TTL依 K3 費率計算，每百萬個 token 的寫入費用會多 $3.00。每次快取命中可省下 $2.70，因此依照 Moonshot 自己的算法，第二次命中起就能回本。
• 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 在所有推理強度下，思考 token 都按輸出費率計費。AIHubMix 沒有列出 K3.1 Pro 的獨立推理價格。

降低費用的做法：

1. 依工作負載設定 reasoning_effort，不要沿用 max。查詢和分類可試試 low，一般程式設計工作則可用 high。
2. 每個工作階段都固定使用同一個模型和推理強度；變更任一項時，請開啟新的工作階段。
3. 將穩定不變的部分放在前面：system 提示詞、工具定義、程式碼庫上下文；接著再放入每回合會變動的內容。
4. 只有在瓶頸是等待模型輸出時才使用 Highspeed；若流程主要耗時在工具呼叫，就不適合使用。
5. 留意思考 token 在完成 token 中所占的比例。若簡單任務的比例持續超過一半，請降低推理強度。

具備實際權限的 Agent

Hermes Agent 的問題說明了遷移錯誤如何演變成安全問題。它的「智慧核准」分類器呼叫 k3 時設定了 temperature，結果每次呼叫都回傳 400。依回報者的說法，分類器「每次呼叫都會升級處理（故障時開放）」：安全檢查因此失去作用，而主聊天流程看起來卻一切正常。

K3.1 Pro 保留了這個觸發條件，還新增了一個。團隊通常會透過設定較低的 temperature 或關閉思考模式，讓分類器呼叫快速又便宜；但在 K3.1 Pro 上兩種方法都行不通：設定 temperature 可能導致每次呼叫都回傳 400；在 AIHubMix 上，關閉思考模式的請求則沒有回傳推理內容。如果安全檢查使用 K3.1 Pro，請設為 reasoning_effort: "low" 以提升速度，並決定 API 錯誤發生時要如何處理，確保系統採取故障時關閉的安全做法。

對於會自主執行動作的 Agent，還有幾件事需要留意：

• 強制工具呼叫可正常運作。K3.1 Pro 支援 tool_choice: "required"，而 K2.x 不支援，因此可以移除 K2.x 時代為了強制工具呼叫而採用的替代方案。
• 內建網頁搜尋尚未達到可用於正式環境的水準（K3）。Moonshot 的 K3 指南表示，網頁搜尋「仍在更新中，近期不建議用於正式工作流程」。除非 Moonshot 另有說明，K3.1 Pro 也請比照辦理。透過 AIHubMix 使用時，K3.1 Pro 的搜尋循環在 10 月 24 日未能完成：模型要求呼叫 $web_search，但將結果送回後，回傳了 400 Invalid request: tokenization failed。
• 圖片輸入必須使用 base64。K3 不會擷取公開圖片 URL；10 月 24 日，AIHubMix 上的 kimi-k3.1-pro 拒絕了一個圖片 URL，回傳 400 Invalid request: unsupported image url，因此傳送螢幕擷取畫面連結的 Agent 會遇到錯誤。Moonshot 提供的另一種選項是使用其檔案上傳功能取得檔案 ID，但 AIHubMix 不支援：ms:// 參照回傳了 404。使用 base64 圖片則可正常運作。K3.1 Pro 在 Kimi Code 中也能接收影片輸入。

程式設計工具：Claude Code 和 Codex

Claude Code 使用 Anthropic Messages API，AIHubMix 的主要 ID 在 10 月 24 日可正常回應。Codex 使用 Responses API，只有 coding channel 可正常回應。安裝和基本設定請參閱 AIHubMix 的常設指南。以下只說明 K3.1 Pro 的變更項目。

在 Responses API 上的主要 ID 開始回應之前，Codex 欄位會使用 coding channel ID。工具傳送的任何 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 文件、其 Claude Code 指南（以 K3 為對象撰寫）和 AIHubMix 的測試，已知問題如下：

• 開始新的工作階段。不要將執行中的 K3 工作階段切換成 K3.1 Pro。請開啟新的工作階段，讓快取和輸出品質都從乾淨狀態開始。
• 未設定的層級會無聲失敗。Claude Code 會針對主要對話、摘要和子代理使用不同的層級。Moonshot 提醒，只設定其中部分層級，其他層級就會「無聲失敗」。你可以將 Haiku 層級指向較便宜的模型，處理背景工作。
• 舊設定會優先採用。 ~/.claude/settings.json 中 env 區塊的舊值會覆蓋您在 shell 中匯出的變數。
• 1M 上下文。Moonshot 的 K3 指南使用 kimi-k3[1m]，讓 Claude Code 將視窗視為 1M。透過 AIHubMix 使用 kimi-k3.1-pro[1m] 也能以相同方式運作：Claude Code 會在送出前移除後綴，而 AIHubMix 在 10 月 24 日成功回應了產生的請求，其中包含 1M 上下文標頭。只有 Claude Code 能辨識這個後綴。若從任何其他用戶端將 kimi-k3.1-pro[1m] 當成模型 ID 傳送，會收到 400。
• Effort。K3.1 Pro 的預設值已是 max，Moonshot 的 K3 指南建議搭配 CLAUDE_CODE_EFFORT_LEVEL=max 使用。一般工作使用 high 可減少 token 消耗。無論 Claude Code 傳送哪個層級，都會依照 effort 對照表映射，而 AIHubMix 測試的五種值全都接受。
• 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 就會退回使用其不認識之模型的預設中繼資料。Moonshot 的 Codex 指南（以 K3 為對象撰寫）指出，出現 Model metadata for kimi-k3 not found 警告是預期行為，且不會造成影響。
• Effort。Codex 自有的層級包括 medium 和 xhigh。根據 Kimi Code 的對照方式，它們會分別以 high 和 max 執行；AIHubMix 在 10 月 24 日也都接受了這兩種值。請設定 low、high 或 max，才能清楚掌握自己付費使用的是哪個層級。
• 不同 channel 的行為不同。coding channel 接受了主要 ID 不接受的 temperature。等主要 ID 開始在 Responses API 上回應後，請先重新執行冒煙測試，再進行切換。
• 不要使用 search_context_size。如果你的設定中有這個參數，請移除（請參閱會明確報錯的項目）。
• 編輯後重新啟動。Codex 只會在啟動時讀取 config.toml。如果 CC Switch 管理你的 Codex 設定，它可能會覆寫你的修改。

15 分鐘冒煙測試

請在每種工具中各執行一次，並選用含有測試套件的小型儲存庫：

1. 在 K3.1 Pro 上開始新的工作階段。不要延續曾使用 K3 或其他模型的工作階段。
2. 提出要求：「為這個儲存庫中的某個函式新增單元測試、執行測試，並修正任何失敗項目。」
3. 成功時應該會看到以下情況：模型會讀取檔案並執行測試（工具呼叫正常運作）。看到結果後，模型會繼續處理，這表示推理內容和工具結果有傳回模型。最後測試全部通過，而且整個工作階段中沒有任何 400 或 404。
4. 在 AIHubMix 使用記錄中，確認模型 ID 與你設定的一致，並確認後續請求中穩定前綴的輸入 token 顯示為快取命中。如果始終沒有快取命中，表示前綴中有內容每一輪都在變動。
5. 記下每輪耗時和 completion token 數量。這些數據是你選擇推理強度，以及評估 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 於 2026 年 12 月底停用 K2 系列之前，遷移 K2.x 程式碼；自 10 月 31 日起，新註冊的 Moonshot 帳戶將無法使用 K2。
• 請為 K3.1 Pro 開啟新的工作階段，不要切換舊工作階段。
• 從所有呼叫路徑中移除 temperature、top_p、n 和兩種 penalty，包括 helper 呼叫。
• 移除所有關閉思考模式的設定，包括 effort 值 off、none 和 disabled，並刪除遺留的 K2.x 思考區塊。
• effort 請設定為 low、high 或 max；medium 會以 high 執行，xhigh 則以 max 執行。
• 在同一個工作階段中，固定使用相同的模型和推理強度。
• 完全照抄 Highspeed ID，並在使用記錄中確認模型。
• stop 清單最多包含五個項目，且每個項目不得超過 32 bytes。
• 傳回完整的 assistant 訊息，包括 reasoning_content 和 tool_calls，並重新傳送動態工具訊息。
• 長請求請使用串流，並將逾時設定為分鐘。
• 將 JSON 移回 Messages API 之前，請先驗證結構化輸出。
• 更新成本追蹤設定，以納入獨立的快取寫入欄位。
• 發生 API 錯誤時，安全檢查應採取預設拒絕策略。
• 在每種程式碼工具中執行冒煙測試。

常見問題

為什麼 K3.1 Pro 會回傳 HTTP 400？
常見原因包括 temperature 不等於 1、關閉思考模式，或 effort 設為 off、none、disabled 或未知值。第一種情況是因為 K3 固定的取樣規則，而 K3.1 Pro 也沿用這項規則；其他情況則記載於 Moonshot 的 Kimi Code 文件中。10 月 24 日在 AIHubMix 的主要 ID 上，只有 temperature 會回傳 400；其他情況都回傳 200，而關閉思考模式或設為 none 時則不會傳回推理內容。

可以關閉思考模式嗎？
不行。K3.1 Pro 只能在思考模式下執行。將 reasoning_effort 設為 low，即可縮短思考時間。

設定 temperature 還是會被拒絕嗎？
是，Moonshot API 和 AIHubMix 的主要 ID 都會拒絕；在 2026 年 10 月 24 日，它們回傳了「invalid temperature: only 1 is allowed for this model」。同次檢查中，AIHubMix 的 coding channel 接受了 0.2 的 temperature。請在所有路徑中省略 temperature。

K2 模型何時會停用？
自 2026 年 10 月 31 日起，新註冊的 Moonshot 使用者將無法使用 K2 系列模型，而 Moonshot 計畫在 2026 年 12 月底前停用所有 K2 系列模型。10 月 24 日時，AIHubMix 仍列有 K2.6 和 K2.7 Code，且未公布停用日期。

為什麼我的 Kimi Code 配額消耗得更快？
K3.1 Pro 的預設推理強度是 max，而 Kimi Code 中的 K3 預設為 high；此外，Highspeed 的配額消耗約為一般模型的兩倍。一般工作請設定較低的推理強度，並在同一個工作階段中維持不變。

為什麼 Highspeed 沒有變快？
可能是 ID 拼錯了，這種情況下 Kimi Code 會無聲地退回 K2.8 Preview，且不會進入思考模式；也可能是工具呼叫佔用了大部分回合時間。Highspeed 只會加快模型輸出。

Codex 應使用哪個 AIHubMix 模型 ID？
目前使用 coding-kimi-k3.1-pro，透過 aihubmix.com/v1 上的 Responses API，並將 wire_api 設為 responses。10 月 24 日時，主要 ID 在 Responses API 上回傳 404。AIHubMix 將 coding channel 標示為評估預覽版，不適用於正式環境。

繼續閱讀：Kimi K3.1 Pro 系列

• 遷移之前，不妨先確認升級是否值得：從有哪些變更，到實際執行一項工作要花多少錢，請參閱：Kimi K3.1 Pro 與 K3 比較：有哪些變更、費用多少，以及哪些人適合切換
• 如果遷移讓你開始考慮其他選擇，這篇文章會比較 K3.1 Pro、Qwen 4 和 Claude Fable 5.5，並列出使用各模型完成一項前端建置工作的費用：Kimi K3.1 Pro、Qwen 4 與 Claude Fable 5.5 比較：前端品質、每項任務成本，以及實際檢視炒作
• 如果 Highspeed 的配額和價格讓你想知道高速版本是否划算，這篇文章專門探討速度與價格之間的取捨：Kimi K3.1 Pro 與 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 端點設定檔漂移