Anthropic 表示，Message Threads 在 Claude Code 的 50 萬至 100 萬 token 請求中，首個 token 等待時間中位數約降低 35%。這是廠商公布、經媒體轉述的特定數據，並非外部團隊重現的結果。它留下幾個實際問題：改善適用哪些工作？少傳資料，帳單會跟著下降嗎？應用程式又要承擔哪些對話狀態責任？

對建置程式代理、客服代理或文件分析流程的團隊來說，答案取決於請求長度，以及服務能否保存、重建完整對話。官方 SDK 用 Acme 客服代理示範訂單與配送追問，這是 API 操作範例，不代表企業部署成效。

若要先釐清 API 在應用程式與服務之間扮演的角色，可參考從手機 App 到醫療資料交換的 API 入門。

Anthropic 文件也將電腦操作代理、文件或圖片密集工作流列為可能受益情境，但未提供各情境的獨立成效數據。另一個具體脈絡是 Claude Code 長工作階段，35% 數據限於該產品特定長度請求。以下拆解機制、效能、計費與回退設計。

Anthropic Message Threads 怎麼減少長對話的等待？

它把首次完整對話暫存在伺服器，後續只傳新增訊息和前一個回應 ID。模型仍會取得完整對話脈絡，減少的是每一輪從用戶端重送歷史的工作。

傳統 Messages API 每次都附上此前的 user 與 assistant 訊息。對話越長，請求本文越大；API 每輪也要驗證並切分完整內容。Message Threads 首次請求加入 thread: {"type": "create"}，送上完整訊息、system prompt（系統提示）與 tools（工具定義）。

回應會帶有 id。後續請求使用 thread: {"type": "continue", "previous_message_id": "上一個回應 ID"}，只附上新訊息。

這不是對話濃縮，也不是模型只看最後一句。Anthropic 說 API 會在呼叫模型前重建對話，模型仍讀取完整內容。SDK helper（封裝流程的輔助程式）能代為建立和延續 thread；自行呼叫 API 則須在每次請求帶上 beta 標頭。

首次建立時傳入的 system 和 tools 只能放在 create 請求，continue 再傳，即使值為空，也會收到 400 錯誤。

Anthropic 文件的客服範例是較容易看懂的操作案例：第一輪詢問訂單，第二輪追問標準配送時間；第二輪只帶新問題和第一輪回應 ID，system prompt 與工具設定沿用原 thread。文件也說明，這是 SDK 用法示範。開發團隊可用同一流程理解 coding agent（程式代理）或跨多輪工具呼叫的狀態延續，但不能把範例當成該類系統已取得某種速度或成本成效。

35% 的首個 token 改善適用在哪些請求？

這個數字指 Claude Code 中 50 萬至 100 萬 token 請求的首個 token 等待時間中位數，不能直接套用到較短對話或其他工作負載。

首個 token 等待時間（time to first token，TTFT）是送出請求到模型開始回傳第一個 token 的時間。Anthropic 文件指出，不用 thread 時每輪重新上傳、驗證和切分整段對話；使用後，前置處理多半只涉及新一輪內容。

The Decoder 轉述 Anthropic 的數字：50 萬至 100 萬 token 請求的 TTFT 約降 35%。公開資料未交代足以重現結果的完整測試方法、網路條件、負載分布和快取設定，因此這是特定場景的廠商效能訊號，不是採購預估值。

長時間執行的程式代理可能反覆帶上程式碼、工具結果和先前討論；電腦操作代理可能在多輪中產生螢幕畫面；文件或圖片密集的工作流也可能累積很長的上下文。Anthropic 文件將這些列為 thread 可能較有幫助的情境，但沒有逐類公布獨立效能數據。它們能說明哪裡值得測，不足以證明每個團隊都能得到相同改善。

Anthropic 文件指出：「對話越長，首個 token 等待時間越低、越穩定。」這是產品文件對功能效果的說明，實際幅度仍須在自己的流量和系統條件下驗證。

