Stop resending the whole conversation: Claude Message Threads enters public beta, cutting median first-token latency by about 35% for long sessions

Every developer who works with long sessions knows the feeling: the longer the conversation runs, the slower the model seems to start answering. The model has not become dumber. The problem is that every turn resends the entire conversation. On 2 November 2026, Anthropic moved Message Threads into public beta on the Claude Platform to attack exactly that problem. Its promise is deliberately modest, and that modesty is why it deserves a careful read: it does not promise lower bills or a smarter model, only a faster start for long conversations. For anyone who runs Claude Code for hundreds of turns a day, how fast the first token arrives is productivity in itself.

This article separates the official claims from the boundaries and the things left unsaid. The announcement is short, but it hides one crucial distinction: what it saves is transmission and validation time, not compute on the bill. Get that distinction wrong and every later judgement about the feature will drift.

Why long conversations used to get slower

Before threads, a Messages API call was stateless. Each request sent the system prompt, the available tools, every earlier message and every tool result in full, and the server validated and tokenized all of it before generation began. At the start of a session that overhead is barely noticeable. Once a conversation reaches hundreds of thousands of tokens, it is not: the request body keeps growing, and the work before the first word keeps growing with it.

Anthropic describes the scenario concretely: a coding agent may make hundreds of requests in one session, resending every earlier message and tool result each time. Once the conversation reaches hundreds of thousands of tokens, resending becomes a major source of delay before the model starts responding. Note the wording. The claim is about waiting before generation, not about generation speed itself. Generation is unchanged; what changes is the road leading up to it.

That is why long-session slowness is so easy to misdiagnose. The first instinct is to switch to a faster model or shorten the output, but if the bottleneck is the request body itself, a faster model only helps in part, and a shorter output does nothing for the wait before the first word. Threads fix that stretch: later requests become smaller, so the server reaches generation sooner.

How a thread actually works

In Anthropic's own description, the mechanism is not complicated. The first request sends the full conversation as usual and includes the thread parameter, which creates a thread. On each later turn, the client sends only the new messages and the ID of the previous response, and the server reconstructs the rest before calling the model. The conversation history stops being luggage carried on every trip and becomes something temporarily held on the server, retrieved by reference.

For developers calling the API directly, the entry points are the thread parameter on Messages API requests and the accompanying beta header, message-threads-2026-08-12. The official SDKs provide a helper that handles those details, so developers do not have to track headers and IDs by hand. That does not make threads a black box: they have an explicit lifetime. Anthropic says a thread is held in memory between turns, encrypted, and never written to disk. If five minutes pass after the last request with no new request, the thread expires, and the client must resend the full conversation to start a new one.

One more point belongs up front: threads are best-effort. The documentation uses that word deliberately, meaning the server will try to keep a thread but does not guarantee that every continuation will succeed. Your application must still keep its own complete copy of the conversation and be ready to replay it in full when continuation fails. Treating a thread as your only archive of the conversation is the easiest mistake to make in this beta. A thread saves repeated transmission; it does not store your history for you.

On availability, the announcement lists four surfaces: the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry, and Claude models on Google Cloud managed by Anthropic. Standard token rates and existing rate limits still apply. Note what is missing: no general availability date and no separate price for threads. Right now this is a public beta, not a production service commitment.

It saves time, not money

This is the most important sentence in the announcement, and Anthropic states it plainly: although each request becomes smaller, Claude still reads the full conversation on every turn, so token usage stays the same. In other words, threads cut time to first token, not the bill. The headline figure is that, with 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%.

That figure should be read literally. Median is not average, and certainly not a guarantee; 500,000 to 1 million tokens is a specific range, not every conversation size. Short conversations have little resending overhead to remove, so the gain will be far smaller, perhaps imperceptible. Long conversations gain the most, but only if the session is genuinely active and dense with turns. If your agent pauses for a long time between turns, the thread may expire before the next turn arrives, and part of the gain will be eaten by replaying the full conversation.

Comparing threads with prompt caching clarifies their place. Caching addresses repeated content being charged less; threads address repeated content being transmitted less. One affects cost, the other affects waiting. They can work together, but neither replaces the other. Anyone expecting threads to cut the bill will be disappointed; anyone expecting long sessions to feel snappier is the intended user.

For vibe developers, the distinction has a practical edge. Many solo projects are not limited by token budgets but by waiting: while an agent fixes a bug across several files, every turn waits for the model to work through hundreds of thousands of tokens of context before it says anything. Threads do not change what the model can do, but they shorten that wait, and the debugging loop feels noticeably better. Feel is not a vanity metric here; in work that needs continuous judgement, feel is efficiency.

Who benefits first, and who can wait

Anthropic names three scenarios that fit best. The first is long-running coding agents, where each tool result and file edit lengthens the conversation. The second is computer-use agents, where screenshots stay with the thread instead of being re-uploaded every turn. The third is document- and image-heavy workflows, where request bodies grow just as fast. All three share one trait: context is not one-off background material but a working site that keeps growing during the session.

Claude Code users are the first direct beneficiaries. The announcement says threads are already on by default for most Claude Code users, with no configuration change needed. The boundary matters too: most is not all, and default-on is not coverage for every user and every client version. The announcement gives no minimum client version and says nothing further about what else is needed beyond the server-side switch. If your long sessions have not become faster, do not rush to doubt the announcement; you may simply not be in the default-on group yet, or your sessions may not be in the size range where the gain shows.

