Claude Code 首 token 等待 p90 从 4.07 秒降到 1.33 秒：gzip 与云会话预热
Anthropic 公布 8 月至 10 月的延迟优化：本地 Claude Code 首 token 等待 p90 从 4.07s 降到 1.33s，云会话 16.99s 降到 6.00s，改动在模型之外。
2026-10-19 · anthropics/claude-code 官方仓库 issue #90457（一手核对）；延迟数字经官方 X 账号 ClaudeDevs 公布、由多家二手媒体转录
发布 2026-10-19核实 2026-10-19要点速览
- Anthropic 公布了一组 8 月至 10 月的延迟优化结果：本地 Claude Code 会话的首 token 前等待 p90 从 4.07 秒降到 1.33 秒（约 3 倍）；云会话从 16.99 秒降到 6.00 秒（约 2.8 倍）。
- Claude 网页版与 Cowork 的 p90 从 3.36 秒降到 2.17 秒（约 1.5 倍）；Claude API 的 p50 首 token 时间（含模型计算时间）从 1.53 秒降到 1.01 秒。
- 口径不同，不能横向比：前三组不含模型计算时间，API 那组含。
- 两项改动都在模型之外：① 自 CLI v2.1.300（2026-10-14 发布）起，发往
api.anthropic.com的大请求默认 gzip 压缩（遥测关闭时同样生效）；② 云会话在你开始打字时就开始预热，而不是等你提交之后。 - 可关：
CLAUDE_CODE_GZIP_REQUEST_BODIES=0。企业代理如果处理不了 gzip 请求体，这是排查开关。 - 本站一手核到的关键限定：官方仓库 issue #103218「Opt-in gzip request bodies for Bedrock, Vertex and custom base URLs」仍处于 open 状态——也就是说当前默认 gzip 落在
api.anthropic.com这一条路上，走 Bedrock / Vertex / 自定义 base URL 的团队很可能吃不到这次优化。 - 来源口径：延迟数字由 Anthropic 官方 X 账号 ClaudeDevs 公布，本站未取得官方长文公告页，数字经多家二手媒体转录且转录值一致；公布日期在不同来源中被记为 10-16 与 10-17 两种，本站不作裁定。
① 数字怎么读：先分清「含不含模型时间」
| 场景 | 优化前 | 优化后 | 倍数 | 是否含模型计算时间 |
|---|---|---|---|---|
| 本地 Claude Code 会话 | 4.07 s | 1.33 s | ≈3x | 不含（p90） |
| 云 Claude Code 会话 | 16.99 s | 6.00 s | ≈2.8x | 不含（p90） |
| Claude 网页版 / Cowork | 3.36 s | 2.17 s | ≈1.5x | 不含（p90） |
| Claude API | 1.53 s | 1.01 s | ≈1.5x | 含（p50） |
这张表最容易读错的地方是最后一行。 前三行度量的是「你按下回车到模型开始吐第一个字之间，有多少时间是纯粹被网络、序列化、会话启动吃掉的」——模型想多久不算在内。API 那行是 p50 且包含模型计算时间，所以 1.01 秒这个数看起来比本地 Claude Code 的 1.33 秒还小，但两者完全不可比。
对开发者的实际含义：本地会话从 4 秒多降到 1.3 秒，改的是「问一句等一句」这种高频短循环的体感。云会话从 17 秒降到 6 秒，改的是「我还要不要盯着它」这个决策——17 秒足以让人切走标签页，6 秒通常还留在原地。
② gzip 为什么能砍掉这么多：因为每轮都在重传整段对话
这轮优化的技术背景值得讲清楚，因为它解释了一个长期被忽略的成本：
Claude Code 每一轮都会把完整对话、文件片段与工具定义重新上传一次。 长会话下单个请求从几百 KB 到超过 1 MB 是常态——上行带宽窄的环境（家用宽带、酒店网络、跨境链路）尤其吃亏。
官方仓库 issue #90457「FEATURE Compress API request bodies with gzip by default」（创建于 2026-08-28，状态 open）正是这条改动的载体。社区在该议题下的实测称：真实请求体压缩比约 2.1 倍，有机器在约 3 小时内省下 185 MB 上行。
该实测为议题下的社区测量，非 Anthropic 官方数据，本站列为待核实。
一条必须说清的边界：gzip 压的是线路上的字节，不是计费 token。 官方与转录来源都明确这一点（"Gzip shrinks bytes on the wire, not billed tokens"）。别指望它能省钱，它省的是时间。
③ 云会话预热：把启动开销藏进你打字的时间
第二项改动更取巧：云会话不再等你提交后才启动容器，而是在你开始打字时就开始预热。
这是纯粹的延迟隐藏，不是消除。 启动开销没有消失，只是被挪进了「人还在敲字」的那段窗口。代价也很直接——它会为你可能永远不提交的 prompt 预先起算力。
本站的判断：对云会话这种 17 秒量级的开销，这个交易是划算的；但它也意味着你的云算力账单里会多出一部分「预热但未提交」的消耗。有成本对账需求的组织，值得留意这一点。
④ 你现在该做的三件事
- 确认版本 ≥ v2.1.300。 gzip 默认压缩是这一版引入的，Claude Code 工具卡里有完整的版本序列与升级注意事项。
- 走代理 / 网关的团队，先验证你的中间设备能处理 gzip 请求体。 出现请求失败或返回异常时，用
CLAUDE_CODE_GZIP_REQUEST_BODIES=0关掉对比一次，即可定位是不是压缩引发的。 - 走 Bedrock / Vertex / 自定义 base URL 的，先不要预期这次优化。 见下节。
⑤ 最容易被漏掉的一条：这条路线的 gzip 覆盖可能不全
这是本站本轮一手核到的、其他转录报道都没提的点。
在 anthropics/claude-code 官方仓库中，与压缩相关的议题共有三个（经 GitHub Issues API 一手核对）：
| Issue | 标题 | 状态 |
|---|---|---|
| #90457 | FEATURE Compress API request bodies with gzip by default | open（创建于 2026-08-28） |
| #103218 | FEATURE Opt-in gzip request bodies for Bedrock, Vertex and custom base URLs | open |
| #102929 | FEATURE Accept zstd request bodies: smaller than gzip and 7x faster; cross-turn prefix deltas cut request bytes ~100x | open |
#103218 仍在 open，说明「Bedrock / Vertex / 自定义 base URL 也支持 gzip」这件事在提出者看来尚未落地。 换句话说：
- 直连
api.anthropic.com→ 默认 gzip 生效，能吃到本地 4.07s→1.33s 这档优化。 - 走 Amazon Bedrock / Google Vertex / 自建网关或第三方中转 → 大概率仍是未压缩的请求体，上行开销照旧。
这一点对国内用户尤其重要——国内大量使用者是通过第三方 API 中转接入 Claude Code 的（详见 Claude Code 工具卡 的国内使用一节）。如果你的 base URL 不是官方域名，这次「3 倍提速」可能与你无关。
本站的措辞保留：issue 处于 open 状态不等于功能一定未实现（议题可能在实现后未关闭）。本站未逐行核对 Claude Code 源码确认最终落地状态，故此处只作「很可能未覆盖」的提示，并列入待核实。
AI 之家 观点
第一，这组数字最值得注意的地方是：它们不是靠换模型拿到的。 过去两年行业习惯把体验改善绑定在「更强的模型」上，而这次的 3 倍提速来自压缩每轮重复上传的对话体和把容器启动藏进打字时间——两件纯粹的系统工程。本站的判断是：2026 年 agent 工具的竞争，正在从「模型能力」外溢到「传输与会话生命周期」这类不太上头条的地方。 谁把这些做扎实，谁的日常体感就领先一档。
第二，请务必带着「不含模型时间」这个前提引用它。 4.07→1.33 秒改的是等待开场的焦虑，不是答案出来的总时长。一个需要 60 秒思考的复杂任务，你现在仍需等 60 秒以上。把「首 token 延迟降 3 倍」讲成「速度快 3 倍」，是这轮传播里最可能出现的误读。
第三，本站更关心的是那个没人报的限定：gzip 大概率只覆盖官方域名。 各家转录都在复述同一组漂亮数字，但真正决定你能不能吃到红利的是你的 base URL。走 Bedrock / Vertex / 自建网关 / 第三方中转的团队——包括国内绝大多数使用者——请先验证自己的链路，不要照着 1.33 秒去设预期。这也是本站一贯的做法：看到「默认开启」四个字，第一问永远是「对谁默认」。
第四，反向代价说一句：云会话预热会为未提交的 prompt 起算力。对 Anthropic 来说这是用闲置算力换体感；对你来说，如果团队里有人习惯打了长长一段再删掉，这部分消耗是实打实的。 有成本对账需求的组织值得盯一下。
待核实
- 官方公告的原始载体与时间：延迟数字由官方 X 账号 ClaudeDevs 公布，本站未取得 Anthropic 官方长文公告页或 changelog 条目。不同转录来源把公布日期记为 2026-10-16 与 2026-10-17 两种，本站未取得原帖时间戳，不作裁定。
- 数字是否出自官方原文表述：本站核对的四家转录来源（CryptoBriefing、BlockBeats、AICoder、Zubiqo）数值完全一致，但其中一家明确指出**「Anthropic 自己的帖子并未给出这些数字」**（theblockbeats 之外的另一来源）。本站无法确认 4.07 / 1.33 / 16.99 / 6.00 等数值是否由 Anthropic 以文字形式正式公布，故本文不标
firsthand。 - 「社区实测压缩比约 2.1 倍 / 3 小时省 185 MB 上行」：来自 issue #90457 下的社区测量，非官方数据。
- Bedrock / Vertex / 自定义 base URL 是否真的没有默认 gzip：依据为 issue #103218 处于 open 状态，本站未核对源码实现，属推断性提示。
CLAUDE_CODE_GZIP_REQUEST_BODIES=0的完整语义：该环境变量名由转录来源给出；本站未在官方文档中检索到该变量的说明页，其精确作用范围（是否只影响请求体、是否影响遥测上报）未核实。- zstd（issue #102929）是否进入排期：议题为 open，官方未给出任何时间表。
- 云会话预热的触发条件与取消行为：官方未说明「开始打字」的判定阈值、以及未提交时预热资源的回收策略。
来源
- anthropics/claude-code issue #90457「Compress API request bodies with gzip by default」（官方仓库，一手核对标题与状态）
- anthropics/claude-code issue #103218「Opt-in gzip request bodies for Bedrock, Vertex and custom base URLs」（官方仓库，一手核对）
- Claude Code 官方 CHANGELOG（v2.1.300 起 gzip 相关条目）
- Claude Code v2.1.300 Release（2026-10-14）
- 延迟数字转录来源（二手）：Crypto Briefing、BlockBeats、AICoder、Zubiqo（四家数值一致）
- 延伸阅读：Claude Code 工具卡、上下文压缩概念页、上下文工程概念页、Codex 工具卡
口径说明：本文的机制描述（gzip、云会话预热、环境变量、issue 状态与编号）均经官方 GitHub 仓库一手核对；四组延迟数字来自官方 X 账号 ClaudeDevs 的公布、经四家二手媒体转录，本站未取得官方长文原文，故本文不标注
firsthand: true。「前三组不含模型计算时间、API 组含」为转录来源一致口径，引用时请勿混用。凡官方未证实的内容，均已列入待核实，不作推断。