Until now, every request to the Claude Messages API had to carry the entire conversation: the system prompt, the tool definitions and every earlier turn. On 2 November, Anthropic released message threads in beta, which let the API hold the conversation on its side for a short time. After the first request, your application sends only the new messages and the id of the previous response. Anthropic says this keeps requests small and the time to the first token lower and steadier as a conversation grows. For anyone running long agent loops, that is a practical change worth testing this week.
What Anthropic released
The feature is listed in the Claude Platform release notes for 2 November and documented on its own page. It is a beta, switched on with the header message-threads-2026-08-12, which must be sent on every request in a thread. The release notes say threads are available on the Claude API, Claude Platform on AWS, Anthropic-managed Claude models on Google Cloud and Claude in Microsoft Foundry. Amazon Bedrock and Google Vertex AI are not on that list.
The supported models include the current lineup, such as Claude Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1, as well as several older models back to Claude Sonnet 4.5.
How a thread works, step by step
Anthropic's documentation describes three moves:
- The first request sends the full conversation, the system prompt and the tools, and adds a thread parameter of type create.
- Each later request sends only the messages since the previous response, plus a thread parameter of type continue with the previous_message_id. You leave out the system prompt and the tools.
- The API rebuilds the full conversation before calling the model, and the response comes back as a normal message.
A few rules keep the thread consistent. Settings such as the model, tool choice and thinking must stay the same on every turn, or the API returns a 400 error that names the fields that differ. Each response id can be continued once, and a thread only grows forward, so editing or branching a conversation needs a fresh create request. Anthropic's SDKs include a thread helper that adds the header, leaves out the system prompt and tools on later turns and replays the full conversation once if the thread has gone.
The limits that matter
The biggest limit is time. According to the documentation, a thread is best effort. It expires 5 minutes after its last request, each stored response restarts that timer, and the API deletes the thread no more than an hour after its last use. If a continue request arrives after expiry, it returns a 404, and you must send the full conversation again in a new create request. Anthropic is explicit that your application remains the source of truth, so you still store the full history yourself. No response tells you whether the API stored that turn; you only find out on the next continue request.
Three other limits are easy to miss. A thread does not cache your prompt automatically; you still add cache_control if you want prompt caching, with at most four cache breakpoints per request. Threads are not eligible for zero data retention, and organisations with HIPAA readiness enabled cannot use them, although Anthropic says thread contents are held in memory, encrypted and never written to durable storage. Batch requests and token counting do not accept the thread parameter either.
How it compares with OpenAI and Google
Claude is not the first API to offer server-side conversation state, but it has chosen a much shorter memory. Microsoft's documentation for the Azure OpenAI Responses API says turns are chained with a previous_response_id and that response data is retained for 30 days by default, with an option to delete a stored response. Google's Interactions API for Gemini uses a previous_interaction_id and, according to its documentation, keeps interactions for 55 days on the paid tier and 1 day on the free tier, with a setting to turn storage off.
Those longer windows suit apps where a user returns to a chat hours or days later. Claude's five-minute window fits a different job: agent loops and live chats where requests arrive seconds apart. It also means less of your data sits on a provider's servers. We think the short window is a sensible trade for agent builders, as long as your code handles the 404 cleanly and falls back to a full request.
Who should switch it on
- Developers running agents that make many tool calls in a row, where each request currently resends a long history.
- Teams with long support or coding conversations that see slower first tokens as chats grow.
- Not yet: organisations that require zero data retention or have HIPAA readiness enabled, and teams that only call Claude through Bedrock or Vertex AI.
What to do this week
- Pick one long-running agent and add the beta header and a create request on its first turn.
- Log request size and time to first token before and after, so you can see the gain on your own workload.
- Write the fallback first: on a 404, resend the full conversation with a new create request.
- Keep your own conversation store, since the thread is a short-term copy.
If you are still choosing which Claude model to run in that loop, our guide to Opus, Sonnet, Haiku and Fable covers the trade-offs, and the Claude course in Learn starts from the basics.