Anthropic says that wait times drop by 35% for Claude Code requests ranging from 500,000 to one million tokens by avoiding having the client retransmit the entire conversation on every turn. The feature, called message threads, is available in public beta for the Messages API and is already enabled by default for most Claude Code users.
The change reduces the work required before a response: after sending the full history once, the client can send only new messages and a reference to the previous response. But it does not reduce the amount of context Claude processes. The full conversation is still reconstructed on the server and the model reads it on every turn, so token usage does not change.
Anthropic announced the feature on November 2. It is not limited to Claude Code: it can also be used through the Messages API to create custom agents, including those that handle repeated tool calls, screenshots, or large amounts of documents and images.
Less repeated history before each response
Until now, every request to the Messages API included the entire history: previous messages, tool results, and any other accumulated content. In a long programming session, an agent can make hundreds of requests while reading files and modifying code. When the conversation reaches hundreds of thousands of tokens, sending all that material again adds overhead before Claude starts responding.
With a thread, the first request still includes the full conversation, along with system instructions and tool definitions. That request creates the thread on Anthropic's servers. For subsequent requests, the client transmits only new content and the ID of the previous response. Anthropic reconstructs the full context there before passing it to the model.
The difference lies in what travels from the application to the API, not in what Claude has to read. The company measures the result using time to first token (TTFT): the time that elapses before it begins generating a response. For Claude Code requests with between 500,000 and one million tokens, Anthropic reports a median reduction of approximately 35%.
That percentage refers to TTFT in that context range, not the total time for a task or all requests. Anthropic's documentation presents threads as especially useful in long, active sessions, where tool results, file changes, or other data that would previously have been retransmitted accumulate.
The improvement does not lower the token bill
Anthropic maintains its usual billing because Claude still processes the full history on every turn. Standard token rates and existing usage limits also remain unchanged. Message threads reduce the size of subsequent requests and the work involved in validating and tokenizing data sent to the API again, but they do not remove that context from the model's processing.
The company notes that threads can be combined with prompt caching, its prompt cache feature. These are distinct mechanisms: threads avoid retransmitting previous messages from the client; the cache allows processed content to be reused and may apply reduced rates to cache reads. Anthropic says both can work at the same time, but enabling a thread does not by itself enable the cache.
Agents that repeatedly send large files could see a particularly noticeable difference in the amount of data transmitted. Guillaume Lebedel, co-founder and CTO of StackOne, calculated the potential impact for computer-use agents in a simulation. His example assumes that the agent captures a 150 KB image at every step: by request number 50, the previous method would accumulate about 7.5 MB of screenshots, compared with about 0.15 MB if only the latest one is sent.
“My bet: computer-use agents will adopt it before coding agents, because a screenshot at every step is what makes retransmission heavy.”
— Guillaume Lebedel, co-founder and CTO of StackOne
In that same example, Lebedel estimates that the total screenshots transmitted over 50 steps would drop from about 191 MB to 7.5 MB, roughly 25 times less. These are calculations based on a simulation, not a test of the API in operation. Lebedel predicted that computer-use agents could drive adoption of the feature before the end of the year.
A thread can expire after five minutes
The beta has a short inactivity limit: a thread can no longer be continued after five minutes of inactivity. Each response stored by the API resets that period. If the application tries to continue a thread that is no longer available, the API returns a 404 error; the client must resend the full conversation and create another thread.
That does not necessarily mean the user loses the context. Anthropic recommends that the application keep its own copy of all messages, because the history temporarily stored on the server does not replace the local record. Its SDK's thread helper can automatically resend the conversation when needed. In a custom integration, the developer must manage expiration and recovery.
Anthropic also says that thread content is kept encrypted in server memory and is not written to persistent storage. Although continuation expires after five minutes, the data may remain in memory for up to an hour after the last use. The documentation specifies that the server may delete the thread within that maximum period.
The feature does not meet zero data retention or HIPAA requirements. Therefore, these data-handling limits may prevent its use in certain environments. Anthropic also notes that some context-management capabilities, including on-demand compaction, are not supported.
How to enable it in the Messages API
The API adds the thread parameter. The first request uses thread: {"type": "create"} along with the full history, system instructions, and tools. Subsequent requests send new messages and thread: {"type": "continue", "previous_message_id": "..."}, with the ID of the previous response.
When continuing a thread, system instructions and tools are not sent again: the ones from the request that created it are retained. Direct requests must also include the beta header message-threads-2026-08-12. The Python SDK offers a helper that manages starting and continuing the thread, as well as that header. The helper keeps a copy of the conversation in memory while the object exists; if the application needs the history to survive a restart, it must save it itself.
The documentation imposes other conditions for direct integrations. A thread is append-only, and each response ID can be continued only once; the latest ID must be used. To edit an earlier turn or open a branch, create another thread from the local copy. If a continuation is no longer possible, the application must replay the full history in a new creation request.
The feature is in public beta for all Claude models and can be used on Claude Platform, Claude Platform on AWS, Claude on Microsoft Foundry, and Claude models managed by Anthropic on Google Cloud. Anthropic has not announced a date for the feature to leave beta in these materials.
Sources: The New Stack, The Decoder, Claude, Claude Platform Docs, TNW | Anthropic, TechRounder, Times of AI
