Claude Message Threads Beta Cuts Request Size, Not Your Bill
Message Threads is in public beta on the Claude Messages API. Anthropic reports 35% lower time to first token — token charges stay unchanged.

Anthropic opened Message Threads to public beta on the Claude Messages API on 2 November 2026. The company says median request size in long conversations fell from about 800 KB to 1.8 KB.
The feature targets one specific tax on agent builders: resending the entire conversation — every earlier message, every tool result — just to ask the next question. It does not touch your token bill.
How it works
The first call, the "create" request, sends the full conversation including the system prompt and tools, along with the thread parameter. The API stores that conversation and Claude's reply under the response ID. Every later "continue" request sends only the messages since the previous response, plus that response's ID, and the API reconstructs the rest before calling the model.
In practice you add the thread parameter and the message-threads-2026-08-12 beta header. Official SDKs ship a thread helper that handles the header, keeps the conversation in memory, and replays the full conversation once for certain continuation errors. The feature is already on by default for most Claude Code users.
What Anthropic claims — and what it doesn't
Two vendor figures, both from Anthropic's own Claude Code rollout rather than independent testing: on requests of 500,000 to 1 million tokens, median time to first token is about 35% lower; in long conversations, median request size dropped from about 800 KB to 1.8 KB.
What Anthropic does not claim is the part most teams get wrong. Claude still reads the full conversation on every turn. Token usage, token charges and rate limits are unchanged — what you save is upload time and request size, the waiting and not the bill. Prompt caching also still has to be requested explicitly; threads do not switch it on for you.
The limits that decide whether it fits
- Five-minute expiry. A thread expires five minutes after its last request. Each response restarts the clock; an idle session is gone, and you resend the full conversation to start a new one.
- Best-effort, not storage. State is held in memory under server-managed encryption, never written to durable storage, and deleted no more than one hour after last use. There is no API to list, read or delete threads.
- Keep your own history. A continue request sent before the previous response's
message_stopstreaming event can return a 404, so your app must still be able to replay the whole conversation. - Compliance exclusions. Not eligible for zero data retention, not for HIPAA organisations, and not usable with Message Batches, on-demand compaction or most context editing. No token counting through threads.
Beta support covers every model, on the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry and Claude Models on Google Cloud (Anthropic-managed). Standard token rates apply; there is no pricing change for using it.
If your problem is the bill, look at your tool list
Threads are a latency fix. Cache hygiene is where the money is, and the MCP ecosystem is leaking it. HISTOR, a public log of MCP tool definitions, recorded 10,712 changes to the tool lists of 4,491 MCP servers in the week of 25 October to 1 November — and 331 of those changed nothing but a date or a timestamp.
That matters because of prefix ordering: with Anthropic's API the cached prefix is built tools first, then system prompt, then messages, so a change anywhere in the tools invalidates everything after it. By HISTOR's accounting, reading a cached prefix costs a tenth of the normal input price while writing one costs 1.25 times input (twice for the one-hour cache) — roughly 12 times more on a miss than on a hit. A single server was responsible for 237 of the 331 date-only changes.
What to do next
If you run long agent sessions and your bottleneck is time to first token on huge contexts, threads are worth an afternoon of testing — with your full-history replay path kept intact. If your bottleneck is spend, audit which MCP servers rewrite their definitions daily; HISTOR found 218 servers that changed definitions seven or more times in a week, and pinning those per session is the cheaper fix.
More from DangMua