Anthropic has launched message threads in public beta for the Claude Messages API, giving long-running agents a way to stop uploading their entire conversation on every turn. The feature is available now on Anthropic’s native platform, Claude Platform on AWS, Anthropic-managed Claude Models on Google Cloud, and Claude in Microsoft Foundry.
Anthropic reports that most Claude Code users already have threads enabled. In requests carrying 500,000 to 1 million tokens of context, the company measured about a 35% reduction in median time to first token. The improvement is about network and request-processing latency: Claude still reads the reconstructed conversation, so token prices and rate-limit accounting do not fall simply because an application uses a thread.
The release gives developers a cleaner transport for the longest agent sessions, but it is not durable conversation storage. A thread expires five minutes after its last request, can disappear before the next turn, and is not eligible for zero data retention or HIPAA workloads. Production integrations therefore need a replay path from the first day they adopt it.
How Claude message threads change an agent loop
Without a thread, a client sends the system prompt, tool definitions, prior user messages, Claude replies, tool calls, and tool results again on every request. Anthropic must validate and tokenize that growing payload before generation begins. A coding or research agent that makes hundreds of turns can spend an increasing amount of time moving old context back to the API.
With a thread, the first request sends the full conversation and adds {"thread":{"type":"create"}}. Later requests include only new messages plus the ID of the previous response:
second = client.beta.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Run the next test."}],
thread={
"type": "continue",
"previous_message_id": first.id
},
betas=["message-threads-2026-08-12"],
)The server rebuilds the conversation before calling the model. The client omits system and tools after the create request, while continuing to send fixed fields such as the model, thinking configuration, context-management settings, output configuration, and beta headers with the same values. A mismatch produces a thread_fingerprint_mismatch error.
Some controls can change from turn to turn, including max_tokens, streaming, metadata, stop sequences, and service tier. MCP server URLs and authorization tokens are not stored with the thread, so applications using MCP must keep sending those values. Anthropic’s SDK helper handles much of this request bookkeeping automatically.
The five-minute expiry makes replay mandatory
Each stored response restarts a five-minute inactivity clock. Anthropic says a thread is deleted no more than one hour after its last use, but a client should expect a continuation to return a 404 as soon as the five-minute window has passed. The API response does not tell the client whether a turn was successfully stored.
That design leaves the application, not Anthropic, as the authoritative record. Developers need to keep every message and tool result in their own store. When a continuation fails with thread_not_found, the client sends the complete conversation in a new create request, then continues from the new response ID. The SDK helper keeps a full copy in memory and can replay once, but it does not persist that history when the process exits.
Threads are also append-only. Each response ID can be continued once, from the latest turn. Editing an earlier user message, branching from an older reply, changing the system prompt, or replacing old turns with a summary requires a new thread. If an agent pauses mid-turn, the client resumes with an empty message list; sending a new user message while the turn is paused is rejected.
Fallbacks add another edge case. If a server-side fallback model answers, Anthropic does not store that turn in the original thread. The next request must recreate the thread from the complete conversation or deliberately move the session to the fallback model.
Threads and prompt caching solve different problems
Message threads shrink what the client uploads and reduce pre-generation processing. They do not automatically cache the prompt and do not reduce billed input tokens. Teams seeking lower repeat-input costs still need Anthropic’s prompt-caching controls.
The two features can be combined. A top-level cache_control value on every request asks the API to cache each new turn while the thread handles transport. Anthropic limits threaded requests to four cache breakpoints, and the top-level setting counts as one. Because that setting is part of the thread fingerprint, it must remain identical throughout the session.
This distinction should shape performance tests. Teams should measure request-body size and time to first token separately from cached-input usage, total input tokens, end-to-end task time, and retry frequency. A shorter upload can make an agent feel faster without changing its model bill.
Short-lived state also creates compliance boundaries
Anthropic describes thread data as encrypted in memory and not written to disk, but its documentation marks the beta as ineligible for zero data retention and HIPAA. Regulated applications should not treat the brief retention window as equivalent to a contractual no-retention mode.
The same constraint affects mixed deployments. A team cannot assume that an agent approved for ordinary internal code or support work is also approved for protected health information merely because the thread expires quickly. Workload classification should happen before an application turns the beta on.
Claude’s design is notably more ephemeral than Google’s Interactions API. Google also lets clients continue with a previous interaction ID, but its documentation says stored interactions are retained by default for 55 days on paid tiers and one day on the free tier. Google allows stateless calls with store=false; Anthropic’s threads instead favor active, tightly spaced loops and require the application to own durable history.
What developers should test before enabling threads
A safe rollout begins with a replayable transcript store and an integration test that deliberately waits longer than five minutes. The client should distinguish a missing thread from a missing model, because both can return 404 responses. It should also test duplicate submissions, concurrent continuation attempts, dropped streams, paused turns, refusals, fallback responses, and process restarts.
Applications should monitor the share of turns that use a lightweight continuation versus a full replay. Frequent replay requests can erase much of the latency benefit, particularly for large conversations. Very large histories may also be impossible for the service to store as a thread; Anthropic advises falling back to ordinary unthreaded requests if replay immediately fails again.
The beta is best suited to dense sessions in which an agent makes repeated calls within a few minutes: coding loops, computer-use workflows, document analysis, and tool-heavy research. It is a poor substitute for a database, a user-facing chat archive, or a session expected to sit idle for hours.
Developers can review Anthropic’s message-threads documentation and platform release notes. Google’s Interactions API documentation provides a useful comparison for teams deciding how much conversation state to place on a model provider’s servers.
