Claude Messages API adds server-side message threads in beta

Anthropic has put message threads into public beta on its Messages API, the interface developers call to send Claude a conversation and get its reply. Without a thread, every turn of a chat or agent loop uploads the whole conversation again, and the API validates and tokenizes all of it again. With a thread, the first request sends the full conversation along with the system prompt and tools, and the API stores it under the ID of Claude's response. Each later request sends only the new messages and the ID of the previous response, and the API rebuilds the conversation before it calls the model (Anthropic documentation).

The benefit is speed. The ClaudeDevs announcement says Claude "starts responding sooner," and the documentation says the wait for the first token stays lower and steadier as a conversation grows, with long agent loops gaining most. Neither gives a measured figure. The post says the API caches the conversation, but that storage is not prompt caching: the documentation says a thread "does not cache your prompt for you," and developers who want prompt caching still request it with its own cache_control setting. Threads do not change pricing or rate limits.

The stored copy is brief and best-effort. A thread expires five minutes after its last request, and the API deletes it no more than an hour after its last use. It is held in memory and never written to durable storage, and the feature is not eligible for zero data retention. When the API can no longer continue a thread, the request returns a 404 error, and the application has to resend the full conversation to start a new thread. Anthropic tells developers that their application stays the source of truth and should keep its own copy of every message; the SDK's thread helper keeps that copy in memory only, and performs the resend automatically.