• Anthropic's own page reports that requests of 500,000 to one million tokens see median time to first token drop by about 35 percent.
• The figure comes from Claude Code production usage; Anthropic's page gives no controlled benchmark method, model mix or percentile beyond the median.
• Token usage and rate limits are unchanged, because Claude still reads the full conversation each turn.
• Threads are best-effort: they expire 5 minutes after the last request, and a continue call can return a 404, forcing a full resend.
• Threads are held in memory and are not eligible for zero data retention, a gating question for regulated workloads.

Anthropic's Message Threads is a real, documented public beta, and its headline claim is narrower than the headline suggests: median time to first token falls about 35 percent on requests of 500,000 to one million tokens, a figure Anthropic ties to Claude Code production usage rather than a controlled test. The mechanism is sound, but the number is a field observation at extreme context sizes, so treat it as a ceiling to test against.

What the feature does

Message Threads changes what the client uploads, not what the model reads. Per Anthropic's documentation, the first request sends the full conversation and starts a thread, and later requests send only new messages plus the ID of the previous response. Without a thread, every turn uploads the whole conversation and the API validates and tokenizes it again; with one, most of that work covers only the new turn. The beta header is message-threads-2026-08-12.

What the 35 percent number is

The figure is a median, drawn from production traffic. Anthropic's page says that with threads on by default for most Claude Code users, requests with 500,000 to one million tokens see median TTFT drop by about 35 percent. The page describes no controlled benchmark, no tail percentile, and no breakdown by model, so it cannot be read as a guarantee for other workloads. Notably, the Decoder article is a faithful restatement of that page.

What it does not change

Cost and token accounting stay put. Anthropic states that standard Claude token rates and existing rate limits apply, and that token usage stays the same because Claude still reads the full conversation each turn. The saving is latency on the upload and validation path, not spend. Prompt caching remains a separate, optional setting: Anthropic's examples pass a top-level cache_control on each turn, which takes effect once the conversation passes the minimum cacheable length.

The failure mode: threads are best-effort

A thread is not durable state, and agent code must treat it that way. Anthropic's documentation says it expires 5 minutes after its last request, each stored response restarts that clock, and the API deletes it no more than 1 hour after last use. If the API can no longer continue a thread, the continue request returns a 404, and the client must send the full conversation again in a new create request. An agent that idles past five minutes pays the full resend.

Data handling is the gating question

Threads hold the conversation, system prompt and tools in memory, encrypted under a server-managed key and never written to durable storage. Anthropic's documentation nonetheless marks the feature as not eligible for zero data retention, while saying that using it does not affect other ZDR-eligible features. Teams with retention commitments should read that note before enabling threads on sensitive sessions, even though contents are deleted within an hour of last use.

Verdict: Signal, for long agent loops only

Signal. The mechanism is documented, the failure mode is specified, and the gain targets a real cost of resending hundreds of thousands of tokens each turn. But the 35 percent is a median from one product's traffic at 500,000 tokens and above. If your sessions are shorter, idle for more than five minutes, or sit under ZDR terms, expect less. Replay a representative session with and without a thread and compare p50 and p95 TTFT before committing.