Anthropic Message Threads: Claude API Agents Stop Resending the Whole Conversation

On November 2, 2026, Anthropic released message threads for the Claude Messages API in public beta. An agent now sends the full conversation once. After that, each request carries only the new messages plus the ID of Claude's last reply. Anthropic says that on requests of 500k to 1M tokens, median time to first token dropped by about 35%.

The catch is simple and worth saying up front: your bill does not change. Claude still reads the whole conversation on every turn. Threads cut the time you spend uploading, not the tokens the model processes. That distinction is the whole story, so let's walk through it.

What happened

Anthropic posted "Make long-running agents faster with message threads" on its Claude Platform announcements page on November 2. Here is what the post and the technical docs confirm.

• You opt in by adding a thread parameter to Messages API requests. The first request includes the full conversation and creates the thread. Later requests send only new messages and the previous response ID.
• Threads live in server memory, encrypted, and are never written to disk. A thread expires 5 minutes after its last request. After that, you resend the full conversation to start a new one.
• Median time to first token (TTFT) fell by about 35% on requests of 500k to 1M tokens. The figure comes from Claude Code, where threads are already on by default for most users.
• Pricing and rate limits are unchanged. Token usage is unchanged.
• The beta is available on the native Claude API, Claude Platform on AWS, Microsoft Foundry, and Claude Models on Google Cloud (Anthropic managed).
• The beta header is message-threads-2026-08-12, and the docs list every current model from Fable 5.1 down to Sonnet 4.5 as supported.

Why upload time became a problem

LLM APIs are stateless. The model does not remember your last request, so the client resends the entire conversation every time. For a human chatting, that is fine. A few dozen turns, a few tens of thousands of tokens, done.

Coding agents are different. One session can fire hundreds of requests, each dragging along every file read, command output and screenshot from before. Once the history hits hundreds of thousands of tokens, just uploading it and having the server validate and tokenize it again adds real delay before the first character appears. Anthropic's docs put it plainly: without a thread, "every turn uploads the whole conversation again, and the API validates and tokenizes all of it again."

Anthropic had already attacked the compute side with prompt caching, which makes repeated prefixes cheaper to process. Message threads go after the transport side that caching never touched. They solve different problems. Keep that in mind while reading any headline about this launch.

How it works

There are only two kinds of request.

Request flow with message threads

1. CreateSend the full conversation plus system and tools, with thread: {type: create}. The API stores it under the response id.
2. ContinueSend only new messages with thread: {type: continue, previous_message_id}. Leave system and tools out.
3. Next turnUse the latest response id for the next continue. Every request resets the 5-minute timer.
4. Expiry or errorAfter 5 minutes, or on a 404 thread_not_found, create a new thread from the full conversation. So the client must keep its own copy.

The step to underline is the last one: the client must keep the conversation. The server throws it away after five minutes.

A few more rules from the docs that will bite you if you skip them.

• Fixed fields. model, tool_choice, thinking, the top-level cache_control and a few others must be identical on every request in a thread. Change one and you get a 400 with thread_fingerprint_mismatch. Switching models means starting a new thread.
• Caching is not automatic. A thread holds the conversation; it does not cache it. To cache every turn, send a top-level cache_control on every request. A thread request allows at most 4 cache breakpoints.
• Streaming. The response id arrives in message_start, but only continue after message_stop. Continue too early and you can get a 404.
• Not supported. Message Batches, token counting and on-demand compaction cannot be combined with threads.
• Refusals. If stop_reason is refusal, do not continue that thread. The refused turn cannot be removed server-side, so start fresh.
• SDK helper. The official SDKs ship a thread helper that adds the beta header, strips system and tools from continue requests, resends the full conversation after expiry, and offers fork(). A fork's first turn sends the whole conversation again.

Why cost stays the same

Anthropic's own words: Claude "still reads the full conversation every turn, so token usage is unchanged." Threads shrink the bytes you send, not the tokens the model processes. If you want a smaller bill, prompt caching is still the tool, and you still have to design it yourself.

