发生了什么
11 月 2 日，Anthropic 在 Claude Platform 的发布说明中宣布，Messages API 的 message threads 进入公开测试，beta 标头为 message-threads-2026-08-12。这项能力解决的是一个很具体的浪费：一个编程智能体在一次会话里可能发出数百次请求，而每一次都要把此前的全部消息与工具执行结果重新上传一遍。上下文涨到几十万 token 之后，光是传输、校验与分词就吃掉了相当一部分首字等待时间。
接口怎么改
- Create：首次请求与现在一样带完整 messages、system 与 tools，额外加 thread 的 create 字段，API 会在该次响应 id 下保存对话。
- Continue：之后每轮只发上次之后的新消息，加 thread 的 continue 字段与上一轮的 previous_message_id；不要再带 system 与 tools，线程会沿用 create 时的取值。
- Replay：线程是尽力而为的。无法续接时 continue 会返回 404，客户端需用完整历史重新 create 并沿用新 id。官方 SDK 的 thread helper 会自动完成这一次重放。
收益与代价
官方给出的数字是：在 50 万至 100 万 token 量级的请求中，首 token 延迟（TTFT）中位数下降约 35%，前提是多数 Claude Code 用户已默认开启该特性。有媒体报道称，长对话单次请求体积中位数从约 800KB 缩至 1.8KB，降幅约 99.8%——这一具体数值未见于官方博客，引用时宜标注为媒体口径。
代价有四条，写代码的人最好先看清：其一，模型每轮仍要读完整上下文，token 用量不变，定价、速率限制与提示缓存计费规则都不变，省的是等待不是账单；其二，线程在最后一次请求后 5 分钟过期，最迟在最后一次使用后 1 小时内删除，长空闲后的第一次请求会突然变慢；其三，对话在服务端内存中加密保存、不落盘，因此不支持零数据保留（ZDR），也不适合 HIPAA 场景；其四，应用仍是唯一真相源，必须自己完整留存历史并实现 404 后的重放路径。
谁会真的获益
官方点名的场景是长跑的编程智能体、计算机操作类智能体（截图不必每轮重传）、以及文档与图片比重很大的工作流。判据其实很简单：如果一次会话会在一小时内从几万 token 涨到八十万 token 且中间不停发请求，开线程几乎稳赚；如果每轮都是独立的短任务，线程只会多添一套状态管理。上下文本身很小的短会话，重发的代价可以忽略，收益也接近零。
还有一处容易混淆：message threads 与 prompt caching 不是一回事。后者是计费层面的前缀缓存，前者是运行时层面的增量传输，两者不冲突、可以叠加——缓存压住成本，线程压住延迟。当前公测覆盖 Claude API、AWS 上的 Claude Platform、Google Cloud 上由 Anthropic 托管的 Claude 模型，以及 Microsoft Foundry 中的 Claude；不支持 Batches、带 thread 的 token 计数与按需压缩，也与 Managed Agents 的 session threads 不是同一机制。