Anthropic API 文件說明訊息串列 Beta：後續請求只需傳送新訊息

Anthropic 的 Messages API 文件介紹一項可將對話狀態保存在伺服器上的訊息串列 Beta 功能。使用者後續發出請求時，可只傳送新訊息與先前的回應 ID，無須重新傳送完整對話。

Anthropic 的 API 文件將 thread 定義為選用參數。首次請求指定 create 後，系統會保存與回應 ID 連結的對話狀態；後續請求加入 continue 和 previous_message_id，便可從該狀態接續對話。

使用現有的 Messages API 延續對話時，開發者須將先前使用者與 Claude 的訊息一併放入 messages 陣列。訊息串列是可選功能，可取代這個步驟；未使用該功能的請求仍可沿用原本的陣列方式。

後續請求省略過往訊息，可以縮短請求本文，但不代表模型處理的上下文或推理時間也會減少。官方文件未提供首個回應 token 時間（TTFT）的改善幅度基準測試。

這項功能的 Beta 識別碼為 message-threads-2026-08-12。開發者須將此值放入 API 請求的 anthropic-beta 標頭，以啟用功能。

Beta 功能尚未正式納入 API。若所屬組織沒有使用權限，請求可能回傳 400 錯誤；功能是否提供、費用與呼叫限制也可能因地區而異。

GitHub 上一則 Claude Code 議題的作者在 10 月 16 日回報，請求在 270 秒後仍能接續，但 360 秒後發出的 continue 請求則回傳 HTTP 404 thread_not_found。作者表示，Claude Code 隨後改以 create 請求重試，並重新傳送完整對話，因此多了一次往返。

作者也表示，即使將含有 7.9k token 的系統前綴提示快取 TTL 設為 1 小時，360 秒後仍出現相同錯誤。這是單一使用者的重現案例，並非 Anthropic 公布的通用到期標準。

另一則 GitHub 議題的作者回報，在同時使用訊息串列與對話中途的系統訊息時，$.model.fork 請求沒有重用提示快取。作者表示，移除這兩項條件中的任一項後，便未再遇到相同問題，但無法確認原因是否出在伺服器端。

這兩則 GitHub 議題都是使用者在特定條件下提出的回報。Anthropic 的官方說明並未訂定所有訊息串列請求的到期時間或快取行為。