Claude Code v2.1.317在11月3日悄悄上线了一个功能。没有发布会，没有倒计时，只是某天打开终端，长对话的等待时间突然变短了。 官方数据很具体： 长会话中单次请求体积的中位数从约800KB降到1.8KB，50万到100万Token请求的首词延迟（TTFT）中位数下降约35% 。大多数Claude Code用户已经默认开启，不需要任何配置。 但它同时写了一句容易被跳过的限定： Claude每一轮仍然读取完整对话，Token消耗和标准费率不变 。 变快是真的，变便宜是假的。 这两件事被同一个功能同时做到了极致，也同时暴露了Agent时代最容易被混淆的一笔账。 先搞清楚它到底省了什么 以前Messages API不记历史。Agent每发一轮请求，都得把之前所有消息、工具返回的文件内容、命令输出从头再传一遍。一个编码Agent跑几百轮，对话涨到几十万Token， 光是把这些内容序列化、上传、再让服务端解析，就吃掉了首词延迟的很大一块 。 Message Threads的做法很直接： 第一轮照常发完整对话、system prompt和tools，服务端把这条线程存在加密内存里，返回一个response ID。之后每一轮只发新增消息和上一条response的ID ，服务端自己把完整上下文拼回去。 请求体积从800KB降到1.8KB，降的是 网络传输和预处理 。Claude推理时仍然读完整对话，所以Token一个没少。 省的是“快递包装”，不是“货物本身”。 35%这个数字，有它精确的适用范围 官方口径写得很窄： 50万到100万Token的请求，TTFT中位数下降约35% 。 这句话有两层容易被忽略的意思。 第一， 它降的是TTFT，不是总任务完成时间 。TTFT是你按下回车到看到第一个字之间的等待。对于跑一个长任务来说，这个等待只是整条时间线的一小段。35%的TTFT改善，放到一个跑20分钟的任务里，体感可能是“等它开口的时间短了十几秒”，而不是“任务快了一倍”。 第二， 如果你的会话在10万Token以下，改善几乎为零 。byteiota的实测分析写得很直白：低Token量的会话，重发成本本身就低，Message Threads省下的传输时间可以忽略。 这个功能是为“长会话”设计的。 短对话用它，等于给自行车装涡轮增压。 和Prompt Cache的区别：一个省上传，一个省钱 这是最容易搞混的地方，也是官方示例里两者一起用的原因。 Prompt Cache解决的是“服务端重复处理” 。命中缓存的那部分输入，按更低的价格计费——Opus 5.5和Sonnet 5.5的缓存读取价格是基础输入价格的 0.05倍 ，其他模型是 0.1倍 。它省的是钱，也是计算。 Message Threads解决的是“客户端重复上传” 。它不碰缓存，不会自动帮你命中任何东西， cache_control 断点仍然要自己设。它省的是传输时间。 一句话： Prompt Cache让每个Token更便宜，Message Threads让每次请求更小。 前者改账单，后者改等待。两者叠加才是完整的优化——一个管“你花多少钱”，一个管“你等多久”。 五个分钟、一个404、一个不能改的system prompt 这个功能的限制比它的收益更需要认真读。 线程闲置5分钟就过期，接口返回404 。没有警告，没有解释。你必须自己写fallback逻辑，检测到404之后用本地保存的完整对话重新建一个线程。如果你的工作流里有一个慢工具调用、或者一个人工审批环节超过了5分钟，线程就断了。 省下来的延迟，会被404重放吞回去一部分。 线程内不能改system prompt和tools 。继续请求里再传system或tools，哪怕传null，都会报错。model、tool_choice、thinking这些字段也必须和第一轮一致，变了会触发 thread_fingerprint_mismatch 。想换配置，只能新建线程，从头开始。 没有list/read/delete API 。你不能查线程里存了什么，也不能手动删。你的应用是对话的唯一可靠副本。服务端那份是“尽力而为”的临时状态， 不能当存储用 。 不支持ZDR和HIPAA 。对有严格数据留存要求的企业，这个功能默认就该关掉。 什么场景值得开，什么场景开了白开 值得认真用： 长时间运行的编码Agent，每一轮都在追加文件内容、diff和命令输出；Computer Use类的Agent，截图默认挂在线程上而不是每轮重传；文档和图片密集的会话，请求体积本身很大。 上下文越重，它省下的TTFT越可观。 开了白开： 短问答、轻量对话、10万Token以下的会话。传输成本本来就不高，35%的改善落到绝对时间上几乎无感。 必须关掉