Claude API 的 message threads：长跑 Agent 不用再重发整段对话

它解决的问题：每轮重传几十万 token

做长跑 Agent 的人都有一个共同痛点。会话跑到第 40 轮，上下文已经堆到 50 万 token，但每发一次请求，客户端都要把整段对话重新序列化、重新上传、让服务端重新预填充。token 照付，首 token 延迟还一轮比一轮长。

Anthropic 在 Messages API 里开放了 message threads 公开测试，核心思路只有一句：对话只发一次。第一个请求携带完整会话并开启一个 thread，之后每个请求只发新增消息，加上上一次响应的 ID。thread 在两次请求之间保存在内存中并加密，不落盘；最后一次请求后 5 分钟过期，客户端到时要重发完整对话、开一个新 thread。

收益与代价，都得算清楚

官方数据：对 50 万到 100 万 token 的请求，首 token 延迟中位数下降约 35%。这个能力对多数 Claude Code 用户已经默认开启。但有一个必须知道的限定——token 用量并没有减少。Claude 每轮仍然要读完整对话，省下来的是传输与预填充的时间，不是账单。

典型受益场景有三类：长跑编码 Agent，每轮都在同一个仓库里改文件；computer use，每一步都要带截图，图像重复上传最贵；文档与图片密集型工作流。反过来说，如果你的会话只有几千 token，或者每轮都在换任务，收益可以忽略。

把省时间和省钱分开算，是做 Agent 成本模型最容易犯的错。message threads 只优化前者。

接入时的四个工程要点

一是超时窗口。5 分钟是从最后一次请求开始算的，不是从 thread 创建算的。做异步队列、人工审批、定时任务这类流程时，间隔很容易超过 5 分钟，必须有 thread 失效就全量重发的兜底分支，并且这条分支要能打点，否则线上会静默退化成旧行为，你还以为优化生效了。

二是响应 ID 的持久化。thread 本身不落盘，但你的进程崩了要能恢复，所以响应 ID 得自己存。存在哪、怎么和会话 ID 绑定，取决于你的状态管理方式；如果是多副本部署，还要保证同一会话的请求打到同一实例，或者把 ID 连同会话状态一起放进共享存储。

三是计费口径不变。别把首 token 延迟下降当成成本下降去改定价模型。仍然是全量输入 token 计费，前缀缓存另算。

四是监控指标要换。原来盯的是整请求耗时，现在要拆成排队、预填充、解码三段，否则你分不清延迟改善来自 thread 复用还是模型排队变短。

顺带说一条同日的消息作对照。GitHub 也在同一天宣布 Copilot Fusion 正式可用，思路正好相反：不让你选模型，让你选努力程度。Fusion Max 在 Coding Agent Index 上得 60 分，与使用 Opus 5.5 Max 的 Claude Code 相差两分以内，但每任务 API 成本约为后者一半、token 消耗约一半、耗时少约 40%。产品分成日常编码与高难任务两档，管理员可以控制模型可用范围与计费。

一边省传输，一边省选型，2026 年底的 Agent 工具链正在两个方向上同时挤压成本。对做产品的人来说，结论很朴素：先量清楚你的延迟到底花在哪一段，再决定优化哪一层。