Anthropic 於 2026 年 11 月 5 日宣布，Claude Platform 的 message threads 進入公開測試階段，開發者在 Messages API 加入 thread 參數後，agent 每一輪只需傳送自上次請求以來的新訊息，毋須重發整段對話歷史[1]。官方數據顯示，大部分 Claude Code 用戶預設開啟此功能後，50 萬至 100 萬 token 的請求，首字延遲（time to first token）中位數下降約 35%。
運作方式
使用 message threads 時，第一個請求仍然包含完整對話，並同時建立一條 thread。之後每個請求只帶新訊息，以及上一個回應的 ID，伺服器會據此接上原有的對話脈絡[1]。這改變了過去每次請求都要把全部訊息與工具結果重傳一遍的做法。
在兩輪請求之間，thread 存放於伺服器記憶體，內容加密，不會寫入磁碟。最後一次請求之後 5 分鐘，thread 便會過期；客戶端其後需要重發完整對話，重新建立一條新 thread。這個設計意味 message threads 針對的是活躍中的 session，而非可以隨時隔幾小時再接續的長時間任務。
延遲從何而來
一個編碼 agent 在單一 session 內可能發出數百個請求，每個請求都附帶先前的所有訊息與工具結果。當對話累積到幾十萬 token，單是重傳與處理這些內容的時間，就已經落在 Claude 開始回應之前[1]。message threads 削減的正是這一段前置開銷：請求本身變小，網絡傳輸與前置處理隨之減少。
值得注意的是，token 用量並無改變。Anthropic 明確指出，Claude 在每一輪仍然會讀取完整對話，因此節省的只是延遲，而非成本[1]。對於按 token 計費的團隊而言，這代表同樣的賬單可以換來更快的首字回應，對互動式工具的體驗有直接幫助。
適用場景
官方列出三類最受益的工作負載。第一是長時間運行的編碼 agent，每次工具結果或檔案修改都會令對話增長，重傳成本逐輪累積。第二是電腦操作（computer use）agent，截圖可以留在 thread 之內，不必每一輪重新上載。第三是文件與圖片密集的流程，請求體積因此大幅縮小[1]。
共通點是上下文越多，message threads 的效果越明顯。反過來說，短對話或單次查詢的改進有限，開發者不宜期望在所有情境都見到三成以上的延遲跌幅。
供應情況與接入
message threads 現已在原生 Claude Platform 提供公開測試，同時覆蓋 Claude Platform on AWS、Claude in Microsoft Foundry，以及 Google Cloud 上的 Claude 模型（由 Anthropic 管理）[1]。收費按標準 Claude token 價格計算，現有的速率限制亦同樣適用，並未因新功能而放寬。
對正在建立長時間代理的團隊而言，這項功能的吸引力在於改動極小：只需在請求加入一個參數，毋須重構對話管理邏輯，亦不必自行維護摘要或壓縮策略。對於已經因為延遲而被迫縮短上下文、犧牲連貫性的產品，這提供了一條不用增加成本的折衷路線。
參考資料
[1] Make long-running agents faster with message threads（2026年11月5日）