Stop Resending the Whole Conversation: Anthropic's Message Threads Cut Agent Wait by About 35%

On November 2, 2026, Anthropic moved message threads into public beta on the Claude Platform. The idea takes one sentence to explain: the first request sends the full conversation as usual, and every turn after that sends only the new messages, with the API holding the rest of the history on its servers. Anthropic says that with message threads on by default for most Claude Code users, requests of 500,000 to 1 million tokens see median time to first token fall by about 35%. This is a deeply "backend" update — no new model, no new interface, no new capability, just a change in how requests travel over the wire. But for anyone running long agent sessions every day, shorter waits are a difference you feel daily.

The problem it solves

To understand message threads, start with how an agent conversation actually runs. A coding agent might make hundreds of requests in a single session, and every request resends all the earlier messages and tool results. When the conversation is short, that is barely noticeable. But once the history grows to hundreds of thousands of tokens, it starts to hurt: every turn re-uploads an ever-thicker transcript, the API re-validates and re-tokenizes all of it, and only then does the model start answering. Much of the wait is no longer the model thinking — it is hauling the history around again.

Anthropic's announcement names three workloads hit hardest: long-running coding agents, where each tool result and file edit makes the conversation longer; computer-use agents, where re-uploading screenshots every turn adds up to serious volume; and document- and image-heavy workflows, where the request bodies are large to begin with. The common thread is that the longer the context, the more wasteful the repeated hauling becomes. Message threads hand that hauling to the server, which keeps the conversation between turns.

This pain is familiar to VibeFix readers. Anyone who has done vibe coding with Claude Code has felt it: as a session runs long, each turn takes longer to start, even when you only changed one line of code. Many people assume the model got slower, when a good share of the time actually goes to resending history. Message threads aim squarely at that invisible wait.

How it works in three moves: create, continue, replay

Using it is simple, with just three moves. The first request sends the full conversation as usual, along with the system prompt and tool definitions, plus a thread parameter that creates a thread. The API stores the conversation together with Claude's reply, identified by the response ID. From the second turn on, each request sends only the new messages plus the ID of the previous response — no system prompt, no tools — and the API stitches the conversation back together before calling the model.

Calling the API directly also requires the beta header message-threads-2026-08-12 on every request in the thread. The official SDKs provide a thread helper that handles the details: it adds the header, sends the full conversation on the first turn, sends only the new messages after that, and automatically replays the full conversation once on certain errors. For most developers, the SDK helper is the right path; hand-writing request bodies makes it easy to trip over the field rules.

The third move is replay, and it is the easiest to overlook. Threads are best-effort: the API does not guarantee that every turn is stored, and no response tells you whether a given turn was stored. You only find out on the next continue — which returns a 404 error with the code thread_not_found. At that point the client must resend the full conversation to start a new thread. In other words, your own application is always the source of truth, and the server-side thread is only an acceleration layer. Anthropic's documentation is explicit: keep your own copy of every message and build the replay path from the start, rather than improvising one when a 404 appears.

The most common misunderstanding: the bill does not move

This is the most important clarification in the whole announcement, and the easiest to get wrong: message threads do not save tokens and do not save money. Claude still reads the full conversation on every turn, so token usage is unchanged, and pricing and rate limits stay the same. What shrinks is the request body — Anthropic says the median request in long conversations falls from about 800 KB to 1.8 KB — and with it, the wait before the first token.

Put plainly: you pay exactly the same, and what you save is the time spent waiting for the model to start speaking. For pay-as-you-go users, this feature will not make the bill thinner; for agents chasing responsiveness, it makes every turn in a long session start faster. Do not confuse the two. Anyone telling you threads "cut costs by 35%" is misreading the announcement — the 35% is about wait time, not money.

One related detail: a thread does not do prompt caching for you. To get cache hits on every turn, you still need to send the same top-level cache_control explicitly on each request. A request carrying a thread can hold at most 4 cache_control breakpoints, counting the top-level one — one too many returns a 400 error. Threads and caching are two parallel mechanisms that do different jobs; neither replaces the other.

Checking the numbers: where does 35% come from?

The announcement's standout number is a single one: for requests of 500,000 to 1 million tokens, median time to first token falls by about 35%. That figure comes from Anthropic's own Claude Code rollout, where the feature is already on by default for most users. Three caveats are needed.

