Claude 消息线程很快，但 5 分钟 TTL 会悄悄让你重传

Anthropic 的 message threads 把多轮对话的请求体从约 800 KB 压到 2 KB 以内，首 token 中位延迟降约 35%，但它只省延迟不省 token，线程闲置 5 分钟即失效。作者结合 Reddit 讨论和自身踩坑，讲清哪些场景真受益、哪些会反复重放，以及 thread_fingerprint_mismatch 和本地留存该怎么处理。

它到底省了什么

• 机制是首轮发完整对话，之后每轮只发新消息加 previous_message_id，长会话请求体从约 800 KB 降到 2 KB 以下。
• Anthropic 称 500k 到 1M token 区间的请求首 token 中位时间下降约 35%，该功能对多数 Claude Code 用户默认开启。
• 关键一点：Claude 每轮仍读取完整对话，token 消耗不变，所以这是延迟优化，不是省钱手段；要降成本仍得手动布置 prompt caching 断点。

5 分钟 TTL 的真实代价

• 线程在最后一次请求后 5 分钟被丢弃，超时后只能整段重放：完整对话、新的 create 请求、新的 thread id。
• 有开发者在 600k 上下文循环里实测 TTFT 提升约 30%，接近官方数字，但其工具调用常卡 3 到 4 分钟等慢接口，再加人工审批点击，窗口就没了。
• 多仓库测试套件、数据库迁移这类长任务必然超过 5 分钟，会静默地再付一次全量上传。
• 有评论指出 5 分钟正好对齐 prompt cache 的默认 TTL，慢工具调用本来就在付冷读成本，这点算合理辩护，但不构成卖点。

和 OpenAI Responses 的差别

• 两者续接方式类似，分别用 previous_message_id 和 previous_response_id。
• OpenAI 默认保留 response 对象 30 天并写入磁盘，可关闭存储；Anthropic 的线程加密存在内存、不落盘，最后一次请求后 5 分钟删除。
• 对要求零数据留存（ZDR）的团队，这个功能意义不大。

thread_fingerprint_mismatch 陷阱

• 字段分三类：仅创建时可传的 system 和 tools，续接请求里即使传 null 也会 400；必须每轮一致的 model、tool_choice、thinking、output_config、beta header 集合和顶层 cache_control；可自由变的 max_tokens、stream、metadata、service_tier。
• 想中途改 system prompt 只能开新线程，线程是只追加的，每个 response id 只能续接一次。
• 作者踩过的坑：线程请求最多带 4 个 cache breakpoint，顶层那个也算一个，文档里只在表格中一行带过。

自己保存每一轮

• create 和 continue 都不会告诉你这一轮是否被存储，失败要等下一次请求返回 404 thread_not_found 才知道，且错误不说明原因：过期、未存储、fallback 模型写入、不同 workspace 或 service account 都可能。
• SDK helper 只在对象存活期间持有对话，进程重启历史即丢。
• 所以应用侧要自己保存每条消息，并在第一天就写好重放路径。

谁该用、谁别用

• 5 轮就结束的 agent 不会触发过期，也省不出可测量的收益。
• 上下文低于 100k token 时，上传不是瓶颈，模型选择才是。
• 需要人工逐步审批的流程会与 5 分钟窗口持续冲突，感觉像功能坏了。
• 真正的目标场景是编码 agent 和 computer use 这类紧凑机器循环，截图留在服务端而不必每轮重传；其余情况普通 prompt caching 够用。