Anthropic Message Threads API: Drop Agent Latency 35%

Anthropic shipped Message Threads in public beta on November 2, moving multi-turn conversation state to its servers so Claude API callers send only new messages after an initial full-context request, which Anthropic measures as a 35% reduction in median time-to-first-token for requests in the 500K–1M token range. Payload on a long session drops from roughly 800 KB to about 1.8 KB, and independent developer testing on 600K-token loops landed at about 30%, though token usage, token charges and rate limits are unchanged because Claude still reads the full conversation each turn. Threads expire five minutes after the last request, after which calls return a 404 thread_not_found and the application must replay the full context, and continue calls must omit system and tools or they return a 400 error.

Every Claude API call in a multi-turn agent loop resends the entire conversation history. At turn 50 of a coding agent, you’re shipping 50,000 tokens of prior messages across the wire just to add one new user message. Anthropic shipped Message Threads in public beta https://claude.com/resources/articles/message-threads on November 2 — a feature that eliminates that redundancy and delivers a 35% drop in time-to-first-token on large contexts. Here’s exactly how it works, what it fixes, and the one caveat the press releases are glossing over. The Problem It Solves The Messages API is stateless by design. Every request is independent, which means your application has to pack the full conversation — every user turn, every assistant response, every tool result — into each call. That’s fine for a 10-turn conversation. It becomes a real problem when you’re running a coding agent through hundreds of tool calls, or a computer-use agent reviewing dozens of screenshots. By turn 50, you’re not just paying for the new tokens; you’re waiting while 800 KB of conversation history crosses the network before Claude can say anything. Message Threads moves the conversation state to Anthropic’s servers. Send the full history once to create a thread, then send only what’s new on each subsequent turn. The API handles the rest. How It Works The implementation is a small delta from the standard Messages API. On your first request, include the full context and add a thread parameter: response = client.messages.create model="claude-opus-5-5", system="You are a coding agent.", messages= {"role": "user", "content": "Review this PR diff..."} , thread={"type": "create"}, extra headers={"anthropic-beta": "message-threads-2026-08-12"} prev id = response.id Save this On every subsequent turn, send only the new message and reference the previous response ID: response = client.messages.create model="claude-opus-5-5", messages= {"role": "user", "content": "Now check the test coverage."} , thread={"type": "continue", "previous message id": prev id}, extra headers={"anthropic-beta": "message-threads-2026-08-12"} prev id = response.id Update for next turn Payload drops from ~800 KB to roughly 1.8 KB on a long session. For requests in the 500K–1M token range, Anthropic measures a 35% reduction in median time-to-first-token. Independent developer testing on 600K-token loops https://emergent.sh/news/anthropic-message-threads-beta-cuts-latency landed at ~30% — close enough to validate the claim. The Honest Caveat Read the coverage and you’ll find a lot of “35% faster” and not much else. Here’s what most posts skip: your token bill does not change. Claude still reads the full conversation on every turn. Message Threads is a network and serialization optimization — it eliminates the overhead of resending history, but it does not reduce the compute required to process it. Token usage, token charges, and rate limits are identical with or without threading. This is a latency win, not a cost win. If you’re running agents at scale hoping to cut API costs, threads won’t help you. The Gotchas You Will Hit The 5-minute expiry https://dev.to/dishant0406/claude-message-threads-are-fast-until-your-agent-waits-5-minutes-ip2 is the real constraint. Threads live in encrypted RAM and expire five minutes after the last request. After expiry, the next API call returns a 404 thread not found and your application has to replay the full context — which completely negates the latency benefit for that turn. If your agent loops involve slow external tool calls, human approval steps, or any workflow that idles for more than a few minutes, you’ll lose the thread regularly. A few other rules that will bite you on day one: - Do not send system or tools on continue calls. Even "system": null returns a 400 error. - Keep model , tool choice , and thinking configuration identical across all turns in a thread. - Wait for message stop before sending the next request on streaming calls. - Maintain your own full conversation history regardless — threads are not durable storage. Build 404 replay logic from day one, not as an afterthought. Prompt caching works with threads, but you’re capped at four cache breakpoints total including the top-level breakpoint . That’s tighter than the standard limit, so plan your caching strategy accordingly. Who Should Use It Right Now Message Threads are designed for tight machine loops https://dev.to/paullovelace/claude-api-message-threads-stop-resending-the-whole-conversation-explained-honestly-3moa — workflows where turns come fast and no human is sitting in the middle waiting. Good candidates: long-running coding agents, automated PR review bots, computer-use agents, CI pipelines that run Claude inline, document analysis pipelines processing many pages in sequence. Poor fit: anything with human-in-the-loop approval steps, HIPAA-regulated workflows not supported , Zero Data Retention environments incompatible , or batch processing via the Message Batches API also incompatible . The feature is available today across all current Claude models on the native Claude Platform, AWS Bedrock, Azure AI Foundry, and Google Cloud Vertex AI. Standard pricing and rate limits apply. Bottom Line If you’re building continuous agent loops with large contexts, Message Threads is worth adding today. The API change is minimal — a header and a thread parameter — and 30–35% faster TTFT on long sessions is a meaningful improvement for user-facing products. Just be clear-eyed about what it is: a network optimization, not a cost reduction. Keep your own conversation history, build replay logic, and don’t architect around the 5-minute window holding under load. The beta will likely extend that limit as it matures, but ship to what exists now.