Anthropic Message Threads API: Drop Agent Latency 35%

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 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 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 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 — 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.