Claude Message Threads Stop Resending the Whole Chat. They Expire After Five Minutes and Are Not ZDR or HIPAA Eligible.
Anthropic's Messages API has a public beta called message threads, under the header message-threads-2026-08-12. You send the full conversation once, then continue with only the new turns and a previous_message_id. It works on the Claude API, Claude Platform on AWS, Anthropic-managed Google Cloud, and Microsoft Foundry. The limits are in the docs: threads are best-effort, expire five minutes after the last request, are deleted within an hour, and are not eligible for zero data retention or HIPAA. No pricing or rate-limit change and no automatic caching. Anthropic reports a median time-to-first-token drop of about 35% on 500,000 to 1,000,000 token requests for Claude Code users with threads on by default. We read the docs and the announcement.
By T.W. Ghost
Anthropic has a public beta on the Messages API called message threads, and it fixes the oldest inefficiency in chat APIs: sending the entire conversation back on every turn. With the beta header message-threads-2026-08-12, you create a thread with the full context once, then continue it by sending only the new turns and a previous_message_id. The thread keeps the system prompt and tools; you leave them out on the continue call. It is available on the Claude API, Claude Platform on AWS, Anthropic-managed Google Cloud, and Microsoft Foundry.
The documentation is as clear about the limits as the feature. Threads are best-effort storage. A thread expires five minutes after its last request, and each stored response restarts that clock; data is deleted no more than an hour after last use. Threads are not eligible for zero data retention and not eligible for HIPAA. There is no pricing change, no rate-limit change, and no automatic prompt caching from threads alone. You must keep your own copy of the conversation. The headline benefit is Anthropic's: with threads on by default for most Claude Code users, requests between 500,000 and 1,000,000 tokens saw median time to first token fall by about 35%. We read the platform docs and the announcement article. Here is what held up.
How It Works, and Where It Stops
| Message threads (public beta) | |
|---|---|
| Header | message-threads-2026-08-12 |
| Flow | Create with full context once; continue with new turns plus previous_message_id; thread retains system prompt and tools |
| Surfaces | Claude API; Claude Platform on AWS; Anthropic-managed Google Cloud; Microsoft Foundry |
| Durability | Best-effort; expires 5 minutes after the last request; deleted within 1 hour |
| Compliance | Not ZDR eligible; not HIPAA eligible |
| Billing | No pricing or rate-limit change; no automatic caching |
| Limits | Batches, token counting, compaction unsupported or limited; at most 4 cache breakpoints; fallback-model turns not stored |
| Your obligation | Retain your own conversation copy |
| Reported gain | About 35% median TTFT drop on 500k to 1M token requests, Claude Code cohort (Anthropic) |
Five minutes is short for agents. An agent that pauses to run a build, wait for a human, or poll a queue will blow through the window between turns and fall back to a full resend. Threads help the tight loops, not the long ones.
The compliance flags are explicit. If your workload runs under zero data retention or HIPAA, this beta is not for it, by Anthropic's own labels. That is a server-side store of your conversation, however briefly, and the docs treat it as one.
The 35% is a cohort number. Anthropic measured it on Claude Code users with threads on by default, on requests above half a million tokens. It is not a service-level promise and will not describe a 20,000-token chat.
A payload-shrink figure circulated with the launch, hundreds of kilobytes down to under two. It is not on the docs or the article, and it stays out.
Verified vs Unconfirmed: The Scorecard
| Claim | Verdict |
|---|---|
Public beta; header; create then continue via previous_message_id; surfaces | Verified (platform docs) |
| Best-effort; 5-minute expiry; deletion within 1 hour | Verified (docs) |
| Not ZDR eligible; not HIPAA eligible | Verified (docs) |
| No pricing or rate-limit change; no automatic caching; keep your own copy | Verified (docs and article) |
| Unsupported features and the 4-breakpoint cap | Verified (docs) |
| About 35% median TTFT drop on 500k to 1M token requests | Anthropic-reported (announcement article; Claude Code cohort) |
| Kilobyte payload-shrink figure | Unverified (not on a primary page) |
Who Should Use It
Turn threads on for tight, high-context loops where turns arrive within minutes of each other and nothing in the conversation is under a ZDR or HIPAA obligation.
Skip it for regulated data, for agents that idle longer than five minutes between calls, and for anything you treat as durable memory; the store is best-effort and so is the gain.
The frontier is elsewhere: the feature saves time to first token, not money, and the plan it is most visible on just changed its name. Our model comparison has the current standings side by side.
Sources
*Not sure whether your agent loop is tight enough to benefit from a five-minute thread? Take the free 2-minute quiz and get matched. Then read about the other latency lever Anthropic is retiring: Claude Code's Opus 4.8 fast mode.*