Anthropic introduced Message Threads for the Messages API in public beta on 2 November 2026, allowing applications to send a complete conversation once and only new messages afterwards. The change reduces the volume transferred between an application and the Claude service during long sessions. The model still receives the full context reconstructed by the API before generating each response.
The feature is available on the Claude API, Claude Platform on AWS, Claude in Microsoft Foundry, and the Anthropic-managed version of Claude Models on Google Cloud. The release targets developers of applications and agents that make successive model calls. Its announced status is beta, with access signalled through a dedicated header on API requests.
New messages replace full-history transfers
Under the usual mechanism, an application resends earlier messages and the results of tools used by the agent at every step. As the session progresses, the same information is uploaded again. Anthropic explains that validating this volume of data and turning it into tokens contributes to the time spent before the model begins responding.
A Message Threads conversation starts with the full history, system instructions and tool definitions. The API temporarily retains that conversation, including Claude's reply, under the response identifier. At the next step, the application sends the added messages and the identifier of the latest response. The original instructions and tools are taken from the thread already created.
This mechanism concerns request transport and preparation. The model continues to analyse the complete conversation, rather than only the new fragment sent across the network. Tool results, a new user message or other information added by the application become the next part of the same context. The response retains the usual API message format, with an identifier used for continuation.
How a conversation moves through Message Threads
- First requestFull history, instructions and tools.
- ContinuationNew messages and the latest response ID.
- Full contextThe API rebuilds the conversation for Claude.
- After expiryThe application replays history in a new thread.
Anthropic reports faster response starts in very long sessions
According to measurements reported by Anthropic, Claude Code requests carrying between 500,000 and one million tokens recorded an approximately 35% reduction in median time to first token. The company says Message Threads is enabled by default for most Claude Code users. The figure describes that category of request and the provider's own measurement.
The metric, known as TTFT, measures the interval before a response begins. The published percentage does not represent total task duration or the generation speed of every token. The example concerns very large contexts found in agents accumulating many messages, files and tool results.
Token usage continues to be calculated against the complete context processed by Claude. Standard rates and existing API limits apply. Prompt caching, the mechanism that reuses eligible parts of a previously processed prompt, is configured separately. A thread with smaller transfers can operate without caching; enabling Message Threads does not itself establish prompt reuse breakpoints.
Five minutes to continue and up to one hour before deletion
A thread expires five minutes after its last request, and every stored response restarts that interval. The documentation separately specifies that the API deletes the thread no more than one hour after its last use. The first period concerns continuing the conversation through its identifier; the second is the maximum deletion period described for data held by the service.
When a thread can no longer be continued, the API returns a 404 error. The application resumes the conversation through a creation request containing the complete history. Anthropic calls for applications to retain their own copy of messages, because a request's response does not confirm whether that turn was stored for continuation. Availability becomes apparent at the next attempt to continue.
The official software development libraries include a helper that constructs these requests and resends the history once when continuation encounters certain thread errors. Its copy stays in the process's memory for as long as that object exists. An application retaining conversations after the process closes must manage that persistence separately in its own data system.
A thread's contents are encrypted in the service's memory under a server-managed key and are not written to durable storage. The feature is not eligible for Zero Data Retention or HIPAA. The documentation provides no API for directly listing, reading or deleting a thread. These conditions define how the new feature can be used in applications.
Coding agents and conversational applications use the same mechanism
Anthropic identifies coding agents, computer use agents, and document- or image-heavy workflows as suitable scenarios. In a development session, each tool result or file edit extends the conversation. For agents working with interfaces, existing screenshots remain in the thread's context instead of being uploaded again at every step.
In a business conversational application, the same mechanism can carry a user's question and the results of connected tools in successive turns. For example, an order assistant can receive a management system's response as a new message. In application development with AI integration, the application's history remains the source of the conversation, while the API thread supports temporary continuation of the message exchange.
The configuration stays consistent throughout a thread
Message Threads allows only the addition of new messages. Each response identifier can be continued once, after which the resulting identifier is used. Editing an older message or creating a branch requires a new thread with the relevant history. The model and certain settings, including the thinking configuration, must remain identical between requests within the same thread.
The feature works with responses delivered progressively through streaming. Continuation takes place after the message ends, rather than immediately after its identifier arrives. For developers, that ordering distinguishes a response still being generated from a completed one. The documentation also describes recovery by resending the conversation when a connection breaks before completion.
The beta does not support Message Batches, token counting through a request containing a thread, or automatic conversation compaction within that thread. Replacing history with a summary requires a new thread created from the application-prepared summary. The access header is named message-threads-2026-08-12; the date in that technical identifier differs from the public release date of 2 November 2026.
