Anthropic 於 11 月 2 日在 Claude Platform 上開放 message threads 公開測試。開發者只要在 Messages API 請求中加入一個 thread 參數，第一輪送出完整對話，之後每輪只需送出新增訊息與上一則回覆的 ID，伺服器端負責把對話重新組合起來。
官方提出的數字來自 Claude Code。這項功能已在多數 Claude Code 使用者端預設開啟，50 萬到 100 萬 token 的請求，首 token 時間的中位數下降約 35%。其他長度區間的成效，部落格並未列出。
公開測試涵蓋 Claude API、Claude Platform on AWS、Microsoft Foundry，以及 Google Cloud 上由 Anthropic 代管的 Claude。文件列出的可用模型，從 Sonnet 4.5、Opus 4.5 一路到 Fable 5.1 與 Mythos 5.1。
省下的是驗證與分詞
沒有執行緒時，代理程式每跑一輪都得把整段對話重新上傳一遍，API 也要重新驗證、重新分詞。對話愈長，這段前置作業就愈久，進行電腦操作的代理程式尤其吃虧，歷史截圖每輪都得再傳一次。
執行緒先把這些內容放在伺服器記憶體中，處理量基本上只剩新增的那一輪。
Claude 每輪仍要讀完整段對話，因此模型端的 token 不會變少，計費與速率限制都沿用現行規則。可以粗估一下：一段 80 萬 token 的對話，每輪新增 2000 token，改用執行緒後，請求中要傳送的內容約為原來的四百分之一，帳單上的輸入 token 卻依然是 80 萬出頭。想省錢仍得靠提示快取，那是另一個開關：執行緒請求的頂層可以加上 cache_control，沒加的話，即使只送新增訊息，也不會有任何內容被快取。
導入時要留一條退路
文件把執行緒定義為「盡力而為」，這決定了串接方式。
- 過期：執行緒在最後一次請求後 5 分鐘過期，每次儲存回覆都會重新計時，最晚在最後一次使用後 1 小時刪除。
- 失效：後續請求一旦回傳 404，就得把完整對話重送一遍，並開啟新的執行緒。回傳結果不會告訴你這一輪有沒有存成功，要等到下一次後續請求才會知道。
- 副本：對話的權威版本仍在應用程式這一側。官方 SDK 的輔助工具會在記憶體中留一份並自動重播，程序結束就消失，需要跨程序的話得自行儲存。
- 固定欄位：
system與tools只在建立時送出，後續請求中帶上，哪怕是 null 也會回報 400。model、thinking、tool_choice、mcp_servers等欄位每輪都要原樣重送，改了就會回傳thread_fingerprint_mismatch。想換系統提示或工具，只能開新的執行緒。
合規上也有一項限制。執行緒內容在記憶體中加密保存，不寫入持久儲存，但這項功能不符合零資料留存（ZDR）的條件。簽了 ZDR 的企業，其他功能不受影響，唯獨執行緒這一項無法使用。
另外，開發者要留意區分：Claude Managed Agents 裡也有 session threads，與這次的 message threads 是兩回事。
補上的一塊拼圖
OpenAI 的 Responses API 很早就有 previous_response_id，同樣是傳一個 ID 來接續上文。Anthropic 這邊長期要求用戶端每輪都帶完整歷史，好處是無狀態、實作直白，代價則是對話變長後的延遲。這次的做法是個折衷：狀態只在伺服器端短暫停留，遺失了就重播，用戶端的副本一份都不能少。
從官方列出的適用情境來看，長時間執行的程式開發代理、電腦操作代理，以及文件與圖像密集的工作流程是主要對象。Anthropic 也是先在自家 Claude Code 上預設開啟，再開放給 API 使用者。
至於短於幾十萬 token 的一般對話能獲得多少提升，官方並未提供數字；文件只說執行緒在長時間的代理程式迴圈中幫助最大。自行打造代理程式的團隊，不妨先用自己的對話長度分布測一輪，再決定是否要為這條 404 重播路徑多寫一層程式碼。
參考來源：Claude 官方部落格、CocoLoop、Claude Platform 開發文件；延遲降幅以官方公布的 Claude Code 中位數為準，粗估部分為編輯推算。