Anthropic adds message threads to the Claude API so long agent loops stop resending everything

Anthropic released message threads in public beta on November 2. The feature is aimed at an unglamorous problem in agent engineering: the Messages API is stateless, so a long-running agent re-uploads its entire conversation on every turn, and the API has to receive, validate and tokenize all of it again before the model starts answering. The deeper an agent gets into a task, the more of each turn goes into that overhead.

How it works

According to the documentation, a client adds a single `thread` field to a normal Messages API request. The first request sends the full conversation, with the system prompt and tools, and sets the thread type to "create". The API stores that conversation, including Claude's reply, under the response ID. Each later request sets the type to "continue", passes the previous response ID and carries only the messages added since then. System prompt and tools are left out of those requests; the thread keeps the values from the first one.

The feature uses the `message-threads-2026-08-12` beta header, and Anthropic's SDKs include a thread helper that builds these requests and handles recovery. It is available on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Claude in Microsoft Foundry, per the release notes.

What it does and does not save

The gain is latency, not cost. Anthropic's announcement says Claude still reads the full conversation on every turn, so token usage is unchanged, and standard token prices and existing rate limits apply. Prompt caching is also unchanged: threads do not cache anything on their own, and developers still choose where cache breakpoints go, with a limit of four breakpoints per threaded request.

The headline number is Anthropic's own. The company says message threads are on by default for most Claude Code users, and that requests of 500,000 to 1 million tokens see median time to first token drop by about 35%. It gives no figure for shorter contexts beyond saying the benefit grows with the amount of context an agent carries. No independent benchmark is available yet.

The constraints

Threads are deliberately short-lived. A thread expires 5 minutes after its last request and is deleted no more than an hour after its last use. Contents are held in memory, encrypted, and never written to durable storage. When a thread can no longer be continued, the API returns a 404 and the client must resend the whole conversation in a new create request. The documentation tells developers to keep their own copy of every message and to build that replay path from the start.

• Threads are append-only. To compact a conversation, you write the summary yourself and start a new thread from it; built-in compaction is not available with threads.
• Message Batches, token counting and most context editing are not supported, and a request that uses them is rejected.
• Fields such as model, thinking settings and tool_choice must stay identical across a thread; changing them returns a 400 error.
• After a refusal, or a reply written by a fallback model, the thread cannot continue from that response, and the client starts a new one.
• The feature is not eligible for zero data retention, and organizations with HIPAA readiness enabled cannot use it.

What changes for developers

For anyone running coding agents, computer-use agents or document-heavy workflows on Claude, this is mostly a latency and bandwidth optimization that sits next to prompt caching rather than replacing it. Caching reduces what you pay for repeated context and can speed up processing; threads remove the need to resend that context at all. The 5-minute expiry matches the pacing of an active agent loop, but agents that pause for human review or slow tools will often fall back to the full-resend path. That makes the replay logic a requirement, not an edge case.

There is also a design trade-off. Today, many agent frameworks rewrite history on each turn, trimming tool output or swapping old turns for summaries. A thread only appends, so that kind of context management has to happen at deliberate break points, by starting a fresh thread. Teams that lean on aggressive history editing may get less out of threads than teams whose loops simply grow.