AREX Feed Article
Anthropic 开放 Messages API 消息线程公测：对话由服务端缓存，官方称 Claude Code 首 token 中位延迟约降 35%
北京时间 11 月 3 日凌晨（11 月 2 日 19:06，UTC），Anthropic 面向开发者的官方账号 @ClaudeDevs 发帖宣布：消息线程（message threads）已在 Messages API 进入公开测试（public beta）。这套机制把对话缓存在服务器端的回合之间，开发者不再重发完整对话，只需发送新消息和上一条消息的 ID，Claude 就能更早开始响应（）。
同一条推文线程还给出了 Anthropic 自家集成后的两个数字：Claude Code 接入消息线程后，500K～1M token（词元）请求的首 token 中位时间（time to first token，TTFT）约降低 35%；长对话中，单次请求的中位大小从约 800 KB 降到 1.8 KB（）。这些数字是 Anthropic 的单方口径，目前没有独立核实。
一条 thread 把对话留在服务器上，应用只发增量
按的说明，第一个请求照旧发送完整对话、system 提示词和 tools，并加上 thread 参数（"thread": {"type": "create"}）；之后的每个回合只发送自上一条响应以来的新消息，附上 "thread": {"type": "continue", "previous_message_id": "<上一条响应的 ID>"}，system 和 tools 不必再带——线程会保留 create 请求里的值。API 在调用模型前重建整段对话，返回的仍是普通的 message 响应。手写请求时，每个线程请求都要带 message-threads-2026-08-12 这个 beta header（测试版请求头）；各家 SDK（软件开发工具包）的 thread helper 会替开发者补上这些字段。
提速的原理写在文档里：不用线程时，每个回合都要把整段对话重新上传，API 每次都要重新校验和切分（tokenize）全部内容；用了线程，「这些工作的大部分只需覆盖新回合」。文档的判断是，线程对长时间的 agent（智能体）循环帮助最大。
默认开启、账单不变
把 35% 这个数字放进了正文，并交代了来历：消息线程已对大多数 Claude Code 用户默认开启，一个编码 agent 单次会话可能发出数百个请求，每个请求都重发此前所有消息和工具结果，对话涨到数十万 token 后，重发全部历史会拖慢 Claude 开始响应的时间。
不过，账单不会跟着变小。博客明确写道：每个请求虽然变小，「Claude 每一回合仍然要读完整段对话，所以 token 用量不变」。这也不是 Claude Code 最近第一次为延迟动手——10 月 16 日，同一个账号介绍过 Claude Code 开始在每回合对发出的对话做 gzip 压缩，让它更快到达模型（）。
五分钟过期、尽力而为：文档写明的边界
线程是尽力而为（best-effort）的：它在上一次请求 5 分钟后过期，API 在最后一次使用后不超过 1 小时将其删除；每存储一条响应，5 分钟就重新计时。线程无法继续时，continue 请求返回 404 错误（错误码 thread_not_found），开发者要把整段对话重新发一次 create 请求；SDK helper 会自动做一次这样的重放。
文档同时把责任划给了开发者：「你的应用始终是对话的事实来源。」每条消息的副本要自己保留，重放路径要从一开始就建好——没有任何响应会告诉开发者某一回合究竟存没存上，只能在下一次 continue 请求时才知道；SDK helper 也只把对话副本保存在 helper 对象存续期间的内存里，不会存到别处。
数据方面，文档说明线程不适用于 ZDR（zero data retention，零数据保留）场景：API 把线程放在内存里，用服务器托管的密钥加密，从不写入持久存储；线程也没有列出、读取或删除的 API。一些功能与线程互斥：Message Batches、token counting、compaction、context editing（clear_thinking_20251015 且 keep 为 all 的情形除外），以及开启 HIPAA readiness 或 Inference hooks 的组织。
哪里能用，适合什么场景
按博客的说法，消息线程现在可以在原生 Claude Platform、Claude Platform on AWS、Claude in Microsoft Foundry 以及 Claude Models on Google Cloud（Anthropic 托管）上使用，按标准 Claude token 费率计费，沿用现有限流；@ClaudeDevs 的帖子把最后一家写作「Claude on Google Cloud」（）。
博客列出的适用场景有三个：长时运行的编码 agent，工具结果和文件编辑会不断把对话撑大；computer use agent（操作电脑的智能体），截图留在线程里，不必每回合重新上传；以及文档和图片密集的工作流，请求体积因此变小。上下文带得越多，线程能压缩的 TTFT 就越多。就在几天前（10 月 29 日），Anthropic 刚把 Claude API 的 Messages 和 Token Counting 接口的最大请求体积从 32 MB 提到 128 MB，理由正是长时间 computer-use 会话和大 PDF 这类图片密集请求（）。
回复区：缓存自己配，五分钟够不够
公告发出后，开发者 Browser OS 在回复中提醒了文档里的这个坑：「线程不会替你缓存提示词——你还是得在每个请求上加顶层 cache_control，否则每回合发出去的字节变少了，却什么也没被缓存」（）。文档的说明与此一致：线程不会替开发者缓存提示词，prompt caching 仍要自己设置——每个回合带上顶层 cache_control，而一个线程请求最多允许 4 个 cache_control 断点。George Vasilakopoulos 则建议，为自己的对话留一份副本，以备 404 重放（）。
更多追问指向那个 5 分钟。zhallen 问过期时间能否配置：「任何会停下来等人工审核或跑长测试的 agent，几乎每一回都会超时」（）；Füranco 的评价更直接：「缓存 5 分钟就过期，这几乎没用」（）。计费是另一个集中问题，dr. ai 直接问缓存的线程按 10% 的缓存读取费率还是全价计费（）。对计费，文档的总回答是：线程不改变定价，也不改变限流；至于过期时间，文档把 5 分钟写成固定行为，没有提供可配置项。