How to read the 35%

The stated conditions are: requests of 500k to 1M tokens, median TTFT, measured across Claude Code users. Short conversations will see little or nothing, because there was never much to upload. And this is Anthropic's own measurement. No third party has published numbers yet.

Other views and open questions

A daily.dev roundup of developer reaction (2 X threads, 204 comments as of November 3) tallied roughly 45% positive, 35% mixed, 20% skeptical. Most of the concerns have answers in the docs.

• "Five minutes is too short." Workflows that pause for human review or long test runs may keep tripping the expiry. The docs do not say whether it is configurable. The SDK recreates the thread for you, so the cost is one slower turn now and then.
• "My conversation sits on their server." The docs say threads stay in memory only, never touch durable storage, and are deleted no more than one hour after last use. But threads are explicitly not eligible for Zero Data Retention. If you have a ZDR agreement or handle regulated data, this feature is off the table. That is not a counterargument; it is a constraint.
• "Does it work on Amazon Bedrock?" Commenters said no. The official docs list "Claude Platform on AWS" as beta. Those are not the same name, and which AWS path is covered has not been clarified.
• "What about cache billing?" Threads do not touch pricing. Cache write and read rates follow the existing prompt caching rules.

For comparison, OpenAI's Responses API has previous_response_id, which plays a similar role. OpenAI's docs also state that all previous input tokens in the chain are billed as input tokens. So both companies reduce transport, and neither reduces billing. The difference is retention. OpenAI stores response objects for 30 days by default (you can set store: false), and its separate Conversations API has no such limit. Anthropic expires threads in five minutes and never writes them to disk. One design leans toward convenience, the other toward minimal retention.

What this means for you

If you build agents on the Claude API

• If you have loops where the conversation grows into hundreds of thousands of tokens (coding, computer use, document-heavy work), try the SDK thread helper first. It handles the beta header and fixed fields for you.
• Treat speed and cost as separate projects. Cost only drops when you send cache_control on every request inside the thread.
• Branch on error.details.error_code. A 404 thread_not_found means replay the full conversation. A 400 thread_fingerprint_mismatch means you changed a fixed field.
• Keep your own copy of the conversation. The server is not your database.

If your organization has ZDR or health-data terms, you cannot use this. Note that the SDK's beta tool runner turns threads on by default, so check how to disable it.

If you use Claude Code, it is probably already on. The first character in long sessions arriving a bit sooner is the effect.

If you are a user or investor, nothing changes today. But it is worth noticing that both major API vendors are moving more conversation state onto their servers as agents run longer.

What to watch

• When the beta goes GA, and whether the 5-minute expiry changes with it.
• Whether ZDR eligibility changes. Today it is explicitly "not eligible."
• The exact AWS coverage, including Bedrock.
• Independent TTFT measurements. Right now the only number is Anthropic's.

Closing

I build small apps alone, so I rarely run agent loops long enough for this to matter yet. Still, reading the announcement, I kept thinking that recent AI API progress is less about "the model got smarter" and more about "you wait less for the same model." It is not glamorous. But for a tool you use every day, that is where you feel it.

When you run an agent, which bothers you more: the pause before the first character, or the invoice?

Sources

• Anthropic, "Make long-running agents faster with message threads" (2026-11-02): https://claude.com/resources/articles/message-threads
• Claude Platform docs, "Message threads": https://platform.claude.com/docs/en/build-with-claude/message-threads
• OpenAI docs, "Conversation state": https://developers.openai.com/docs/guides/conversation-state
• The Next Web, "Anthropic's message threads let Claude agents skip resending chats": https://thenextweb.com/news/anthropic-message-threads-beta-claude-api-agents
• daily.dev, "Anthropic adds message threads to the Claude Messages API in public beta": https://daily.dev/posts/anthropic-adds-message-threads-to-the-claude-messages-api-in-public-beta-a4vfrfrii