First, the range is narrow: it covers only large requests between 500K and 1M tokens. Anthropic has published no figures for shorter conversations. If your sessions are only tens of thousands of tokens, do not expect a 35% gain — measure the actual benefit on your own traffic.

Second, Anthropic has published no sample size, date range, or methodology. This is a vendor-reported internal rollout figure, not an independent benchmark, and no outside organization has replicated it so far. Treat it as directionally credible but unverified in magnitude.

Third, the request-size drop from 800 KB to 1.8 KB is likewise Anthropic's own median for long conversations, and it describes what travels over the wire — not what the model actually processes. Claude still reads the whole conversation every turn, so however impressive that number looks, it will never show up on your bill. Judge this feature by the metric it promises — time to first token — not by the volume figure.

The limits list: read this before using it

Public beta means "usable, with boundaries." Anthropic's documentation states the limits precisely, and they decide whether threads fit your use case.

Five-minute expiry

A thread expires 5 minutes after its last request, with each stored response restarting the clock; the API deletes it no more than 1 hour after its last use. More than 5 minutes of silence and the thread is gone, so the next turn must resend the full conversation. For a continuously running agent, 5 minutes is usually enough. But for semi-automated flows where a person reviews each step, a single review can easily exceed 5 minutes, and the thread will very likely have expired. Treat 5 minutes as a hard constraint when designing the flow, not as "probably enough."

Append-only, no rewriting

A thread is append-only: each response ID can be continued once. Editing, branching, or revisiting earlier messages means starting a new thread. Compacting history or cleaning up thinking content is also mostly incompatible — on-demand compaction and most context editing do not work with threads, with the single exception of clear_thinking_20251015 with keep: "all". Threads suit tasks that move forward; they do not suit tasks that repeatedly reorganize history.

Strict field rules: get one wrong and it is a 400

Create requests and continue requests accept different fields, and mixing them up returns an error. The system prompt and tool definitions go only in the create request — sending them in a continue request, even as null, returns a 400. The model, tool choice, thinking configuration, MCP servers, context management, output configuration, container skills, top-level cache control, and the set of beta headers must stay identical on every request, or the API returns thread_fingerprint_mismatch. To change models or tool sets mid-task, start a new thread. The fields you can freely change are limited to max_tokens, stop sequences, streaming, metadata, and service tier. The SDK helper manages all of this for you; anyone hand-writing requests must check each field.

Compliance and feature exclusions

This matters most for enterprise users: message threads are not eligible for zero data retention (ZDR) or HIPAA use. Thread contents are held in server memory under server-managed encryption and never written to disk, but that still does not meet ZDR requirements. Also incompatible with threads are Message Batches, the token counting API, on-demand compaction, and organizations with inference hooks enabled. And there is a management gap: there is currently no API to list, read, or delete a thread — you cannot see what the server stored, and you cannot delete it; you can only wait for it to expire.

It is not a memory feature — and do not confuse it with the other "threads"

Anthropic has more than one thing with "thread" in the name, and confusing them is costly. First, message threads are not Claude's agent memory feature with note-taking, salience filtering, and dreaming — they do no long-term memory, no importance filtering, and no cross-session retention; they disappear after 5 minutes idle, more like a "basket for holding things between requests." Second, they are not the session threads in Claude Managed Agents, a different session mechanism that the documentation explicitly distinguishes.

The accurate framing is this: message threads are a request-level acceleration mechanism, not application-level state management. Your application still stores the conversation, does its own memory work, and handles branching and compaction. Think of it as a courier service for long conversations: the belongings are still yours, only the hauling changed hands.

Who benefits most, and who should wait

Three groups should adopt it right away. First, people using Claude Code directly: the feature is already on by default, most users need to do nothing, and long sessions should start faster — though the November 3 Claude Code changelog does not mention the switch, so do not go looking for a specific version number to verify it. Second, developers running their own agent loops: adopt the SDK thread helper and the benefit shows up in every turn's time to first token. Third, teams running computer-use or document- and image-heavy agents: screenshots and large files no longer get re-uploaded every turn, so the request-size reduction is most visible there.