圖表以單一數字標示 Claude Code 50 萬至 100 萬 token 請求的 TTFT 中位數改善約 35%，並註明其他工作負載沒有獨立公布數據。
約 35% 是 Anthropic 對特定超長 Claude Code 請求公布的中位數，其他工作負載仍須自行測量。

少傳訊息是否代表 Anthropic API 帳單也會下降？

不能由傳輸量減少推論費用按相同比例下降；Anthropic 說 Threads 不改變定價或 rate limits，Claude 仍會讀取完整對話。

要把三種指標分開看：用戶端到 API 的網路傳輸量、模型實際處理的輸入 token，以及從送出到開始回應的延遲。Threads 直接改變的是每輪傳給 API 的請求內容和重複驗證、切分工作。Anthropic 的定價仍依模型與功能計費；官方文件明確寫出 Threads 不會改變價格或速率限制。若要算實際成本，仍須檢查用量報表中的輸入、輸出與快取 token，而非用封包縮小幅度代替費用估算。

Anthropic 對 Claude Code 的觀察，回答的是超長請求的等待時間，不是所有 API 客戶的帳單降幅。譬如客服機器人每輪只多一兩句、對話總長有限，節省的傳輸可能很有限；相反，長時間代理工作有大量工具回覆和附件，較值得測試是否改善回應啟動速度。這兩個工作場景是評估方向，公開資料沒有提供可供直接比較的個別成本結果。

若評估程式代理的 token 用量與成本，也可對照程式代理 token 節省幅度的驗證方式；不同工具的結果仍須依自身工作負載測量。

若產品同時使用 prompt caching（提示快取），應另行確認 cache breakpoint（快取切點）設定。官方文件說 thread 後續每輪仍只傳新增訊息，但沒有自行設定快取切點時，不代表後續歷史內容會因 thread 自動享有快取。Thread 和快取是可分別驗收的機制，不能把一項的收益算到另一項名下。

Thread 遺失或設定改變時，系統如何接續？

應用程式必須自行保存每一輪訊息與回應 ID，遇到 404 就用完整對話建立新 thread；改動固定欄位也要重新建立。

Thread 是短期、盡力提供的伺服器端狀態。官方文件說，它在最後一次請求後 5 分鐘到期，且最後使用後最遲一小時刪除；若 continue 找不到狀態，API 回傳 thread_not_found，應用端需重送完整對話並以新回應 ID 接續。API 不提供列出、讀取或刪除 thread 的端點，因此 thread ID 本身不能取代產品自己的對話資料庫。

其他錯誤也有各自的修復方式。每個回應 ID 只能延續一次；從舊 ID 重送，可能得到 thread_already_continued。若同一 ID 的 continue 尚未結束又送一次，會得到 thread_continue_in_flight。

model、thinking、tool_choice、快取設定與 beta 標頭等欄位須維持建立時的值，否則會回 thread_fingerprint_mismatch；system 和 tools 僅能在 create 時傳入。設定要變更，就用完整對話開新 thread。

工具呼叫也有狀態順序：上一個回應若要求執行工具，下一輪新增訊息須包含對應的 tool_result，並從該回應 ID 延續。API 不會替應用端移除重複舊訊息，可能把它再加進對話或回錯。

SDK helper 會在部分 thread 錯誤時重播完整對話一次，但副本只留在 helper 物件的記憶體中。程序重啟或服務切換後，仍須從應用端保存的紀錄復原。這項狀態管理責任不能交給短期伺服器暫存。

Anthropic 文件提醒：「你的應用程式仍是對話的事實來源。」它要求服務保存自己的訊息副本，並預先準備重播路徑。

流程圖呈現應用程式保存完整對話與最新回應 ID，遇到 thread 找不到或固定欄位改變時以完整紀錄建立新 thread，並阻止同一回應 ID 併發延續。
Thread 是短期狀態，完整對話紀錄與安全接續流程仍須由應用程式負責。

