Anthropic Message Threads: 35% Faster, Same Bill

Anthropic shipped message threads in public beta on November 2, 2026. The feature lets your agent upload a long conversation once, then send only what changed. If you have been resending a 500,000-token history on every turn, this removes a real bottleneck — but not the one most people assume.

Your bill does not change. Message threads cut latency, not spend. Anthropic says so directly in the docs, and the reasoning matters before you refactor anything.

What actually changed

Under the old model, every request carried the entire conversation — messages, tool calls, tool results — even though the API had already received every one of them. A coding agent on a complex task might make hundreds of calls. Once history reaches 500,000 tokens, each later request re-uploads all of it. The API then validates and tokenizes that input again before the model can start generating, and that repeated preparation is what piles up as latency.

With a thread, the first request still sends everything: conversation, system prompt, tool definitions. Add thread: {"type": "create"} and the API stores it server-side under the response id. Later turns send only new messages plus thread: {"type": "continue", "previous_message_id": "..."}, and the API rebuilds the conversation before it calls the model.

That word matters: rebuilds, not summarizes. Claude still reads the full conversation every turn. If the history holds 500,000 tokens, the model receives 500,000 tokens, even though your client transmitted four messages. From Anthropic's own docs: "While each request is smaller with message threads, Claude still reads the full conversation on every turn, so token usage stays the same."

The savings are in bytes on the wire and in pre-generation processing time. Token charges and rate limits are untouched.

The measured gain

Anthropic reports that threads reduced median time to first token by about 35% for Claude Code requests containing 500,000 to 1,000,000 tokens. The feature is default-on for "most" Claude Code users, and because it lives in the Messages API it extends to anyone building agents.

The payload reduction depends on what your agent stuffs into each turn. Guillaume Lebedel, CTO of agent infrastructure company StackOne, published a simulation that makes the win concrete. Say a computer-use agent captures a 150 KB screenshot per step. Without threads, the 50th request carries roughly 7.5 MB of accumulated shots. With threads, about 0.15 MB — just the latest. Across the 50-step session, cumulative upload drops from roughly 191 MB to 7.5 MB, about 25x.

That is a simulation, not a live benchmark. But the direction is sound: the heavier the per-turn payload, the more a thread buys you. Lebedel bets computer-use agents adopt it before coding agents do, precisely because a screenshot per step is what makes the resend expensive, and that most will have it on by the end of December.

Implementing it

Threads work with a single thread field. Because it is beta, you must send the anthropic-beta header with value message-threads-2026-08-12 on every request in the thread — in the Python SDK, betas=["message-threads-2026-08-12"].

Turn one sends the full conversation with thread: {"type": "create"}. Turn two sends only the new messages with thread: {"type": "continue", "previous_message_id": first.id}. Leave system and tools out of continue requests — the thread retains them from the create request, and sending either one, even as null, returns a 400.

An SDK thread helper also handles the beta header and keeps the conversation in memory. In Python, client.beta.messages.thread(...) creates the helper (no request is sent), and thread.send() submits one turn at a time.

Fields split into three groups, and getting this wrong is the most common way to hit a wall:

• Create-only: system, tools. Send them once; never on a continue.
• Fixed: model, tool_choice, thinking, mcp_servers (except each server's authorization token), context_management, output_config, the skills in container, the top-level cache_control, and the set of anthropic-beta values. Same values on every request, or you get a 400 with code thread_fingerprint_mismatch naming the differing fields.
• Free: max_tokens, stop_sequences, stream, metadata, service_tier, and anything else not listed. These can change turn to turn.

Two more gaps. The API does not store MCP server URLs, MCP authorization tokens, or the container id — send those on every request that uses them. And on Claude Fable 5.1, Mythos 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5, changing system or tools invalidates thinking blocks already in the conversation, which can return a 400.

Five minutes and it's gone

The loudest complaint on X after launch was the expiry window. One developer: "Five minutes at the coffee machine and the thread expires." Another: "Only 5 minutes for cache expires is almost useless."

The practical damage is smaller than it sounds. Your application remains the source of truth: keep your own copy of every message and build the replay path from the start. The SDK helper holds the full conversation in memory and replays it in a new create request when a continue fails, so the first request after a break is slower but nothing is lost. And every successful request stored in a thread restarts the five-minute clock, so a continuously operating agent can hold one thread across a long task.

If you manage threads by hand, you own expiry: continuing an unavailable thread returns a 404 and you must resend the full conversation. One subtlety catches people out — no response, create or continue, tells you whether the API actually stored that turn. You only find out on the next continue, which is why the docs insist you build the replay path first rather than after an incident.

Data handling: the limitation that disqualifies some teams

Thread contents are encrypted under a server-managed key, held in server memory, never written to durable storage, and deleted no more than one hour after last use. A reasonable posture — but not zero retention.

Concretely, message threads are not ZDR eligible and not HIPAA eligible. If your organization has HIPAA readiness enabled, or you operate under a contract forbidding any server-side retention of conversation content, the feature is unavailable. Likewise unsupported: on-demand compaction, combining thread with the token counting API, context editing (except clear_thinking with keep: "all"), and organizations with Inference hooks on. Most are rejected with a 400 and code thread_unsupported_request, with an error.details.unsupported value naming the rule.

Using threads does not affect your use of other ZDR-eligible features; the restriction is scoped to this one.

Threads are not a substitute for caching

This is the part that most often gets conflated, and the distinction decides your architecture:

• Threads reduce what you send. That's latency.
• Prompt caching reduces the price of what repeats. That's cost.

Threads do not cache anything for you. For cache reads, send a top-level cache_control on every request; the API applies it to the last cacheable block of that request's messages, so each turn reads prior conversation from cache and writes the new turn to it. That breakpoint counts as one of the four permitted per request — a platform-wide prompt-caching rule, not threads-specific — so plan the budget up front.

On Opus 5.5, per Anthropic's pricing page checked November 4, 2026: $4 per million input tokens for fresh input, $0.20 per million for cache reads. If the goal is a lower bill, caching is the lever; if it is a snappier agent, threads are. Long sessions usually want both.

Who should turn this on

Threads pay off when conversations are long and API calls are frequent: long-running coding agents accumulating file edits and tool results, computer-use agents capturing a screenshot every step, applications handling large volumes of documents or images. They do almost nothing for one- or two-turn chat, or retrieval pipelines where context turns over completely on each call.

Availability: the Claude API, Claude Platform on AWS, Anthropic-managed Claude Models on Google Cloud, and Claude in Microsoft Foundry, across all models, in beta.

The bottom line

Message threads are an infrastructure fix, not a capability upgrade. The model is no smarter, the context window is no larger, the price is identical. What changed is that you no longer re-upload the same half-million tokens each turn — and that alone cut latency by roughly a third where it hurts most.

Decide accordingly: caching for the invoice, threads for the stopwatch. And check the two hard constraints — five-minute expiry, no ZDR or HIPAA — against your real workload before you enable it, not after.