Anthropic has given developers a way to stop re-sending entire conversations to Claude on every turn. Message threads, released in public beta on November 2, 2026, let an application send the full history once and then pass only the new messages, together with the ID of Claude's previous response. The feature is aimed at long agent loops, where Anthropic says repeatedly uploading hundreds of thousands of tokens adds a noticeable wait before the model starts to reply.
The headline figure comes from Anthropic's own coding tool. The company says message threads are already on by default for most Claude Code users, and that for requests of 500,000 to 1 million tokens, median time to first token dropped by about 35%. Anthropic has not published results for shorter conversations; it says only that the benefit grows with the amount of context an agent carries, naming coding agents, computer-use agents that would otherwise re-upload screenshots, and document-heavy workflows as the main use cases.
Using the feature means adding a thread field to Messages API requests and sending the message-threads-2026-08-12 beta header. The first call carries the full conversation, system prompt and tools and is marked as a create request. Each later call is a continue request that names previous_message_id and must leave out the system prompt and tools, which the thread keeps from the first call. Several other settings, including the model and the thinking configuration, have to stay identical for the life of the thread. Anthropic's SDKs ship a thread helper that builds these requests and handles replays, and the SDK's beta tool runner now uses threads by default.
Threads change what travels over the network, not what the model reads. Claude still processes the whole conversation on each turn, so token usage, standard token rates and existing rate limits are unchanged, according to Anthropic. The documentation is explicit that a thread is not a prompt cache: developers who want to avoid recomputing earlier turns still have to place cache_control breakpoints, with a limit of four per threaded request. Between turns, Anthropic says each thread is held in memory, encrypted and never written to disk.
The design is deliberately short-lived. A thread expires five minutes after its last request and is deleted no more than an hour after its last use. When the API can no longer continue it, a continue call returns a 404 error with the code thread_not_found, and the client has to resend the full conversation to open a new thread, which is why the docs tell developers to keep their own copy of every message. There is no API to list, read or delete threads, a thread cannot be compacted in place, and turns answered by a server-side fallback model are not stored. Anthropic's documentation also lists the feature as not eligible for zero data retention or HIPAA arrangements.
The beta works with every Claude model on the Claude API, Claude Platform on AWS, Claude in Microsoft Foundry and Claude Models on Google Cloud (Anthropic managed), and it is listed in the Claude Platform release notes for November 2. The Next Web, reporting the launch the same day, stressed the trade-off that Anthropic itself acknowledges: the feature saves waiting time, not money.
For teams building agents on Claude, the appeal is lower and steadier latency as sessions grow, without rewriting prompts. The price is more state to manage: applications must track response IDs, plan for expiry and replays, and keep fixed parameters stable across a thread. The 35% improvement is Anthropic's own measurement on a Claude Code cohort, not an independent benchmark, and real gains will depend on context size, caching setup and how often threads lapse between turns.