Anthropic launches message threads for long-running agents

Anthropic announced message threads as a public beta on November 2, 2026. The feature lets applications using the Messages API on Claude Platform send only new messages after the initial request, rather than the entire conversation.

The target audience is active sessions where latency is critical. Long-running coding agents, computer-use agents that keep screenshots in the thread, and document- and image-heavy workflows are at the top of the list. Anthropic reports that threads are on by default for most Claude Code users and that time to first token for requests between 500k and 1 million tokens dropped by a median of about 35 percent.

The entire conversation is not reloaded on every turn

Without threads, each turn reloads the entire conversation; the API revalidates and tokenizes all of that text again. With threads enabled, most of this work is done only for the new turn, and the API then reconstructs the conversation for the model. However, Claude still reads the entire conversation on every turn, so token consumption does not change, and standard token pricing and existing rate limits apply.

The documentation splits the process into two request types. A create request sends the entire conversation, the system prompt, and the tools with the thread parameter; the API stores the conversation and Claude’s response under a response ID. A continue request sends only the messages since the previous response and that response’s ID, and does not resend the system prompt and tools.

Ephemeral threads that expire in five minutes

Threads work on a best-effort basis and expire five minutes after the last request; each response stored by the API resets that timer. The application must keep its own copy of every message, because the source of truth is the application itself. If a thread cannot be continued, the client resends the entire conversation from scratch with a new create request. The SDK helper adds the required beta header, keeps the conversation in memory, and automatically resends the full conversation once on certain continuation errors.

Thread contents are not persisted to disk; they are held in memory with server-side managed encryption and deleted at most one hour after last use. Because files are kept by reference, the application must keep every file in the conversation accessible while the thread is open. Message threads are not eligible for zero data retention or HIPAA use.

Prompt caching does not happen automatically

Threads do not automatically cache prompts; the developer must provide cache breakpoints or the top-level cache_control field themselves. A request containing a thread can have at most four cache breakpoints. Threads accept append-only additions, and each response ID can be continued once. If a field provided only at the create stage, such as the system prompt or tools, changes, you must open a new thread containing the entire conversation.

In streaming responses, the client must wait for the message_stop event before continuing with the response ID; a continue request sent too early may return a 404 error. The API does not store turns produced by fallback models; in that case, to continue the thread, the entire conversation must be sent with a new create request.

The beta is available on native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry, and Claude models on Google Cloud. Support is available across all models. There is no API for listing, reading, or deleting threads; Message Batches, token counting, on-demand compression, and most of context editing are not supported. Organizations with inference hooks enabled also cannot use the feature.

Source: Unite.AI