Claude Code 的「首 token 延遲」大降約 3 倍。這一篇，用一條故事線講清楚：慢在哪、怎樣修好。
雲端會話最慢的一成個案，按下 Enter 後要等近 17 秒才見第一個字。
每次提問前，Claude Code 先傳約 3.28 萬 tokens 的背景資料。包袱太重。
對話負載每回合 gzip 壓縮；你打字未完，雲端會話已先啟動。
本地 4.07 → 1.33 秒；雲端 16.99 → 6 秒。等待時間大減。
用 AI 寫程式，最難受的不是它答得慢。
是你按下 Enter 之後，畫面一動也不動。
你不知道它在想，還是在卡住。
今年 4 月，Vue.js 作者 Evan You 公開抱怨：Claude Code 可以卡住幾分鐘不動。
延遲不是小毛病。當工具經常要你乾等，信任就會一點點流失。 —— 本篇整理的編輯觀察；Evan You 的抱怨見來源報導
到了 7 月，有分析拆開了流量一看，找到了線索。
原來每次你開口之前，Claude Code 已經先傳了一大包背景資料。
2026 年 7 月的分析估計：系統提示、工具定義等固定開銷。
差距約 4.8 倍。包袱越重，傳送和處理就越久。這解釋了為何基線延遲一直偏高。
Anthropic 沒有換模型。
它修的是傳送方式。
雲端會話已悄悄啟動預熱，不等你按 Enter。
整段對話先 gzip 壓縮，變小了才出發。
傳送更快、伺服器更早開工，等待大減。
對話越長，每一回合要重傳的內容越多。先用 gzip 壓縮 conversation payload，路上花的時間自然減少。
雲端會話啟動需要時間。趁你還在打字，先把會話熱身好。按下 Enter 時，它已經在等你，不用從零開始。
道理不深。
一件是把行李壓小，另一件是提早到車站。
但兩件加起來，效果以倍數計。
公布的指標是 p90 延遲。
先花十秒弄懂 p90，數字才有意思。
p90 是甚麼？把 100 次使用由快到慢排好。第 90 名的時間，就是 p90。
換句話說：十次裡有九次，比這個數字更快。它量度的是「慢的時候有多慢」，比平均數更貼近你的真實感受。
數字越短越好。資料來源：ClaudeDevs 於 2026 年 10 月 17 日公布，CryptoBriefing 報導。
四組數字方向一致。改善幅度最大的，正是原本最慢的雲端會話。
按下按鈕，兩條進度條按真實秒數賽跑（16.99 秒對 6 秒）。舊版跑完之前，新版早就完工。
提示：等舊版跑完，你會明白為甚麼用戶會失去耐性。
留意一點：6 秒仍然不是「即時」。
但由 17 秒變 6 秒，是由「想放棄」變成「可以接受」的距離。
消息在 10 月 17 日才公布，距今約一天。
截至本篇整理時，Hacker News、Reddit 與 X 上都未見成形的討論串。
四組延遲數字內部一致，倍數計算對得上，未見有人質疑數據。
目前沒有實質爭議。
唯一要註明的是來源層級：「每一回合 gzip 壓縮」這個技術細節，來自 latent.space 的二手轉述，不是 Anthropic 的一手技術文件。
延遲數字本身則由官方帳號 ClaudeDevs 公布，可信度較高。
一句總結：這次升級不花巧。
它針對最痛的那一點下手——等。
而數據顯示，它做到了。