Claude Message Threads Cut Agent Latency by 35%

A coding agent can make hundreds of requests in one session. Every time, the app sends Claude the whole conversation again: each message, each tool result, each file edit. Once that history passes a few hundred thousand tokens, the upload and checking work adds a pause before Claude even starts to answer. Anthropic's fix is Claude message threads.

On Monday, Nov. 2, the company put that fix into beta on the Messages API, and Anthropic's announcement says median time to first token (TTFT) drops by about 35% for requests of 500,000 to 1 million tokens. That number comes from Claude Code, where threads are already on by default for most users.

Before you get excited about the bill: nothing about cost changes. More on that below, along with a catch that matters for any agent that sometimes waits on a human.

How Claude message threads change the request loop

Without threads, each turn re-sends everything. With them, you send the full conversation once, along with your system prompt and tools, and add a thread parameter set to create. After that, each request carries only the new messages and the ID of the previous response, according to Anthropic's developer docs. The API rebuilds the conversation on its side before calling the model.

Anthropic says thread contents are held in memory, encrypted, and never written to durable storage. The docs also spell out what you can't change mid-thread: system and tools go on the create request only, and sending either on a continue request returns a 400 error. The model, tool choice and thinking settings have to stay identical on every request too, or you get a thread_fingerprint_mismatch error.

Enabling it takes the beta header message-threads-2026-08-12. The release notes list it for the Claude API, Claude Platform on AWS, Claude in Microsoft Foundry and Claude Models on Google Cloud (Anthropic managed). The docs list 17 supported models, from Claude Opus 5.5 down to older Sonnet and Opus 4.x releases.

What the 35% latency cut does and doesn't mean

Anthropic gives the gain as a median, and only for long requests. It doesn't publish absolute wait times in the announcement, so we can't tell you whether 35% is two seconds or twenty. Short sessions have little history to re-upload, so there's little to save.

The mechanical explanation is a size drop. AlphaSignal reported that median request size in long Claude Code sessions fell from roughly 800 KB to 1.8 KB. That's about 444 times smaller, or a cut of around 99.8% in bytes sent. AlphaSignal's page doesn't tie that figure to a specific Anthropic post, so treat it as reported, not confirmed.

The bill stays put

It's tempting to read "35% faster" as "35% cheaper." It isn't. Anthropic is blunt about it: "Claude still reads the full conversation on every turn, so token usage stays the same." Standard token rates and existing rate limits apply, and The Next Web put it the same way.

One thing worth knowing if you're comparing it with prompt caching: a thread doesn't cache anything for you. The docs say caching works as it does without a thread, so you still choose where the breakpoints go, with a limit of four per request. If you want cheaper cached reads, you ask for them separately. Anthropic did lower cache-read prices on Claude Sonnet 5.5 from $0.20 to $0.10 per million tokens on Oct. 7, per its release notes, which is a separate move from this one.

The five-minute catch

A thread expires five minutes after its last request, and the API deletes it no more than an hour after its last use. Each stored response restarts the five-minute clock, so this is an idle timer, not a session cap. A busy agent will never hit it.

An agent that waits on a person will. Picture a coding agent that stops for a human to approve a patch and comes back after a coffee. The next continue request gets a 404 with the code thread_not_found, and the app has to send the whole conversation again in a fresh create request. The docs say no response tells you whether a turn was stored. You only find out on the next continue.

That's why Anthropic tells developers to treat their own copy of the conversation as the source of truth and build the replay path from day one. The SDK helper does the replay for you, and it keeps the conversation only in memory while the helper object lives. If your agent has to outlive its process, you save the history yourself.

Two more edge cases from the docs are worth a note on your checklist. If a response ends in a refusal, don't continue that thread; start a new one without the turn that triggered it. When streaming, wait for the message_stop event before continuing, because an earlier continue can return a 404.

Who can't use it

Threads aren't eligible for zero data retention. The docs say the contents are deleted within an hour but not written to durable storage, and that using the feature doesn't affect your other ZDR-eligible features. The Next Web adds that Anthropic also says threads aren't eligible for its HIPAA health-data setups; the docs page we read only mentions ZDR, so we're attributing that one to TNW. If you're in a regulated field, check with Anthropic before you plan around it.

Our take: a latency fix, not a cost fix

This is a latency fix, and a well aimed one. The painful part of long agent loops isn't the model thinking; it's hauling a huge, mostly unchanged history across the wire and validating it again each turn. Threads cut that, and the 444-fold drop in request size reported for Claude Code suggests the savings are real where sessions are long.

It also leaves two things untouched. Claude still processes the full context every turn, so the compute bill is the same. And the five-minute timer means threads are a speed boost, not durable memory. If your workflow routinely pauses longer than that, you'll fall back to the slow path often, and you'll want to measure how often before counting on a 35% gain.

Bottom line: test threads on your longest sessions, log how often a thread expires, and keep your own copy of the conversation. The speedup is real, but it only lasts while the thread stays warm.

We'd also be careful about reading too much into the default-on rollout in Claude Code. It's a sign Anthropic trusts the feature, but it's still labeled beta, and the numbers so far come from Anthropic's own tool. Independent measurements on third-party agents would tell us more. This sits alongside other moves to make long-running agents practical, like the always-on designs we covered in DeepSeek's Super-agent proposal, where cost and latency are the main limits.

What to do this week

If you build on Claude, add the thread parameter in a staging environment, run your longest session, and compare TTFT with and without it. Build the 404 fallback before you ship. Watch the release notes for a longer lifetime, since the five-minute window is the main thing standing between this beta and a default for every kind of agent.

Source: Anthropic

claude anthropic claude api ai agents claude code

AI

About the author

AI Briefing Daily Editorial. The editorial desk of AI Briefing Daily, an independent publication covering artificial intelligence. Every story is researched against primary sources, checked by hand and reviewed by a person before publication.