Three groups can wait. First, teams with strict compliance needs: ZDR or HIPAA use cases are excluded outright, and organizations with inference hooks enabled cannot use threads. Second, slow human-in-the-loop flows: if each review step takes more than 5 minutes, threads will keep expiring and replays will eat the gains. Third, pipelines that lean heavily on batches, token counting, or on-demand compaction: those features are currently mutually exclusive with threads, so adopting threads means giving them up. For these groups, it is cheaper to wait for the general-availability compatibility list.

What to do when 5 minutes is not enough

The 5-minute expiry is the hardest constraint, and flow design has to revolve around it. The straightforward approach is to keep every turn inside 5 minutes: fast tool calls and fast model responses keep the thread alive. But as soon as the flow waits on a human review, an external system, or a long compile and test run, expiry is almost certain. The right response is not to "save the thread" but to accept that it will expire: the client always holds a full copy of the conversation, and after expiry it simply creates a new thread from that copy at the cost of one full resend. Design "expire, then rebuild" as the normal path, not as an exception, and the system becomes more robust.

One detail belongs in code: when a continue fails, read the error code before replaying. A 404 means two very different things — the thread is gone, or the model does not exist. Only the first is fixed by resending the full conversation; replaying will never fix the second. Anthropic puts the error code in error.details.error_code, and only thread_not_found should trigger the replay path. The SDK helper already handles this distinction; anyone hand-writing requests needs to code that branch explicitly, or an ordinary thread expiry may be misdiagnosed as something worse.

What it means for vibe coding

For people vibe coding with Claude Code, this is close to an invisible upgrade: no configuration changes, no version to install, and long sessions may simply start faster. The thing worth doing is paying attention next time you run a long task — sessions that used to get slower and slower may now hold steady. If you feel no difference, do not worry: your sessions may not have reached the 500K-token range where the gains are measurable.

For developers writing their own agent loops, the significance is bigger. Until now, the usual ways to speed up long sessions were to compress context yourself, truncate history, or live with growing waits. Message threads offer an official acceleration path that does not change model behavior, at the price of accepting the 5-minute expiry and append-only writes. Adoption is cheap: the SDK helper covers most of the details, and the key is to write the "keep your own copy of the conversation plus replay on 404" path into the code from day one, not as an afterthought.

There is also a longer view: Anthropic's work over the past year has a through-line — prompt caching in August 2024, context engineering guidance in September 2025, and now message threads. The theme is always the same: the cost and latency of long-context agents. Caching attacks repeated computation; threads attack repeated transmission. Together, they make long-session agents feel closer to real time. For indie developers, that means the long-session optimizations that used to be the preserve of large teams are becoming platform defaults.

One more group deserves a separate mention: indie developers building their own agent products on the Claude API. Until now, such products had to choose between "fast responses" and "full context," often forcing messy truncation and compression work on the client. Message threads move some of that dirty work into the platform. The trade is a new set of constraints — 5-minute expiry and append-only writes — but for most products shaped as "the user says one thing and the agent keeps working," the exchange is worth it. The key is to run it on real traffic for a week before rolling it out fully, watching how often 404 replays happen and how wait times actually change.

Verdict: a small change with real gains — but do not expect it to save money

Message threads are among the least glamorous and most practical of Anthropic's recent releases. No new model, no new interface — just a change in how requests are sent. But for long-session agents, time to first token is a tax paid hundreds of times a day, and if the 35% figure holds, the difference will be felt. Claude Code users already benefit by default, and developers building their own agents can adopt the SDK helper without much effort.

Its boundaries are equally clear: it saves no tokens and no money, threads expire after 5 minutes, writes are append-only, and it is incompatible with ZDR, HIPAA, batches, and on-demand compaction. Calling it a "long-session accelerator" is right; calling it a "memory system" or a "cost saver" is wrong. Anthropic has said nothing yet about when general availability arrives, what the gains are for short conversations, or whether the 5-minute limit will be relaxed.

The practical advice is simple: Claude Code users need to do nothing — just notice how long sessions feel. Developers building their own agents should wire up the SDK thread helper in a test environment, measure time to first token on their own real traffic, and only then roll it out to production. The vendor's 35% is a reference value; your own number is the one to decide on.