Claude no longer needs you to resend the whole conversation: message threads are here

On November 2, 2026, Anthropic launched message threads for the Messages API in public beta. With them, a long conversation no longer has to be resent in full on every turn: the server stores it for a while and your code sends only the new messages. The promise is a lower time to first token (TTFT) in long sessions. According to Anthropic, in Claude Code it drops by about 35% on requests of 500,000 to one million tokens. If you have an agent that goes through hundreds of tool-use rounds, or a bot that drags a long history along, this affects you. Heads up: it won't lower your bill.

The problem it tackles

The Messages API is stateless: the server remembers nothing between requests. Every agent turn sends the system prompt, the tool definitions and the whole history all over again, including tool results and screenshots. The documentation explains it like this: without a thread, every turn re-uploads the entire conversation, and the API validates and tokenizes it again.

With 20,000 tokens of history you barely notice. With 500,000 you do. Anthropic gives the example of a coding agent that makes hundreds of requests in a single session: each one carries everything that came before, and that resending adds time before Claude starts answering.

How it works

The mechanism is simple and fits in one new parameter, thread, plus the beta header message-threads-2026-08-12, which goes on every request in the thread:

Create. The first request goes out as usual, with the full conversation, system and tools, and you add "thread": {"type": "create"}. The API stores the conversation, including Claude's reply, under that reply's id.
Continue. On later turns you send only the new messages and "thread": {"type": "continue", "previous_message_id": "<previous id>"}. system and tools are not sent again: if you send them, even as null, the API responds with a 400 error.
Start over. The thread is best-effort. It expires 5 minutes after the last request and is deleted at most an hour after its last use. If it can no longer be continued, the API responds with a 404 and the code thread_not_found, and you have to resend the whole conversation in a new create.

Diagram comparing what is sent on each turn without a thread, where the request grows with the entire history, and with a thread, where only the new message travels

The SDKs ship a helper (client.beta.messages.thread(...) in Python) that builds these requests, adds the header and automatically retries from scratch when the thread is lost. The SDK's beta tool runner also uses a thread by default. One important detail: the helper keeps the conversation only in memory, for as long as the object exists. If your process restarts, the copy goes with it.

What doesn't change: the cost

Here's the fine print that matters most. Anthropic says that even though each request is smaller, Claude still reads the entire conversation on every turn, so token consumption is the same. The documentation confirms it: threads don't change pricing or usage limits.

They don't cache anything for you, either. Prompt caching works the same as without a thread: you decide where the cache breakpoints go. To cache every turn you have to send a top-level cache_control on each request in the thread, and there's a cap of 4 cache breakpoints per request. If you want to save money, caching is still the way. The thread saves time.

The rules that can bite you

The documentation splits the fields into three groups, and it's worth having them straight before migrating:

Group	Fields	Rule
Only on `create`	`system`, `tools`	Sending them on a `continue` gives a 400 error
Fixed	`model`, `tool_choice`, `thinking`, `mcp_servers`, `output_config`, top-level `cache_control`, beta headers, among others	Must carry the same value throughout the thread; if they change, `thread_fingerprint_mismatch` error
Free	`max_tokens`, `stop_sequences`, `stream`, `metadata`, `service_tier`	Can change between turns

Other rules from the same documentation:

The thread only grows. Each id can be continued only once, and you can't edit or branch from an old message. To fix something, compact with a summary or switch tools, you have to open a new thread.
The API doesn't check for duplicates. If you resend a message that was already there, it may show up twice in the conversation or return an error.
Streaming: the id arrives in message_start, but you can only continue after message_stop.
Refusals and fallback models: after a stop_reason: "refusal" the thread can't be continued, and a turn written by a fallback model is not stored.
Same owner: the thread can only be continued by the same organization, the same workspace and the same key or service account that created it.
Not supported: Message Batches, token counting, on-demand compaction, most context editing, organizations with HIPAA, or those with inference hooks enabled.
There is no API to list, read or delete threads.

Privacy

Anthropic says it keeps the thread in memory, encrypted with a key managed by the server, never writes it to disk, and deletes it at most an hour after its last use. Even so, the feature is not eligible for Zero Data Retention or HIPAA. If your organization has ZDR by contract, check this before turning it on.

Where it's available

According to the release notes, the beta works on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (managed by Anthropic) and Claude in Microsoft Foundry, with all models. Anthropic already has it enabled by default for most Claude Code users.

What this means

My take: it's a transport optimization, not an intelligence one. The model doesn't remember more or reason better; your request simply weighs less and arrives sooner. Anthropic says it's most noticeable in coding agents, computer use agents (screenshots stay in the thread instead of being uploaded on every turn) and workflows with lots of documents or images.

For a WhatsApp bot with short, spaced-out conversations, the gain is small: if the customer takes more than 5 minutes to reply, the thread has already expired and you send everything again. Where the experience does change is in agents that chain tools nonstop and pile up hundreds of thousands of tokens.

The golden rule the documentation repeats is that your application remains the source of truth: keep your own copy of every message and build the path to replay the full conversation from day one. No response tells you whether the turn was stored; you only find out on the next continue. Anyone who treats the thread like a database is in for surprises.

I haven't tested it; all of this comes from the official Claude Platform documentation, Anthropic's announcement and the coverage cited below.