Claude Message Threads Speed Up Long Agent Loops

On November 2, 2026, Anthropic put message threads into public beta for Claude’s Messages API. A long-running agent can now send its full conversation once, then send only new messages and the previous response ID on later turns. That can reduce time to first token, but token pricing and rate limits stay the same. A thread expires five minutes after its last request, so an application still needs its own complete conversation history to recover. These are the release notes and feature rules, not the result of a DailyTech test.

What changes in each request

Without threads, a client sends the earlier messages again on each turn. With threads, the first request still includes the full conversation, system prompt and tools. It adds thread: {"type": "create"}. A later request sends only messages added since the last response and thread: {"type": "continue", "previous_message_id": "<last response id>"}. The beta header message-threads-2026-08-12 goes on every request. The documentation shows both request forms.

Decision point	Standard request	Thread request
First turn	Full conversation and configuration	Full conversation and configuration, plus create
Next turn	Resend earlier messages with the new ones	New messages and previous response ID, plus continue
Server history	Rebuilt from each request	Kept briefly for the next request
Token bill and rate limits	Standard rules	Same standard rules
After inactivity	Client sends its history as usual	Client may need to replay its history in a new create

The application must keep its own message log. The API does not promise that a successful response was stored for a later continuation, and it offers no endpoint to list, read or delete threads. On a continue request, leave system and tools out entirely; sending either, even as null, causes an error. Some other settings, including the model and beta-header set, must remain fixed within a thread. To change one, start a new thread with the full conversation. See Anthropic’s field rules before adapting a request builder.

Anthropic lists the beta on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Claude in Microsoft Foundry. The company identifies long coding agents, computer-use agents with screenshots, and document or image-heavy sessions as good candidates. This is a transport and latency change for active conversations; it does not enlarge a model’s context window. The AI model tracker helps compare models separately from this API feature.

Faster starts do not mean cheaper tokens

Anthropic reports about 35% lower median time to first token for Claude Code requests carrying 500,000 to 1 million tokens when threads are enabled for most users. That is a company-reported result for that workload, not a forecast for every app and not an independent benchmark. A short chat or an agent that pauses often may see a different result. The gain comes from sending and processing less repeated request data before generation starts.

Claude still reads the full conversation on every turn, according to Anthropic. Message threads therefore do not lower billed token use by themselves, and the docs say neither pricing nor rate limits change. Keep the network payload, time to first token, and billed tokens as three separate measurements. A smaller upload can coexist with the same input-token bill.

Prompt caching is another control. A thread does not switch it on automatically: add cache controls when the workload qualifies, then inspect the returned cache usage. Read our prompt caching explainer for the billing mechanism and the API cost calculator to model a workload with its actual input, output and cached-token mix. The calculator is a planning tool; it does not measure a live thread. Rate-limit pressure also needs its own check, using the approach in our API rate-limits guide.

What happens after a six-minute pause

Illustrative scenario, not a test: A coding assistant creates a thread at 10:00 and successfully continues it at 10:02. The last request starts a fresh five-minute window. The user returns at 10:08, six minutes later. The client tries to continue from the latest response ID. Since the thread expires five minutes after its last request, it should be ready to send the full locally saved conversation in a new create request. The API may lose a thread earlier because storage is best-effort. Anthropic says it deletes stored thread data no more than one hour after last use; that deletion limit is not a one-hour promise that the thread remains usable.

Timing rule	Published limit	What it means
Thread expiry	5 minutes after the last request	Keep local history ready for replay.
Stored-data deletion	No more than 1 hour after last use	This is a deletion deadline, not a usable lifetime.

Source: Anthropic message threads documentation.

The recovery decision belongs to the error code. Anthropic’s error table says a 404 with thread_not_found calls for a new create carrying the full history. Do not treat every 404 as an expired thread. A 400 thread_fingerprint_mismatch means fixed request fields changed; thread_already_continued means a response ID was reused. The SDK helper can replay the conversation for certain continuation errors, but it holds its copy in memory only while that helper object exists. A production app that needs to survive process restarts must store its own history.

Should you try the beta?

If your workload looks like this	Decision
Long, active agent loop with large tool results or screenshots	Pilot threads on a small set of sessions; compare with the same workload without threads.
Mostly short or widely spaced conversations	Defer until a measurement shows enough upload or latency pain to justify expiry handling.
Requires zero data retention or a HIPAA-enabled organization	Do not use threads; Anthropic marks this feature ineligible.
Depends on Message Batches, token counting with thread, or on-demand compaction	Check the unsupported-feature rules before designing around threads.

For a paired pilot, record the same workload on both paths: request-body bytes, time to first token, input tokens, cache-creation tokens, cache-read tokens, output tokens, number of thread_not_found recoveries and full-history replays. Compare medians only after collecting actual runs; no values are available from this article. Keep model, prompt, tools and caching settings consistent between paths. If you need to estimate spend, use the measured token mix in the calculator rather than applying Anthropic’s latency percentage to the bill. Anthropic’s data-handling terms also matter: thread contents are held encrypted in memory, are not eligible for zero data retention, and are not a durable conversation store.

Sources

• Claude Platform release notes — November 2 beta announcement and availability.
• Message threads documentation — requests, expiry, recovery, limits and data handling.
• Anthropic announcement — company-reported Claude Code latency result and example workloads.

All pages read on November 4, 2026.

Free toolWill my whole document fit?Check a document