Anthropic · Status at source date: Public beta
Claude Messages API adds message threads in public beta
Anthropic has introduced message threads in public beta for active agent sessions. After an initial full conversation, clients can send new messages with the previous response identifier. Thread state expires after five minutes of inactivity. This reduces repeated request payloads; token usage remains unchanged. For teams building marketing automation, the relevant change is transport and latency, not a promised reduction in model costs.

What changed
Anthropic announced Message Threads in public beta on 2 November. The Messages API feature lets an application send the full conversation once, then submit only new messages with the preceding response identifier. The aim is to reduce repeated request payloads and latency during active, long-running agent sessions.
Smaller requests do not mean fewer billed input tokens. Claude still processes the conversation, and Anthropic says token usage remains unchanged. Its reported latency improvement is an internal result for very long Claude Code conversations, rather than a performance promise for every workflow.
Expiry and recovery matter
The official documentation describes threads as best-effort state. After five minutes of inactivity, a thread expires; a client must be able to replay its full conversation when continuation fails. The application remains responsible for its own conversation history. Message Threads is also distinct from session threads in Managed Agents.
The documentation lists support across the native Claude API and specified Anthropic-managed cloud offerings. It marks the feature as not eligible for zero data retention or HIPAA arrangements. Teams should check the current documentation for their deployment rather than assuming that an existing contract or integration automatically covers the beta.
Relevance to marketing automation
For a team building an assistant that reviews repeated campaign exports or works through many document revisions, this changes how successive requests are transported. It does not improve the underlying campaign data or remove the need to check the assistant’s conclusions. The practical question is whether repeated uploads are a meaningful part of the workflow’s delay.
Measure that before changing an integration. Compare representative sessions with the current implementation, including pauses long enough to trigger expiry. Check that a recovery request preserves the correct conversation and does not repeat a consequential tool action. A faster first response is useful only if the surrounding workflow remains reliable.
Keep latency, token cost and task accuracy as separate measures. A transport improvement can affect one without improving the others. Review the data-handling conditions with the people responsible for the application before testing with real customer information.
Source and date
Anthropic is the original, unsigned announcement source. The accompanying screenshot records its 2 November announcement.
Sources & contributor credit
- Official source · Anthropic
Unsigned official announcement. Transport and latency change; token usage unchanged.
- Official sourceClaude documentation
Documents best-effort state, five-minute inactivity expiry, recovery, deployment availability and data-retention limitations.
Original creator unverified
Credits reflect the editor's latest changes. Original authorship has not been independently verified for this version.
Attribution evidence and limitations
Full attribution review pending.
A source link alone does not establish original authorship.
Original image and video creators have not yet been verified.
- Published on this site
- Article updated
This update reflects the dated source reporting. Availability may have changed. Further coverage of this same development will be added to this page.




