On November 2, Anthropic opened a public beta of message threads on the Claude Platform. Developers add a thread parameter to a Messages API request, send the full conversation on the first turn, and from then on send only the new messages plus the ID of the previous reply. The server stitches the conversation back together.
The performance figure Anthropic cites comes from Claude Code. The feature is already on by default for most Claude Code users, and on requests of 500k to 1M tokens the median time to first token falls by about 35%. The company's blog does not list results for other length ranges.
The beta covers the Claude API, Claude Platform on AWS, Microsoft Foundry, and Claude hosted by Anthropic on Google Cloud. The documentation lists supported models running from Sonnet 4.5 and Opus 4.5 up to Fable 5.1 and Mythos 5.1.
What gets saved is validation and tokenization
Without threads, an agent re-uploads the entire conversation on every turn, and the API has to validate and tokenize it all over again. The longer the session, the longer that preparation takes. Computer-use agents suffer most, since historical screenshots have to be sent again each turn.
Threads hold that content in server memory, so the work per request shrinks to little more than the newly added turn.
Claude still reads the whole conversation on every turn, so the model-side token count does not go down, and billing and rate limits follow the existing rules. A rough calculation shows the effect: in an 800,000-token session that adds 2,000 tokens per turn, a threaded request carries roughly one four-hundredth of what it used to, yet the bill still shows more than 800,000 input tokens. Saving money still depends on prompt caching, which is a separate switch. A threaded request can carry a top-level cache_control; without it, sending only the new messages means nothing gets cached.
Build in a fallback
The documentation defines threads as “best effort,” and that shapes how you should integrate them.
- Expiry: a thread expires 5 minutes after the last request, the timer resets each time a reply is stored, and the thread is deleted at the latest 1 hour after its last use.
- Invalidation: once a follow-up request returns a 404, you must resend the full conversation and start a new thread. The response does not tell you whether a given turn was stored successfully; you only find out on the next follow-up.
- Copies: the authoritative version of the conversation still lives on the application side. The official SDK helpers keep a copy in memory and replay it automatically, but it disappears when the process ends, so anyone who needs persistence across processes has to store it themselves.
- Fixed fields:
systemandtoolsare sent only when the thread is created, and including them in a follow-up, even as null, triggers a 400 error. Fields such asmodel,thinking,tool_choiceandmcp_serversmust be resent unchanged on every turn; changing them returnsthread_fingerprint_mismatch. To switch the system prompt or tools, you have to open a new thread.
There is a compliance limit as well. Thread contents are encrypted in memory and are not written to persistent storage, but the feature does not qualify for zero data retention (ZDR). Enterprises with a ZDR agreement are unaffected on other features, but cannot use threads.
Developers should also keep two things apart: Claude Managed Agents has its own session threads, which are a different thing from the message threads announced here.
Filling a gap
OpenAI's Responses API has long offered previous_response_id, which likewise passes an ID to pick up from earlier context. Anthropic has long required clients to send the full history every turn, which is stateless and straightforward but costs latency as conversations grow. This release is a compromise: state stays on the server only briefly, a lost thread is simply replayed, and the client-side copy remains indispensable.
Judging by the use cases Anthropic lists, the main targets are long-running coding agents, computer-use agents, and workflows heavy on documents and images. Anthropic also switched the feature on by default in its own Claude Code first, before opening it to API users.
For ordinary conversations shorter than a few hundred thousand tokens, Anthropic gives no figures on the gain; the documentation says only that threads help most in long agent loops. Teams building their own agents would do well to run a test against their own session-length distribution first, then decide whether it is worth writing an extra layer of code for that 404 replay path.
Sources: Claude official blog, CocoLoop, Claude Platform developer documentation; the latency reduction is the Claude Code median published by Anthropic, and the rough calculation is the editor's own estimate.