Anthropic 近日喺 Claude Code 上開咗「訊息線程」（message threads）：唔再每一輪都將成段對話重新上傳，只傳上一輪之後有變化嘅部分。呢個功能對大部分 Claude Code 用户預設已開，API 用户可用「thread」參數啟用。
原理簡單：以前寫程式要叫模型返工，每次請求都要喺同一個 500,000 至 1,000,000 token 嘅大 context 入面重傳全段對話，就好似同朋友 chat 每句都要連成串貼出先至嚟。開咗線程之後，只有新增部分先會傳，Anthropic 稱大型請求嘅中位 time-to-first-token（首個 token 出現嘅時間）會減低 35%。
實際快幾多？
有開發者用自身 Claude Code 日誌做估算：功能未開之前，約 980 個回合嘅數據顯示，每次 mid-task 請求後，Claude 大約 3 秒先至開始回應。過去一個月有咗幾個忙碌嘅夜晚，四個鐘內大約做 100 至 225 次模型呼叫。按 Anthropic 公佈嘅 35% 中位首 token 時間削減推算，四個鐘嘅編程會話大約省 2 至 4 分鐘。
呢個估數係基於廠商數字推算，唔係本站實測；作者同時話明，35% 係 Anthropic 嘅量度，自己冇獨立重跑。
對一般寫 code 嘅人嚟講，省兩到四分鐘唔算多；但喺企業級、需要 AI 即時回應、或者要處理大量文件同截圖嘅場景，任何 latency 削減都有價值。Anthropic 嘅 blog 話，computer-using agents 嘅截圖會「跟住 thread，唔會每輪重新上傳」。
資料圖片：Pixabay
快，唔代表平
重點嚟喇：token 消耗完全不變。模型每一輪都仲要處理成段對話，rate limit 亦冇改動，所以呢個功能唔會帶來任何成本削減。想省錢，要配合 prompt caching（提示快取，大約存在兩年，令模型避免重複處理相同 prompt）。
換句話講，message threads 只係令 Claude「反應快啲」，唔係「更聰明」——context 依然係全段 session，冇因為開咗線程就變咗。
阿調搞兩下
廠商話快 35%，第三方可照呢個數字計出每四個鐘省兩到四分鐘，但 cost 一分冇減。快唔等於平，平唔等於勁。打工仔最實係要睇：呢個省返嘅幾分鐘，係咪真係可以提早收工，定係老細會話「唔係仲快咗？做多兩份啦」。工具更新要問邊個揸住個掣、邊個食返呢個速度。
阿調｜深度調教
