Anthropic launched Anthropic message threads in public beta on Monday, giving software engineers on its Messages API a way to run multi-turn agent sessions without re-uploading complete chat histories on every turn. The update targets active, latency-sensitive workflows such as autonomous coding tools and computer-use agents.
Key points
- Developers can now transmit only new messages after an initial setup call, eliminating repeated client-side uploads and tokenisation.
- Median time to first token dropped by 35% on conversations holding between 500,000 and one million tokens during internal tests with Claude Code.
- Threads reside solely in server memory, expire after five minutes of inactivity, and are permanently wiped within one hour.
- Applications must maintain their own local conversation logs because the API offers no endpoints to view, list or retrieve stored threads.
As enterprise engineering teams deploy autonomous software for longer tasks, conversational payloads expand quickly. When agents inspect codebases, execute terminal commands, or capture periodic desktop screenshots, context windows fill up with hundreds of thousands of tokens. Anthropic introduced message threads in public beta to stop clients repeatedly serialising that data across the network on every successive step.
Under the standard Messages API design, every single interaction requires the client to upload the entire chat history from turn one. The platform must then validate, parse and tokenise the entire historical transcript before generating an answer. With message threads enabled, that processing overhead applies only to the newest turn before Anthropic’s backend reconstructs the conversation for the model.
How message threads handle API requests
The official documentation splits the thread lifecycle into two distinct stages: create requests and continue requests. During a create request, the client application passes the initial prompt, tool declarations, system configuration and the complete conversational history alongside a thread parameter. Once processed, the API stores the conversation and Claude’s response in volatile memory under an individual response identifier.
Subsequent turns use continue requests. These payloads omit the system prompts, tool schemas and prior context entirely, transmitting only the messages accumulated since the previous turn alongside the latest response identifier. Each response then generates a fresh identifier that the client uses to anchor the subsequent turn.
Because the mechanism operates on an append-only structure, each response identifier can be continued only once. If an agent needs to change its system prompt, swap available tools, or alter a fixed configuration field, it must open a new thread by submitting the full conversation from scratch.
What threads mean for latency and cost
While the architectural change reduces network payload sizes and speeds up processing queues, it does not alter basic model pricing. Claude still reads the full historical conversation on every turn to maintain context. Token usage remains unchanged, and standard token billing rates and rate limits apply across all accounts.
The primary advantage lies in speed. Anthropic enabled message threads by default for most Claude Code users and measured performance on heavy context loads. On requests holding between 500,000 and one million tokens, median time to first token fell by roughly 35%. That speed increase proves especially useful for AI coding agents, where developers otherwise spend valuable minutes waiting for continuous build-and-test loops to begin responding.
Computer-use agents gain similar advantages. Desktop automations frequently bundle high-resolution screenshots into conversational turns, creating bandwidth bottlenecks when sending full histories. Under message threads, those image assets stay anchored to the server-side thread rather than moving across the network repeatedly.
Memory retention, security and caching rules
Anthropic designed the thread infrastructure as an ephemeral cache rather than a persistent database. Threads expire automatically five minutes after their most recent request. Each successful continue request resets that five-minute countdown timer. Across all sessions, the platform purges thread contents from memory no more than one hour after last use.
Data security follows strict memory isolation. Thread contents remain in memory protected by server-managed encryption and are never committed to durable disks. Any files supplied during an agent run are held by reference, meaning client applications must keep external source files accessible for the duration of the session.
Because the platform stores these conversational states in memory, message threads are not eligible for zero data retention or HIPAA workloads. Anthropic clarified that enabling the feature on standard workspaces does not compromise an organisation’s eligibility for other zero-data-retention features across the broader platform.
Prompt caching rules also require developer action. Threads do not automatically cache prompt tokens; engineers must still configure manual cache breakpoints or top-level cache parameters. Each threaded request supports up to four cache-control breakpoints.
Platform availability and current limits
The public beta is active across all Claude models on the native Claude Platform, Claude Platform on Amazon Web Services, Claude in Microsoft Foundry, and managed Claude instances on Google Cloud. The feature represents a technical milestone in Anthropic’s commercial expansion into high-frequency enterprise agent tooling.
Several constraints govern early adoption. The API does not provide administrative endpoints to list, inspect or delete active threads. Threads also do not work with Message Batches, real-time token counting endpoints, on-demand context compaction, or custom inference hooks.
Developers using streaming must wait for the message_stop event before submitting their next continue request, as earlier calls trigger 404 errors. If a fallback model handles a turn during an unexpected service interruption, the backend cannot save that state, forcing the client to retransmit the full conversation in a fresh create call. Because threads remain best-effort and expire quickly, engineering teams must maintain complete local transcripts and preserve a full replay path in their production software.
