Anthropic put message threads into public beta on November 2. The point is simple: an agent should no longer re-upload the entire conversation on every turn.
How it works
Until now, every Messages API request carries the whole conversation, tool results included. A coding agent making hundreds of requests in one session ends up sending hundreds of thousands of tokens before Claude says a word.
With message threads you add a thread parameter. The first request contains the full
conversation and opens the thread. Every request after that sends only the new messages
plus the ID of the previous response. You need the beta header
message-threads-2026-08-12.
The number Anthropic puts on it: for requests between 500k and 1M tokens, median time to first token drops by about 35%. For most Claude Code users the feature is already on by default.
Five minutes, in memory
Between turns Anthropic holds the thread in memory, encrypted and never written to disk. It expires five minutes after the last request, and is deleted no more than an hour after last use. After that your client resends the full conversation and starts a new thread.
For error handling that means the full-history path stays the normal case and must not rot. Test it only on the first call and you will discover in production that it is needed after every pause.
Where it pays off
Anthropic names three cases: long-running coding agents, where every tool result and file edit extends the conversation; computer use agents, whose screenshots stay with the thread instead of being re-uploaded each turn; and document- or image-heavy workflows. The more context an agent carries, the bigger the effect.
It is available on the native Claude Platform, on Claude Platform on AWS, in Claude in Microsoft Foundry, and on Claude Models on Google Cloud in the Anthropic-managed variant. Standard token rates and existing rate limits apply.
It does not shrink the bill
Here is the line that is easy to skip: Claude still reads the full conversation on every turn. Token usage stays the same, and so does the cost. What gets smaller is only the payload crossing the wire.
So message threads is a latency feature, not a savings feature. If you want a cheaper bill you still need prompt caching and a shorter context. If you are sitting there waiting for an agent to answer, you get a real 35%.