2026 年 11 月 2 日，Anthropic 在 Claude 平台上线了 Message Threads 公共测试版。过去调 API，每一轮对话都得把完整的历史上下文重新打包发一遍；开启新功能后，客户端每次只需上传自上一条消息以来的新增内容，50 万至 100 万 token 长对话的中位首字延迟下降约 35%，请求负载中位数直接从 800 KB 缩减到 1.8 KB。不过别急着把它当成省钱或偷懒的神器，服务端依然会重读全部历史，token 消耗和账单分文不少，而且线程在内存里只活 5 分钟——它压根不是 OpenAI 那种帮你存 30 天记录的会话托管，而是专门给高频机器循环修的一条内存快车道。
把核心变化拆开看，最值得开发者注意的边界有三处：
- 发生了什么.通过传入
previous_message_id接力对话，系统提示词与工具定义留在服务端加密内存中，闲置 5 分钟过期，1 小时内从物理内存彻底抹除。 - 谁最受益.Claude Code 这类编程 Agent、连续截屏的 Computer-Use Agent，以及挂着大文档跑的自动化工作流。
- 渠道与合规暗礁.目前仅支持 Claude 原生平台、Microsoft Foundry，以及 AWS 和 Google Cloud 上由 Anthropic 托管的渠道（不等同于 Amazon Bedrock 或 Google Vertex AI 原生接口），且明确排除在零数据保留（ZDR）与 HIPAA 合规之外。
算力分毫未减，砍掉的 35% 延迟从哪来
很多人第一反应是反常：既然 Claude 在服务端还是要从头到尾读一遍百万 token 历史，模型推理的计算量一点没少，凭什么首字延迟能降 35%？
答案不在显卡上，而在网线和网关里。在传统的无状态 API 架构下，一个跑了三四十步的编程 Agent 或桌面操作 Agent，上下文里塞满了代码文件、几十个工具的 JSON Schema，以及一串高分辨率的 Base64 屏幕截图。客户端每隔几秒发一次请求，就要把这坨接近 1 MB 的文本通过 HTTP 重新传上云端，API 网关收到后还得把庞大的 JSON 字符串完整反序列化、校验一遍，最后才能塞进推理集群。
当上下文膨胀到 50 万至 100 万 token 时，客户端上行带宽和网关解析 JSON 的耗时，已经长成了独立于模型算力之外的累赘。Message Threads 把历史状态锁在服务端内存里，单次传输体积从 800 KB 骤降到 1.8 KB，等于直接砍掉了每次请求的上行传输与网关解析开销。这也是为什么官方测试数据专门卡在 50 万至 100 万 token 区间——要是日常几千 token 的短对话，网络上传本来就只有几毫秒，开不开这个功能根本试不出差别。
五分钟线程撞上一小时缓存，最容易踩的工程错位
真正让我警惕的，是它跟提示词缓存（Prompt Caching）各跑各的独立时钟。不少初级开发者看到只传增量消息，下意识以为服务端既然留了内存，肯定顺手把 KV Cache 也省了，账单会自动打折。
完全是两码事。Message Threads 管的是网络传输层，Prompt Caching 管的是推理计算层。哪怕开了 Message Threads，只要你没在请求里显式传 cache_control 参数，历史 token 依然按全价收钱。更拧巴的是两套机制的寿命对不上，放在一起跑就会制造出诡异的状态机错位。
看一眼两边的账本就明白了。假设你为了跑长任务，花 2 倍输入单价买了 1 小时有效期的 Prompt Caching，结果用户在屏幕前喝了杯咖啡，停顿了 10 分钟才输入下一句指令。这时候再去调接口，5 分钟寿命的 Message Threads 已经过期，服务端会直接甩给你一个 404 错误；客户端必须捕获这个 404，老老实实把本地存的 800 KB 完整历史重新上传一遍。但搞笑的是，当你把全量历史重传上去之后，因为 1 小时的 Prompt Caching 还没到期，匹配上的前缀依然能按 0.1 倍甚至 0.025 倍的缓存读取价结账。
| 对比维度 | Anthropic 方案 | OpenAI 方案 |
|---|---|---|
| 状态接力接口 | Message Threads (previous_message_id) | Responses API / Conversations API |
| 服务端保留时长 | 闲置 5 分钟过期（1 小时内物理删除） | 默认 30 天（Conversations API 无期限） |
| 缓存写入溢价 | 5 分钟为 1.25 倍，1 小时为 2 倍 | 30 分钟为 1.25 倍，12 小时为 2.5 倍 |
| 缓存读取折扣 | 常规 0.1 倍（Opus/Sonnet 5.5 为 0.05 倍，Fable/Mythos 5.1 为 0.025 倍） | 常规 0.1 倍（GPT-6.1 Sol/Terra 为 0.05 倍） |
而且这个 5 分钟倒计时是从请求发出的那一刻就开始算的。如果模型自己思考加输出一段长代码花了 2 分钟，留给客户端处理工具调用并发起下一次请求的时间，实际上只剩 3 分钟。
为什么 Anthropic 死守五分钟内存态
同样是做服务端状态接力，OpenAI 的 Responses API 默认把状态存 30 天，Conversations API 甚至不设过期时间；Anthropic 却抠门到只给 5 分钟尽力而为（best-effort）的内存保留，连硬盘都不肯落。
OpenAI 想替你当数据库，Anthropic 只想替机器省带宽。
这背后是两家公司对 API 边界的算计完全不同。古人行军讲“千里馈粮，士有饥色”，百万 token 的上下文就是每次 API 调用都要背着跑的沉重粮草。OpenAI 的思路是干脆在云端建个永久粮仓，让做套壳聊天应用的小团队连后端数据库都省了，顺带把客户的数据和状态死死绑在自家平台上。
但 Anthropic 盯死的是 Claude Code 这类自主 Agent。机器循环调工具是按秒计算的，步与步之间根本不会停顿超过 5 分钟；一旦任务跑完，这串中间状态留着也是占内存。不落盘、只存加密内存、用完即焚，既替自己省下了海量的持久化存储成本，又能在机器高频循环的那十几分钟里把 I/O 延迟榨干。
只可惜，这套不落盘的轻巧设计在企业合规面前还是卡了壳。哪怕 Anthropic 反复强调服务端密钥加密、绝不写进硬盘、一小时物理销毁，只要数据在两次请求之间停留在服务端内存里，按照严格审计标准就不算用完即走。因此官方文档不得不写明该功能不支持零数据保留（ZDR）与 HIPAA。对于签了 ZDR 协议的金融、医疗大客户来说，这条快车道暂时只能看不能上。
- 风险.在生产环境接入 Message Threads 时，客户端绝不能省掉本地数据库，必须写好 404 状态码拦截与全量历史重放（Replay）的降级逻辑，同时盯紧
cache_control断点，否则一次网络抖动或人类停顿就会让对话当场中断。
接下来真正要盯紧的，是 Amazon Bedrock 和 Google Cloud Vertex AI 原生接口什么时候能把这套内存接力机制接过去——毕竟绝大多数大企业的生产流量，还跑在那两座云端围墙里面。