Anthropic adds message threads so Claude agents stop resending full conversations

Claude agents can now send a conversation once, then submit only what changed. Anthropic launched message threads in public beta on November 2, 2026, giving its Messages API temporary server-side conversation storage. The feature targets the wait before a response begins in long-running sessions—not the number of tokens Claude reads.

Send the history once, then send the changes

Without a thread, each request uploads every earlier message and tool result again. The API then validates and converts that history into tokens again. A coding agent can make hundreds of requests during a session, so the repeated work grows as its conversation accumulates code, file edits and tool results.

A thread changes that exchange. Developers add a thread parameter to the first request, alongside the full conversation, system instructions and tools. Anthropic stores that conversation, including Claude’s reply, under the response ID. Later requests carry only new messages and the previous response ID; the API rebuilds the conversation before calling the model.

The stored history has rules, laid out in the message threads documentation:

• System instructions and tools belong only in the first request. Sending either again on a continuation returns an error.
• The model and certain other settings must stay fixed. Developers need a new thread to change them.
• Threads are append-only: each response ID can be continued once. Editing or branching earlier messages requires a new thread.

Less upload work, not fewer billable tokens

Anthropic says message threads are on by default for most Claude Code users. Its reported improvement measures time to first token—the delay before Claude starts producing an answer—not the time needed to finish an entire task. The cited result applies to particularly long requests.

Claude still reads the complete conversation on every turn, so token usage stays unchanged. Standard token prices and existing rate limits also apply. Smaller network requests should not be confused with a smaller amount of material sent to the model for processing.

Nor does creating a thread automatically turn on prompt caching, which reuses previously processed input. Developers must still configure caching separately. The SDK helper can request it on each turn, but without that setting or manually placed cache markers, a thread alone does not cache the prompt.

Temporary storage still needs a recovery plan

Anthropic says threads are held in encrypted memory and are not written to disk. A thread expires five minutes after its last request; the documentation separately sets deletion at no more than one hour after last use. The feature is not eligible for zero-data-retention arrangements or HIPAA.

Storage is best-effort, so the application remains responsible for its conversation history. If a thread cannot continue, the API returns a 404 error and the client must resend the full history to create another. A successful response does not confirm that the API stored that turn; developers discover that on the next continuation.

Anthropic’s software development kit, or SDK, includes a helper that keeps the history in memory and automatically attempts this replay. It saves that copy nowhere else. Applications that need a conversation to survive a process restart must preserve their own copy rather than rely on the helper.

The public beta is available through the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry and Anthropic-managed Claude Models on Google Cloud. Anthropic identifies active coding sessions, computer-use agents and document- or image-heavy workflows as the main uses—sessions where repeatedly uploading growing histories adds delay.