Anthropic API 2026-10-21：temperature 設為 1.0 也回傳 400

Claude 請求若使用 API 版本 2026-10-21，只要設定 temperature、top_p 或 top_k，就會回傳 HTTP 400，連預設值也不例外：temperature: 1.0 會得到「temperature: Extra inputs are not permitted」。這些取樣參數用來控制模型選擇下一個 token 時的隨機程度。API 版本由請求標頭 anthropic-version 指定，決定 Messages API 如何驗證及回應請求；舊版值為 2023-06-01。Anthropic 在 10 月 21 日同步發布的 SDK 主版本，包括 Python 2.0.0、TypeScript 1.0.0 及另外五個 SDK，預設都會傳送新版值。這些 SDK 已完全移除取樣參數，因此會遇到 400 的是自行組合請求本文的程式碼，例如直接發送 HTTP 請求的用戶端，或額外加入本文欄位的程式。我們在 Claude Sonnet 4.6 和 Claude Sonnet 5.5 上，用兩個 API 版本測試了八種請求格式，也比較了兩個 Python SDK 版本，並透過 Synthorai 重跑測試。

TL;DR

• 使用 2026-10-21 時，Claude Sonnet 4.6 和 Sonnet 5.5 都會對 temperature、top_p 和 top_k 回傳 400，包括 temperature: 1.0。
• 2026-10-21 也會拒絕 assistant 訊息中的 document 區塊，以及 user 文字區塊上的 citations。
• Anthropic 的 Python SDK 2.x 透過 Authorization: Bearer 傳送金鑰；請求若同時帶有兩種標頭，API 會使用 x-api-key。
• 透過 Synthorai，兩個 SDK 版本發出的全部 32 筆請求都回傳 200，包括 Anthropic API 在 2026-10-21 下會拒絕的 12 筆。

API 版本 2026-10-21 會對哪些請求回傳 400？

造成 400 的變更共有五項：三個取樣參數、直接放在 assistant 訊息中的 document 區塊，以及 user 訊息文字區塊上的 citations。citations 是文字區塊指向文件段落的引用資訊。下表將這些變更整理為六個失敗案例，再加上兩個仍可通過的案例。我們針對每個模型與版本，將各案例直接送到 Anthropic API 一次。200 表示請求已接受；400 表示請求遭拒，錯誤類型為 invalid_request_error。

新版的錯誤訊息如下：

Claude Sonnet 5.5 在 2023-06-01 下就已拒絕非預設的取樣值，但錯誤訊息不同（「`temperature` is deprecated for this model.」），而且仍接受 temperature: 1.0。到了 2026-10-21，參數本身已被移除，因此連預設值也會失敗。Claude Sonnet 4.6 在舊版下則接受所有測試案例。Anthropic 的遷移指南指出，相同規則也適用於 token 計數，以及 Message Batch 中的每筆請求。Batch API 可用較低價格非同步執行大量請求。指南沒有列出 2023-06-01 的終止日期。

各種 400 錯誤要怎麼修？

移除三個取樣參數，將文件移到 user 訊息，並移除以 user 身分傳送的文字上的 citations。不帶取樣參數的請求會使用預設值取樣，包括 temperature 1.0，這與 2023-06-01 下不帶這些參數的行為相同。Claude 先前回覆上的引用資訊，以及文件上的 "citations": {"enabled": true}，仍可使用。

使用 Python SDK 時，以下請求可在兩個版本下執行：

import anthropic

client = anthropic.Anthropic()  # 2.x sends anthropic-version: 2026-10-21

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    # no temperature, top_p or top_k: the parameters no longer exist in 2.x
    messages=[{"role": "user", "content": "Summarize this memo in one sentence."}],
)
print(message.content[0].text)

如果某筆請求需要非預設的 temperature，而模型也仍支援，例如 Claude Sonnet 4.6，就必須繼續使用舊版。直接透過 HTTP 呼叫時，要自行設定標頭：

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256, "temperature": 0.2,
       "messages": [{"role": "user", "content": "Pick a number from 1 to 100."}]}'

Anthropic SDK 有哪些變更？

預設傳送 2026-10-21 的 SDK 主版本包括 Python 2.0.0、TypeScript 1.0.0、Go 2.0.0、Java 3.0.0、C# 13.0.0、PHP 1.0.0 和 Ruby 2.0.0。除了 API 版本，這些版本也改變了金鑰的傳送方式，以及單一用戶端可持有的認證資料數量；授權條款則從 MIT 改為 Apache 2.0。我們安裝了 Python SDK 1.17.0（最後一個 1.x 版本）和 2.3.0，將兩者都指向本機的 echo 伺服器，記錄收到的每筆請求標頭與本文：

Python SDK 在 1.0.0 就已從訊息方法中移除 temperature 引數，因此 Python 使用者只有透過 extra_body，或使用自行組合請求本文的 HTTP 用戶端與程式庫，才會遇到伺服器端的 400。extra_body 是 SDK 用來在請求本文加入原始欄位的選項。兩個 API 版本都接受 Bearer 標頭：只帶 Authorization: Bearer <key> 的請求，在 2023-06-01 下也回傳 200，因此認證方式與 API 版本可以分開遷移。

同時傳送兩種標頭時，請求會使用哪把金鑰？

請求同時帶有兩種標頭時，Anthropic API 會使用 x-api-key。我們在兩個版本下測試了五種標頭組合：

