Anthropic Launches Message Threads Beta for Long-Running Agents

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.