Beta、資料保留與整合限制適合哪些系統？

仍在 beta 的 Threads 不符合 ZDR（零資料保留）與 HIPAA 資格；有這類要求的組織應先確認能否使用，並將資料留存條件納入架構審查。

Anthropic 表示，thread 內容、system prompt 與 tools 會加密暫存在伺服器記憶體，不寫入耐久儲存，並在最後使用後不超過一小時刪除。這不等於零資料保留：功能頁明列不符合 ZDR，也不符合 HIPAA 資格。

涉及健康或其他敏感資料的團隊，不能只憑「記憶體暫存」判斷符合內部政策；仍要檢查資料分類、處理目的、權限、日誌遮罩和合約條件。

功能面亦不支援部分 context management（上下文管理）、compaction（對話壓縮）、Message Batches、token counting 和組織設定。要壓縮對話，須由應用程式整理摘要，再用摘要建立新 thread。

服務若需列舉或調閱伺服器端對話，目前沒有對應 API。官方列出 Claude API、Anthropic 管理的 AWS、Google Cloud 與 Microsoft Foundry；部署前仍要核對供應商支援狀態。

真正的取捨在於：長代理流程可能從減少歷史重傳獲得較快的請求啟動，但產品同時得管理本地紀錄、最新 response ID、固定參數、逾時重播和敏感資料。若系統做不到可靠保存，少送幾 KB 或數 MB 的請求，並不能抵銷對話中斷或重複執行工具的風險。

導入前如何做效能與狀態管理驗收？

用相同對話、模型、提示與負載建立傳統請求和 Threads 對照組，同時追蹤延遲、token、費用、錯誤和重播結果。

  1. 挑選代表性的短、中、長對話，固定模型、提示、工具、輸出上限與併發負載，分別執行傳統請求和 thread 流程。
  2. 記錄每輪 TTFT、完整回應時間、請求本文大小、輸入與輸出 token、快取使用、錯誤率和實際帳單；同時標示對話長度及工作類型。
  3. 注入逾時、服務重啟、重複送出舊訊息、同一回應 ID 併發延續、固定欄位變更與工具回覆等情境，確認系統能辨識錯誤並從完整紀錄建立新 thread。
  4. 演練停止 Threads 後的傳統請求回退，核對消息順序、工具結果與應用端資料一致，再由合規負責人確認 ZDR／HIPAA 和組織資料政策。

這套對照測試也能分辨改善來自哪裡。若 TTFT 變短但完整回應時間未改善，瓶頸可能在生成或下游工具；如果請求變小但輸入 token 和帳單近似原值，則符合「少傳輸、不等於少計費」的預期。最後比較不同長度和負載下的分布，不只看平均數，也看中位數與較慢的一端。Anthropic 的 35% 數字可作為待檢驗假設，不能代替自身驗收。

  • Message Threads 首次送完整上下文，後續只送新增訊息和上一個回應 ID。
  • Anthropic 公布的約 35% TTFT 改善限於 Claude Code 的 50 萬至 100 萬 token 請求，尚非獨立重現結果。
  • API 帳單不會因 Thread 自動按傳輸量下降；應用端要保存完整對話並準備逾時重播。
  • Beta、ZDR／HIPAA 資格及資料處理政策，是效能測試以外的導入條件。

常見問題

Q1：Anthropic Message Threads 會降低 API 費用嗎？

不一定。官方表示定價與 rate limits 不變，Claude 仍處理完整對話；實際帳單要依 token 用量和快取狀況核對。

Q2：Thread 逾時後，對話紀錄還在嗎？

伺服器端 thread 可能無法延續，且沒有列出或讀取 thread 的 API。應用程式要保存自己的完整訊息，在 404 時建立新 thread。

Q3：Message Threads 可用於符合 HIPAA 的流程嗎？

Anthropic 目前將 Message Threads 標示為不符合 HIPAA 資格，也不符合 ZDR。若組織有相關要求，須先按合約與政策確認可用範圍。