Claude API message threads cut waits on long agent runs

Anthropic has introduced message threads, a public beta feature in the Claude Messages API that lets an AI agent stop resending its entire conversation on every turn.

It is a developer feature, not a new button in the Claude app. If you build or buy agents that run for a long time, it matters because it targets one thing: how long you wait before Claude starts answering.

What problem it fixes

A coding agent can make hundreds of requests in a single session. Each request normally carries every earlier message and tool result. Once a conversation reaches hundreds of thousands of tokens, Anthropic says, resending all of it adds time before Claude begins to respond.

With a message thread, the first request sends the full conversation and starts a thread. Every later request sends only the new messages plus the ID of the previous response. Anthropic says this lowers time to first token, the delay before the first words arrive.

Anthropic’s figure: message threads are on by default for most Claude Code users, and for requests of 500,000 to 1 million tokens, median time to first token drops by about 35%. That number comes from Claude Code usage, so your results will depend on your own workload.

What it does not change

• Token usage stays the same. Anthropic says Claude still reads the full conversation on every turn.
• Pricing and rate limits stay the same. The documentation says threads do not change either. Standard Claude token rates and existing rate limits apply.
• Your app stays the source of truth. The docs tell developers to keep their own copy of every message and build a fallback that resends the full conversation, because a thread is best-effort and can disappear.

In short, this saves waiting time, not money.

How it works

Developers add a thread parameter to a Messages API request:

1. Create. The first request includes the full conversation, system prompt and tools, with the thread type set to “create.”
2. Continue. Later requests send only the new messages and the previous response’s ID. The system prompt and tools stay as they were in the first request.
3. Replay. If the API can no longer continue the thread, the request returns a 404 error and the client resends the full conversation to start a new thread.

Anthropic’s SDKs include a thread helper that does this bookkeeping, including the replay. The feature is in beta and needs the beta header message-threads-2026-08-12.

Anthropic names the workloads that gain most:

• Long-running coding agents, where each tool result or file edit adds to the conversation.
• Computer-use agents, where screenshots stay with the thread instead of being uploaded again each turn.
• Document- and image-heavy workflows, where requests get smaller.

Data handling and limits

For anyone with privacy or compliance duties, these are the details to read:

• Short-lived, in memory. Anthropic says each thread is held in memory, encrypted, and not written to disk. A thread expires five minutes after its last request, and the documentation says the API deletes it no more than one hour after its last use. The five-minute and one-hour figures describe different things: when a thread stops being continuable, and the latest point it is deleted.
• Not eligible for zero data retention. The docs list message threads as not ZDR eligible, without affecting other ZDR-eligible features you use.
• Not available with HIPAA readiness. Organizations that have HIPAA readiness enabled cannot use threads, according to the docs. The same goes for organizations with inference hooks turned on.
• Append-only, one continuation per response. Each response ID can be continued once, and you cannot edit or remove earlier turns. To compact a long conversation, you start a new thread from a summary.
• No management API. There is no way to list, read or delete a thread.
• Unsupported features. Message Batches, token counting, compaction and most context editing do not work with threads.
• Prompt caching is not automatic. Developers choose where cache breakpoints go, up to four per thread request.

Where it is available

The beta covers every model Anthropic lists in the documentation, including Claude Opus 5.5, Sonnet 5.5, Haiku 5.5, Fable 5.1 and Mythos 5.1, plus older models. It is available on the Claude API, Claude Platform on AWS, Claude in Microsoft Foundry, and Claude Models on Google Cloud (Anthropic managed).

Not the same as threads in Claude chats

The name invites confusion. Message threads is an API feature for developers. It is not the conversation history you see in the Claude app, and Anthropic’s documentation also separates it from “session threads” in Claude Managed Agents.

What it means for working professionals

• If you use Claude Code: Anthropic says message threads are on by default for most users, so you may already benefit from faster responses in long sessions.
• If you manage developers or buy agent tools: ask whether a vendor’s agent uses threads, and how it behaves when a thread expires. The feature is best-effort, so good products need a fallback.
• If you handle sensitive data: the lack of zero data retention and HIPAA support is the part to check before turning it on.
• If cost is your concern: nothing changes. This is a speed feature.

It also reflects where agents are heading. Our coverage of Claude Duet and DeepSeek’s Super-agent prototype suggests that long-running, always-on agents are a growing focus, and those are the sessions whose waits grow longest.