放在 Claude 前面的代理伺服器或閘道，可能會與 API 對同一筆請求使用哪把金鑰有不同判斷。使用 SDK 2.x 時，透過 extra_headers={"X-Api-Key": other_key} 加入第二把金鑰的程式碼，現在會送出兩把金鑰：Authorization 裡是用戶端的金鑰，x-api-key 裡則是另一把金鑰。Anthropic API 使用 other_key 驗證請求，但只讀取 Authorization 的代理伺服器會認定請求使用了用戶端的金鑰，導致個別金鑰的配額、日誌與支出上限歸到錯誤的金鑰。指南建議的用戶端修正方式，是改用 Authorization: Bearer <other_key> 傳送第二把金鑰。代理伺服器端則應讀取兩種標頭，並遵循 API 的優先順序（先用 x-api-key），或拒絕兩個標頭帶有不同金鑰的請求。

移除 temperature 會失去什麼？

對原本依賴 temperature: 0 的團隊來說，移除 temperature 的影響可能比預期小。遷移指南指出，Claude 4.7 及後續模型本來就只接受預設值，因此不受影響。對 Claude Sonnet 4.6 這類仍接受其他值的模型，如果原本透過降低 temperature 讓輸出更穩定，移除後就會失去這個效果，也沒有其他設定可以取代。我們測量了這個效果有多大：在 2023-06-01 下，對 Sonnet 4.6 的每種設定各送出 20 筆請求，每筆都附上隨機請求 ID，確保沒有兩筆請求完全相同。

在這些短回答中，Sonnet 4.6 使用預設 temperature 時，輸出的集中程度與設為 0 差不多，因此移除 temperature: 0 的影響不大。temperature: 0 本來也不保證結果完全一致：20 次測試中仍出現了兩個不同數字。提示詞文字對輸出的影響比這個設定更大：沒有附上請求 ID 時，最常見的答案是 42（temperature: 0 下，20 次中出現 17 次）；附上後則變成 47。若需要可重現的輸出，應在程式中比對答案或使用快取；取樣參數原本就無法提供這項保證。

Synthorai 如何處理 API 版本 2026-10-21？

Synthorai 接受兩個 API 版本與兩個 SDK 版本的請求，因此升級至 SDK 2.x，或傳送 anthropic-version: 2026-10-21，都不會讓原本可用的請求失敗。我們透過 Synthorai，對兩個模型重跑了 16 種測試情境，並分別使用兩個 anthropic-version 值：全部 32 筆請求都回傳 200，包括 Anthropic API 在 2026-10-21 下會拒絕的 12 筆。Python SDK 1.17.0（傳送 x-api-key）和 2.3.0（傳送 Authorization: Bearer）都能使用 base_url="https://synthorai.io" 與同一把金鑰，透過 extra_body 傳入 temperature 也可以。

Synthorai 採取這種處理方式有四個原因：

• 同一模型可由多個平台提供。Claude 模型可透過 Anthropic API、Amazon Bedrock 或 Google Cloud Vertex AI 提供，各平台接受的版本字串不同。Synthorai 會傳送各平台預期的版本，因此用戶端的 anthropic-version 標頭不會決定請求的驗證方式。
• 遷移期間會同時存在新舊用戶端。團隊通常逐一升級服務，因此同一個帳號可能連續幾週同時從 SDK 1.x 傳送 2023-06-01，從 SDK 2.x 傳送 2026-10-21。同時接受兩者，各服務就能依自己的時程遷移，同一把金鑰也能搭配兩個 SDK 的認證標頭使用。
• 只換模型，不改程式碼。原本為 Claude Sonnet 4.6 設定 temperature: 0.2 的程式碼，將模型名稱改為不接受此參數的 Claude Sonnet 5.5 後仍可執行，不會因切換模型而失敗。
• 不因預設值而拒絕請求。temperature: 1.0 本來就是模型使用的值，拒絕它只會讓請求失敗，不會改變輸出。

代價是，回傳 200 不代表每個參數都生效。Sonnet 5.5 只接受預設取樣值，因此透過 Synthorai 傳送 temperature: 0.2 雖然會成功，卻無法降低模型的隨機程度。如果輸出依賴某個取樣值，請用自己的提示詞比較有無設定時的結果；上述測試發現，它對短回答的影響很小。

升級前該檢查什麼？

常見問題

為什麼我的 Claude 請求會出現「temperature: Extra inputs are not permitted」？ 請求使用了 anthropic-version: 2026-10-21，這個版本已移除 temperature 參數，因此任何值都會回傳 400，包括 1.0。新版 SDK 主版本預設會傳送這個 API 版本。請移除參數；若模型仍接受非預設值，而且請求確實需要，就將該筆請求固定在 2023-06-01。

anthropic-version 2023-06-01 要停用了嗎？ Anthropic 尚未公布 2023-06-01 的終止日期：遷移指南與 10 月 21 日的 API 版本說明都沒有列出。明確設定此標頭的請求會保留舊版行為，因此個別請求仍可在 Claude Sonnet 4.6 上繼續使用 temperature。

Anthropic API 還接受 x-api-key 標頭嗎？ Anthropic API 的兩個版本都接受 x-api-key 與 Authorization: Bearer，改變的只有 SDK 預設傳送哪一種。兩種標頭同時存在時，API 會使用 x-api-key。

延伸閱讀

• Claude Sonnet 5.5 費用：與 Sonnet 5 相比的模型費用
• LLM 思考控制設定：較新的 Claude 模型仍接受哪些推理設定
• OpenCode 資安事件：保護 API 金鑰：限制外洩金鑰能造成的影響
• LLM API 速率限制：個別金鑰的限額如何計算

← 返回部落格