Claude API eliminates resending history, but it doesn't save money—and it doesn't save local archives

Anthropic has launched a public beta of message threads for the Messages API. When developers call Claude, the server temporarily stores the conversation for a few minutes, and on the next turn they only send the new message and the ID of the previous reply.

Previously, this API did not remember historical messages, and every request had to resend all previous messages and tool results from the beginning. An agent session might send hundreds of requests; once the conversation grows to hundreds of thousands of tokens, just resending it can slow down how long it takes Claude to start responding. Claude Code has already enabled this feature by default for most users.

Anthropic's data shows that for requests of 500,000 to 1,000,000 tokens, the median wait from sending the request to Claude starting output is shortened by about 35%. In long conversations, the median size of a single request drops from about 800 KB to 1.8 KB.

One user summarized the change in three sentences: previously Claude received the full history every turn; now only new messages are sent; the result is faster responses for long tasks.

Source: Vishal Singh's tweet

Billing hasn't changed. You are charged at standard token prices, and rate limits are unchanged. Even though the request body is smaller, Claude still has to read the full conversation every turn, so token consumption is the same as before. What you save is upload time and time to first token; the token bill will not decrease.

It is different from prompt caching. Prompt caching lets the server avoid reprocessing content it has already read, and the cached portion is billed at a lower price, saving money and compute. Message threads save on upload; they do not automatically cache, and you still have to set cache breakpoints yourself. The official examples use both together.

Developers need to add the thread parameter and the beta request header message-threads-2026-08-12 to requests. In the first turn, send the full conversation, system prompt, and tool definitions as usual, and mark it as a new thread. After that, each turn sends only the new message along with the ID of the previous reply.

A thread expires if there are no new requests for 5 minutes, and the API returns 404; at that point you must recreate a thread using the full conversation you saved yourself. You still need to keep a complete local record, and the official SDK's helper methods can handle this step automatically. You cannot change the system prompt or tools midway through a thread, and the model and thinking settings must match the first turn; if you want to change them, you must start a new thread. Thread data is stored encrypted in memory and not written to disk, but zero data retention (ZDR) and HIPAA compliance are not supported. Enterprises with strict data retention requirements should pay attention. The Batch API is not yet supported.

It is suitable for long-running agents and computer-use agents, where screenshots no longer need to be resent every turn, as well as conversations with large numbers of documents and images. It is available on Anthropic's own platform, AWS, Microsoft Foundry, and the Anthropic-managed version on Google Cloud.

The limitations are also very concrete. One user said an agent got stuck on something and thought for six minutes; when it came back, the thread had already returned 404, and it had to dig out the complete local record and start over, effectively back to square one. Another user warned that those using a proxy or a multi-key pool may not benefit: a thread is tied to the same key and workspace, and after rotating the key pool, the next turn may directly return 404 thread_not_found. Another user added that threads can only be appended to, and deleting a failed call also requires starting a new thread.

One immediate takeaway is that this feature takes over the heavy lifting of moving long conversations, but leaves the responsibility for archiving to developers. It suits continuous, high-frequency agent sessions, not scenarios where a human goes to make a cup of coffee and comes back. Five minutes is just enough time to pour a glass of water; when you return, first check whether the thread is still alive.

Blog: https://claude.com/resources/articles/message-threads
Docs: https://platform.claude.com/docs/en/build-with-claude/message-threads