Anthropic opened Message threads in beta on the Messages API on November 2 to reduce request size in long conversations and agent loops. Instead of uploading the full history each turn, an application can send new messages and the previous response's identifier. The server reconstructs the context before calling the model, according to the documentation.
The stated benefit is less data transfer and repeated validation and tokenisation, potentially reducing time to first token. This changes request handling rather than providing permanent memory: a thread expires 5 minutes after its last request and is deleted no more than an hour after its last use.
Temporary server storage, lasting application responsibility
The first request sends the full conversation, system instructions and tools and creates a thread. Later requests supply only new messages and refer to the latest response. The beta header is message-threads-2026-08-12. Its embedded date is a technical identifier, not the November announcement's launch date.
Storage is best-effort. If the thread is unavailable, continuation can return 404; the application must replay the full conversation to create a new thread. Anthropic stresses keeping an application-side copy. Without it, reduced transfer can become lost continuity after a pause or process failure.
Each stored response resets the 5-minute window. Threads therefore suit active sequences, not a database replacement between visits. Even the SDK helper, which keeps conversation history in memory and handles replay, does not persist it automatically beyond the process. Long-term storage remains the application's job.
Availability and checks before switching
The launch lists Claude API, Claude Platform on AWS, Anthropic-managed Claude Models on Google Cloud and Claude in Microsoft Foundry. Documentation marks threads as ineligible for Zero Data Retention and HIPAA. Teams with special data-handling requirements need to assess compatibility before changing existing request paths.
Threads are not prompt caching. Requests can shrink without enabling a cache, which the documentation configures separately. Less transmitted data therefore does not imply token charges fall proportionally. Useful comparisons include latency, request size, token usage and behaviour after expiry.
A trial should cover normal operation, a pause longer than 5 minutes and recovery after failure. Check compatibility restrictions, including Message Batches and some context-management features. When the application retains history and can resend a full request, threads can improve routine work without making temporary server storage the conversation's only point of dependency.