Anthropic put message threads into public beta on the Claude Platform on November 2, 2026. The whole change is one field named thread added to a Messages API request: the first call carries the full conversation with its system prompt and tools, every later call carries only what is new. Anthropic says the median time to first token drops by about 35% on requests between 500,000 and one million tokens, with threads on by default for most Claude Code users.
What was actually released
A server-side conversation store, not a model change. On the create request the API keeps the conversation, including Claude’s reply, under the response id. A continue request sends only the new messages plus previous_message_id, and leaves system and tools out because the thread already holds them. The API rebuilds the conversation before it calls the model.
The gain sits before generation starts. Without a thread, every turn uploads the whole history and the API validates and tokenizes all of it again. With a thread, most of that work covers only the new turn.
| Item, as documented by Anthropic | Value |
|---|---|
| Median time to first token, 500,000 to 1 million token requests | about 35% lower |
| Thread expiry after its last request | 5 minutes |
| Deletion after its last use | no more than 1 hour |
cache_control breakpoints per request, top-level included |
4 |
| Token usage | unchanged |
| Price and rate limits | unchanged |
| Status and beta header | beta, message-threads-2026-08-12 |
Two properties of the store matter as much as the latency. A thread is held in memory, encrypted under a server-managed key, never written to durable storage, and deleted no more than 1 hour after its last use, expiring 5 minutes after its last request. And there is no API to list, read or delete a thread: the application keeps its own copy and replays it when the store cannot continue.
What the beta actually gives you
- A smaller request per turn, and a shorter wait before the first token, on long conversations.
- The same token count and the same price per token as an unthreaded request.
- A thread that is append-only, can be continued once per response
id, and disappears after 5 minutes of silence.
What the claim rests on
The 35% is a median over a named band, 500,000 to one million tokens, on traffic where threads were already on by default for most Claude Code users. That is a real measurement and a narrow one. Anthropic publishes no sample size, no distribution beyond the median, no figure per model, and nothing at all for the requests below 500,000 tokens where most chat and most small agents live.
With message threads on by default for most Claude Code users, requests with 500k to 1M tokens see median TTFT drop by about 35%.
The default clause matters when the number is repeated: the population measured is Claude Code traffic during a rollout, heavy, long-running and tool-driven. A customer shipping a 5,000-token support bot is not in that population and should not expect the same shift.
The number also measures one segment of the wait, the time before the first token arrives. A 35% cut in time to first token is not a 35% cut in task time. On an agent loop the model still generates every token, and the tool calls still take what they take.
What is not published
No latency table by model, no p95 or p99, no measurement at 100,000 or 200,000 tokens, no comparison against prompt caching alone, and no independent replication. The only percentile given is the median, which hides the tail an agent actually feels when one turn stalls.
Token usage is the other half, and the documentation is explicit in the opposite direction: Claude still reads the full conversation on every turn, so token usage stays the same and the bill does not move. Prices and rate limits are unchanged. The gain is time, not money.
On this page
What it changes for teams building agents
Cost and latency are now two separate settings that both have to be configured. Message threads shrink the request; prompt caching discounts the prefix that is read again. The documentation is direct about the boundary: a thread does not cache your prompt, and the top-level cache_control counts against the limit of 4 breakpoints.
The second is engineering work that lands on the customer. A thread is best-effort: a continue request that cannot find the store returns a 404, and no response says whether the API stored that turn, so the application has to hold the conversation and treat a replay as the normal case. Every fixed field, from the model to the tools, must also match the create request or the API answers with thread_fingerprint_mismatch.
The third is the 5-minute window. An agent waiting on a human approval, a webhook or a slow build loses the thread and sends the full conversation again. Threads fit hot loops, not sessions that pause.
The fourth is the list of features the beta cannot combine with.
| Not available with a thread | What it means in practice |
|---|---|
| Message Batches | a batch item carrying thread fails with an invalid request |
| Token counting requests | the count must run on the full conversation instead |
| Compaction and context editing | you cannot summarize inside the thread, except clearing thinking |
| Organizations with HIPAA readiness enabled | the request is rejected |
| Organizations with inference hooks turned on | the request is rejected |
Availability covers the Claude API, Claude Platform on AWS, Claude Models on Google Cloud under Anthropic management, and Microsoft Foundry, on every model.
The Neural Minute take
The percentage in this announcement is a latency figure and it will be read as a discount. It is not one. Nothing in the release lowers a per-token price, and the documentation says in plain words that Claude still reads the whole conversation, so the monthly invoice moves only if your turns move.
Read against our own coverage of Anthropic folding subagents into one agent loop, a pattern comes out: the company is attacking the cost of repeated context from the transport side, not the model side. Fewer redundant agent calls in one release, less redundant upload per call in the next. For anyone running long agents that is where the seconds were.
Two reservations. The first is that the measurement does not describe most deployments. Below 500,000 tokens the release says nothing, and many paid agents never reach that band, so log your own time to first token at your own prompt sizes before planning around 35%. The second is retention: a feature that holds your conversation in memory under a server-managed key and is neither zero data retention eligible nor HIPAA eligible is a feature to check against your contract before it goes near regulated work.
The exclusion list is the quiet part. Teams that reached for compaction or context editing to survive long sessions now choose between the tool that keeps the conversation under control and the path that makes it fast. That tradeoff, not the 35%, decides adoption.
Sources
- Anthropic, “Make long-running agents faster with message threads”, published November 2, 2026, read on November 4, 2026: the announcement
- Anthropic, message threads reference in the Claude Platform documentation, read on November 4, 2026: the documentation
- Every figure quoted here, the 35% median, the token band, the 5 minutes, the 1 hour, the 4 breakpoints and the unchanged token usage, comes from those two pages and is the company’s own number, not an independent measurement
- Our earlier reporting on the same problem at the agent level: Anthropic folds subagents into one agent loop, 2x faster