Anthropic's five-minute Claude message threads push conversation storage back to developers

Anthropic has moved message threads into public beta on its Messages API, letting agents upload a conversation once and then send only new turns instead of the entire history. As Gabriel Anhaia reports in a dev.to write-up, the feature shrinks request payloads and cuts latency, but the server keeps the thread alive for just five minutes between requests — which means the real home for an agent's conversation still has to be the developer's own storage.

What shipped

According to Anthropic release notes cited in the post, threads went live on November 2 behind the message-threads-2026-08-12 beta header and a new thread request field. Previously, turn 200 of an agent loop looked like turn 1, only bigger: the whole conversation was re-uploaded and re-tokenized every time. Now the full history travels once, and subsequent requests carry only the newest messages plus the id of the previous response.

Anthropic's launch post claims median time to first token drops by about 35 percent on requests between 500K and 1M tokens, though Anhaia notes that figure is Anthropic's own and applies only to very long sessions. The docs say threads are already on by default for most Claude Code users and are in beta on every model. The feature works on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Microsoft Foundry.

Create, continue, replay

There are three request shapes. A create request is a normal first call that establishes the thread. A continue request sends only new messages and references the previous response by id. A replay is a fresh create carrying the full conversation — the recovery route when the server can no longer continue.

The SDKs ship a helper that handles the bookkeeping, but hand-rolled loops face strict field rules. The system prompt and tools are create-only; sending them on a continue, even as null, returns a 400. Fixed parameters such as model, tool_choice and thinking must match the original create or the API responds with thread_fingerprint_mismatch, while max_tokens, stop_sequences, stream and metadata may change freely. The API also performs no deduplication, so an accidentally resent message can appear twice in the conversation. Each response id can be continued only once, threads are append-only, and streamed responses can only be continued after message_stop.

The five-minute clock

The docs describe threads as best-effort. The expiry window resets with every response the API stores, but an agent waiting on a slow test suite or a human approving a tool call can easily come back to a dead thread. When that happens, a continue request fails with a 404 thread_not_found, and the error gives no explanation. Listed causes include expiry, a turn the API served but never stored, a response written by a fallback model, a different API key or workspace, and the first image appearing in a conversation that previously had none. Crucially, no response ever indicates whether a turn was stored — clients only discover it on the next request. Threads live in memory rather than durable storage and are deleted no more than an hour after last use.

Same tokens, same price

The docs state that threads change neither pricing nor rate limits, and the launch post clarifies that the model still reads the full conversation every turn, so token usage is unchanged — only upload size and pre-processing work shrink. Prompt caching remains the developer's job: a thread does not cache the prompt automatically, so cache_control breakpoints must still be sent, with a maximum of four per request before a 400 error. Anhaia compares the design to OpenAI's Responses API, whose previous_response_id similarly chains turns without resending history — but OpenAI retains response objects for 30 days by default, versus Anthropic's minutes-scale, in-memory thread.

Persistence is still your job

The design the docs prescribe is unchanged: keep the full conversation on your side, treat the thread purely as an optimization, and build the replay path from day one. The SDK helper retries once on thread_not_found, thread_already_continued and thread_continue_in_flight, and starts a new thread after refusals, but it holds the conversation only while the helper object exists. Agents running as queue workers, serverless functions or anything else that restarts must persist messages externally. The beta tool runner also uses threads by default and can be switched off.

Several setups cannot use threads at all: zero data retention and HIPAA customers are excluded, orgs with HIPAA readiness or inference hooks are rejected, message batches, token counting and on-demand compaction do not work, context editing is unavailable except one narrow mode, and there is no API to list, read or delete a thread.

Why it matters

The five-minute lifetime turns this from a persistence feature into a latency optimization with sharp edges. Long-running agents — exactly the workloads threads aim to serve — routinely pause longer than five minutes on tests, reviews or human approvals, so every thread-based loop needs a durable conversation store and a tested replay path or it will fail in production. The gap with OpenAI's 30-day retention also means teams porting between the two APIs cannot share a persistence design. For short sessions the payoff is minimal since resending costs grow with conversation length; for long, steady-turn loops within a single process, the beta is worth trying behind a flag with the unthreaded path kept as a fallback.