Anthropic Message Threads: Send Only the New Messages and Cut Time to First Token by 35%

Anthropic has put Message Threads into public beta on the Claude Platform, and the pitch is simple: stop re-uploading the whole conversation on every agent turn. In its announcement (dated November 2, 2026), Anthropic says requests with 500k to 1M tokens see a median time to first token (TTFT) drop of about 35%, with message threads on by default for most Claude Code users. The feature is documented in the Claude Platform docs, and The Decoder was among the first to report it.

This post explains how the thread parameter works, what the 35% figure does and does not tell you, and the constraints that decide whether you should adopt it now.

TL;DR: what readers ask first

Why long agent loops get slow

A coding agent can make hundreds of requests in one session. Each request carries every earlier message and every tool result. Once a conversation reaches hundreds of thousands of tokens, the upload alone adds time before Claude starts to answer.

Anthropic's docs describe the second cost: without a thread, the API also validates and tokenizes the whole conversation again on every turn. With a thread, most of that work covers only the new turn. So the saving is on the request path, before the model starts generating.

This sits next to earlier latency work. In October, Anthropic explained that Claude Code now compresses each turn's payload, which we covered in what gzip is and why Claude Code responds sooner. Gzip makes the same upload smaller. Message Threads removes most of the upload instead.

Latency stopwatch showing the wait before the first token in a Claude Message Threads request

How Message Threads work

The flow has three parts, all described in the docs.

1. Create. Send your first request as you do today, with the full conversation, system and tools, and add "thread": {"type": "create"}. The API stores the conversation, including Claude's reply, under the response id.
2. Continue. Send only the messages since the previous response, plus "thread": {"type": "continue", "previous_message_id": "<previous id>"}. Leave system and tools out; the thread keeps the values from the create request.
3. Replay. A thread is best effort. If it can no longer be continued, the API returns a 404 and you send the full conversation again as a new create request.

Here is the Python shape from the docs, using the SDK helper:

client = anthropic.Anthropic()

thread = client.beta.messages.thread(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a support agent for Acme. Keep replies short.",
)

thread.send({"role": "user", "content": "Hi! I have a question about an order."})
second = thread.send(
    {"role": "user", "content": "How long does standard shipping usually take?"}
)

The helper creates the thread on turn one, continues it on turn two, adds the beta header and keeps the full conversation in memory. If you build requests yourself with cURL or the standard create method, add the thread field and the message-threads-2026-08-12 header to every request.

What the 35% claim actually says

Be precise about the number. Anthropic's wording is that, with message threads on by default for most Claude Code users, requests with 500k to 1M tokens see a median TTFT drop of about 35%. Three things follow.

• It is a median, not a worst case, and it covers one length band.
• It comes from Claude Code traffic, a heavy agent workload. A chat app with short conversations will see little.
• It is Anthropic's own measurement. We found no independent benchmark yet, so treat it as a vendor claim until people publish their own runs.

The logic is sound, though: the longer the conversation, the more redundant upload and re-processing a thread avoids. Anthropic says the benefit grows with context size. The docs name the best fits: long coding-agent loops, computer-use agents (screenshots stay with the thread instead of being uploaded each turn), and document or image-heavy workflows.

What it does not change

Anthropic is direct on this: "Claude still reads the full conversation on every turn, so token usage stays the same." Standard token rates and rate limits apply. If your problem is the bill, use prompt caching. Our prompt caching guide covers the mechanics, and Claude Code token efficiency and prompt-cache sessions shows how cache hits shape session cost. The cache-read price change is analysed in Sonnet 5.5 cache read at 0.10.

Threads do not cache for you. Per the docs, "A thread does not cache your prompt for you": you still choose where breakpoints go. A top-level cache_control on every request of the thread asks for caching of each turn. Threads allow at most 4 cache_control breakpoints per request, and the top-level one counts as one. A fifth returns a 400 error with the code thread_unsupported_request.

So the two features stack. Caching cuts what you pay to re-read context. Threads cut what you upload and re-validate. For the cost side of Opus-class sessions, see Opus 5.5 task cost in Claude Code.

The rules that will bite you

The docs list a lot of fine print. These are the ones most likely to cause errors in a first integration.

Your application stays the source of truth. The docs tell you to keep your own copy of every message and build the replay path from the start, because no response tells you whether the API stored that turn. You only find out on the next continue request.

Other causes of a thread_not_found 404 include a different organization, workspace or service account, a response that ended in a tool call cut off by max_tokens, and a previous turn written by a fallback model. Server-side fallback works with threads, but the API does not store a turn a fallback model wrote, so the next turn must be a full create request.

Features that do not work with threads

• Message Batches
• Token counting (count the full conversation instead)
• Compaction on demand, and context editing except clear_thinking_20251015 with keep: "all"
• Organizations with HIPAA readiness or Inference hooks enabled

Because a thread is append-only, you cannot summarize earlier turns inside it. To compact, start a new thread from a summary. That matters for agents that rely on automatic compaction, such as the long-running setups in Claude Managed Agents dynamic workflows.

Data handling and privacy

Threads are not free of trade-offs on data. Anthropic says each thread is held in memory, encrypted and not written to disk, and deleted no more than 1 hour after its last use. A thread holds the conversation sent to the model, the system prompt and tools from the create request, and a fingerprint of the fixed fields. Files are held by reference, so they must stay available while the thread lives.

The docs mark the feature not ZDR eligible and not HIPAA eligible. Using it does not affect your other ZDR-eligible features, but a regulated team should check its contract before turning threads on. There is also no API to list, read or delete a thread.

Who should adopt it now

Adopt it if you run long, tool-heavy agent loops where requests regularly pass 100k tokens, you control the client, and you can write a replay path. The SDK helper already does the replay for you on thread_not_found, thread_already_continued and thread_continue_in_flight, and the SDK's beta tool runner uses a thread by default.

Wait if your conversations are short, you depend on batches or token counting, you need ZDR or HIPAA, or you use compaction heavily. Keep gains realistic: Anthropic's number is for 500k to 1M token requests, and your own distribution may sit far below that.

A practical test plan:

1. Log TTFT per turn for a real session without threads, at several context sizes.
2. Turn on the SDK helper with the same model and cache_control.
3. Compare median and p90 TTFT by context bucket, and count 404 replays.
4. Check that your cost per task did not change, as Anthropic says it should not.

For related choices on the platform side, see Claude Platform cost and performance with prompt caching and effort.

Where this fits

The pattern is not new in the industry. Stateful conversation handles let a provider keep context server-side so the client stops resending it. Anthropic's version is deliberately short-lived and best effort, with the client keeping the real state. That design avoids a hard dependency on server memory, at the price of the replay code you must write. The caution that follows is the usual one for betas: the header carries a date, the feature can change, and the unsupported list is open-ended. The docs say the API can add values to it, and that you should send the full conversation without thread if you see one you do not recognize.

FAQ recap

Message Threads cut upload and re-validation work, not tokens or price. Median TTFT fell about 35% in Anthropic's Claude Code measurements for 500k to 1M token requests. Test it on your own agent before you rely on that figure.

Related reading

• What is gzip: why Claude Code responds sooner
• Prompt caching and LLM cost optimization
• Claude Code token efficiency and prompt-cache sessions
• Sonnet 5.5 cache read price cut
• Opus 5.5 task cost in Claude Code
• Claude Platform cost and performance
• Claude Managed Agents dynamic workflows

Details reflect Anthropic's announcement and documentation as of November 3, 2026. The feature is in beta and may change.