AI 模型和平台
Anthropic 发布长跑时信件线索 Beta Agents
在 Google 上的首选来源中添加 Unite.AI
Anthropic 推出消息线程于2026年11月2日在公共beta发布，允许Claude平台上的信息API应用程序在初始全面对话请求后仅发送新消息。
该功能针对的是活动会话，其中耐久性很重要，包括长期运行的编码agents，其截图保留在线程上的计算机用途agents，以及文档和图像重的工作流程。 Anthropic报告，由于大多数Claude Code用户默认会安装消息线索，包含50万至100万个令牌的请求，则看到中间时间第一令牌下降约35%.
生命周期和恢复
没有线程，每个转动再次上传整个对话，API再次验证和表示所有对话。 有了线程，大部分作品只适用于API重建模型对话前的新转弯。 Claude在每一回合仍然读到完整的谈话，所以象征性的用法保持不变。 适用标准象征性费率和现行费率限额。
官方文献将生命周期分为创建和继续请求。 创建请求会发送完整的对话，系统即时和带有线程参数的工具；API将对话和Claude的回复存储在响应ID下。 持续请求只发出自上次答复以来的信息以及该答复的ID，而忽略系统和工具。 然后在下一个回合使用每个新的响应ID.
线程是最佳的，在他们最后一次请求5分钟后到期；每个响应API商店会重启该期间。 申请仍然是真相的来源，必须保留自己每条消息的副本。 如果API不能再继续一个线程，客户端会在新的创建请求中再次发送完整的对话。 SDK线程帮助器创建和延续线程，新增为所需的β头，将对话保留在内存中，并自动重播完整对话一次，用于指定续读错误。
保留和藏匿
线程内容在服务器管理的加密下保存在内存中，从不写入持久存储，在上次使用后不超过1小时删除。 一个线程包含发送到模型的对话，创建请求的系统即时和工具，以及用于检查以后请求的固定字段的指纹。 文件以引用方式持有，所以应用程序必须在线程活动时保留对话所使用的每个文件。 消息线程不具备零数据保留或HIPAA使用的资格，尽管该特性不影响其他零数据保留特性的资格。
线索不自动缓存提示；开发者必须提供缓存断点或顶级缓存控制。 串行请求最多可以携带四个缓存控制断点。 线索也只是附件，每个响应ID可以继续一次。 更改一个只创建的字段，如系统或工具，或固定字段需要包含完整对话的新线程。
流化、可用性和特性限制
对于流媒体响应，客户端必须等待消息停止事件后再从响应ID中继续，因为较早的持续请求可以返回404个错误。 SDK 帮助器不会在流掉后自动重试一个持续请求。 API不存储由倒置模型书写的转折，要求完整对话在线程恢复之前在新的创建请求中发送。
β在原生的Claude平台上可用，AWS上的Claude平台，Microsoft创始人的Claude模式，Anthropic管理下的Google云上的Claude模式，每个模式都有β支持。 没有 API 列表、 读取或删除线索。 线程不支持Message Batches，令牌计数，按需压缩或大多数上下文编辑，并且这些线程对启用推论钩的组织来说是不可用的。
因为线程过期，无法通过API检索，所以使用β的应用程序仍然必须保留自己的对话历史，并保持一个完全对话的重播路径，即使常规转折只包含新消息。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
AI Models & Platforms
Anthropic Launches Message Threads Beta for Long-Running Agents
Add Unite.AI to your preferred sources on Google
Anthropic introduced message threads in public beta on November 2, 2026, allowing Messages API applications on the Claude Platform to send only new messages after an initial full-conversation request.
The feature is intended for active sessions where latency matters, including long-running coding agents, computer-use agents whose screenshots remain with the thread, and document- and image-heavy workflows. Anthropic reports that, with message threads on by default for most Claude Code users, requests containing 500,000 to 1 million tokens see median time to first token fall by about 35%.
Request Lifecycle and Recovery
Without a thread, each turn uploads the entire conversation again, and the API validates and tokenizes all of it again. With a thread, most of that work applies only to the new turn before the API rebuilds the conversation for the model. Claude still reads the full conversation on every turn, so token usage remains unchanged. Standard token rates and existing rate limits apply.
The official documentation divides the lifecycle into create and continue requests. A create request sends the full conversation, system prompt and tools with the thread parameter; the API stores the conversation and Claude’s reply under the response ID. A continue request sends only messages since the previous response together with that response’s ID, leaving out system and tools. Each new response ID is then used for the next turn.
Threads are best-effort and expire five minutes after their last request; each response the API stores restarts that period. Applications remain the source of truth and must retain their own copy of every message. If the API can no longer continue a thread, the client sends the full conversation again in a new create request. The SDK thread helper creates and continues threads, adds the required beta header, keeps the conversation in memory, and automatically replays the full conversation once for specified continuation errors.
Retention and Caching
Thread contents are held in memory under server-managed encryption, never written to durable storage, and deleted no more than one hour after last use. A thread contains the conversation sent to the model, the create request’s system prompt and tools, and a fingerprint of fixed fields used to check later requests. Files are held by reference, so applications must keep every file used by the conversation available while the thread is active. Message threads are not eligible for zero data retention or HIPAA use, although the feature does not affect eligibility for other zero-data-retention features.
Threads do not automatically cache prompts; developers must supply cache breakpoints or top-level cache_control. A threaded request can carry at most four cache-control breakpoints. Threads are also append-only, and each response ID can be continued once. Changing a create-only field, such as system or tools, or a fixed field requires a new thread containing the full conversation.
Streaming, Availability and Feature Limits
For streaming responses, clients must wait for the message_stop event before continuing from the response ID because an earlier continue request can return a 404 error. The SDK helper does not automatically retry a continue request after a dropped stream. The API does not store turns written by fallback models, requiring the full conversation to be sent in a new create request before threading can resume.
The beta is available on the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry, and Claude Models on Google Cloud under Anthropic management, with beta support on every model. There is no API to list, read or delete threads. Threads do not support Message Batches, token counting, compaction on demand or most context editing, and they are unavailable to organizations with Inference hooks enabled.
Because threads expire and cannot be retrieved through an API, applications using the beta must still preserve their own conversation history and maintain a full-conversation replay path even when routine turns contain only new messages.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.