For teams building their own agents, the test can be more direct. First, look at session length: if most conversations end well below 100,000 tokens, the gain may be only a few hundred milliseconds and not worth restructuring a request layer. Second, look at turn density: if turns are often more than five minutes apart, threads will expire frequently and the gain will be discounted. Third, look at latency sensitivity: for background batch jobs, a few extra seconds before the first token hardly matter, so there is no urgency. But if your agent runs hundreds of turns per session, context regularly passes several hundred thousand tokens, and a user is waiting on screen for the next step, threads are worth trying promptly.

One more group should wait: teams with special data-retention requirements. The documentation says threads are not eligible for zero-data-retention configurations or HIPAA organizations, and that for streaming responses the client must wait for the message_stop event before continuing from the previous response ID, or it may receive a 404. These are not footnotes; they decide whether threads can enter your production path at all. Until the compliance boundary is clear, do not make threads the default.

Do not treat a thread as storage, or as a cache

Two misunderstandings in the design deserve to be called out separately. The first is expiry. Five minutes sounds short, but it is counted from the last request, not from the start of the session. As long as the session stays active, the thread keeps renewing; once you step away for a meeting, lunch, or another task, it will very likely be gone when you return. Threads fit active sessions, not workflows interrupted for a long time. Long tasks that need to resume after a break still need your own persistent storage.

The second is deletion. Threads live in encrypted memory, are never written to disk, and are deleted no more than one hour after their last use. That is good for privacy and awkward for debugging: there is no API to list, read, or delete threads, so you cannot later inspect the copy the server held, nor clean it up yourself. If continuation fails, the only reliable artefact you hold is the complete record your own client kept. The better threads work, the more important it is not to lose that record, because recovery depends entirely on it.

From an engineering standpoint, the right posture is to treat threads as an acceleration layer, not a storage layer. The request layer should do two things: use the thread in the normal case, sending only new content; and fall back to a full replay transparently when continuation fails. Log thread failures separately, or you will not be able to tell whether an improvement came from threads or from network variation. That observability matters most during a public beta, when server behaviour may still change.

Five questions to answer before you integrate

First, how long are your sessions really? Do not answer from feeling; check the logs. If most sessions end below 100,000 tokens, the first-token gain may be imperceptible to users. If they regularly pass 500,000 tokens, threads deserve a place in the plan. Optimisation without data easily becomes change for the sake of a new feature.

Second, how far apart are your turns? The five-minute expiry runs from the last request, not from the session total. Continuous debugging and continuous editing fit it well; workflows that wait for human approval, external systems, or a meeting in between will see threads expire before you return. The right calculation is not how much time one turn saves, but how often replay eats the saving.

Third, what happens on failure? Continuation failure is not an edge case; it is a path built into the design. Your code must replay the full conversation automatically, without losing tool results, scrambling message order, or showing the user a duplicated answer. If your request layer lacks that fallback today, the first step of adopting threads is to build the fallback, not to add the parameter.

Fourth, which requests must not use threads? Work through the documented limits one by one: zero-data-retention setups, HIPAA organizations, message batches, on-demand compaction, and similar cases are out of scope. Streaming needs special care too: continue only after the stop event. Each of these looks like a detail now; in production, each can become an incident.

Fifth, how will you prove it got faster? Record a baseline before launch: median and percentile time to first token for sessions of the same size. After launch, compare by session-size segment, not by overall average. During a public beta the server side may still change, and without segmented data you cannot tell whether a slowdown is a thread problem, a network problem, or model load. Answer these five questions and threads will be genuinely integrated into your system, not merely into your code.

Verdict: a small infrastructure step, a large step for long sessions

On its own, Message Threads is not a headline launch. There is no new model, no new price, and no new interface, only an API parameter and some server logic. But long sessions are precisely where agents stop being demos and start being daily work. A demo can run ten turns; daily work easily runs hundreds. A demo can keep context small; daily work only grows it. A feature that only improves the wait before the first word looks invisible in a demo and is felt every day in real work.

Its restraint is also a signal. Anthropic has not dressed threads up as a cost saving, has not stretched the 35% figure beyond its range, and has not hidden the best-effort nature or the five-minute expiry. That honesty lets developers form a fair expectation: long sessions will start answering sooner, but bills will not shrink, history will not be stored for you, and not every continuation is guaranteed. Held to that expectation, threads are a solid improvement; held to a higher one, they are bound to disappoint.

For solo developers and small teams, the advice is simple. First, feel the default experience in Claude Code on a long session; that step costs nothing. Then decide whether to add the thread parameter to your own agent: long enough sessions, dense enough turns, sensitive enough latency, and it is worth it; otherwise, leave it until it graduates from beta. Infrastructure improvements are not harmed by arriving one step late. They are harmed by being written into a critical path before their boundaries are understood, and then failing on expiry and continuation at a cost larger than the latency they saved.

One question is worth watching next: whether server-held conversation becomes the default shape of the next generation of agent protocols. Today each vendor solves resending in its own way, with threads, caching, and compression behind different interfaces. If holding conversations on the server proves stable, the next steps could be longer retention, clearer continuation semantics, or even context management across sessions. Before that, the 2 November version solves exactly one problem: letting an ongoing long conversation stop retelling its whole history on every turn. That problem is small enough to overlook, yet for people who live inside long sessions, it is friction met every day, and removing it changes how the work feels.