Anthropic's Message Threads Cut Claude Code Latency by 35% — But Not Your Bill

Anthropic's message threads feature reduces median time-to-first-token by 35% for large requests, according to the company's own measurements — and an independent analysis of roughly 980 turns of real-world Claude Code logs projects savings of 2 to 4 minutes per four-hour coding session. The feature, which is enabled by default for most Claude Code users and available to API users via the "thread" parameter, speeds up responses but leaves token consumption, cost, and rate limits completely unchanged.

That is the core trade-off identified by ZDNET contributor David Gewirtz, who analyzed his own Claude Code logs to test Anthropic's claims. His verdict: a genuine but modest performance win, delivered at no additional cost, with no effect on how much you pay or how smart the model behaves.

What did the log analysis actually measure?

Gewirtz examined timing data from approximately 980 turns in his own Claude Code logs, recorded before the message threads feature became available. The numbers establish a concrete baseline: Claude typically began a response about 3 seconds after each mid-task request when running contexts of 500,000 tokens and up. During five busy evenings in the past month, his conversations generated roughly 100 to 225 model calls within a four-hour stretch.

Applying Anthropic's reported 35% median time-to-first-token reduction to that baseline, Gewirtz projected the 2-to-4-minute savings per four-hour work session. Time-to-first-token (the delay before a model starts producing output after receiving a request) is the metric Anthropic uses to describe responsiveness, and it is the one dimension where message threads deliver measurable gains.

The stakes matter most at scale. About half of Gewirtz's sessions hit a context ceiling of 500,000 to 1 million tokens multiple times per night, and he notes that any reduction in latency becomes significant in larger enterprise deployments or applications that involve many back-and-forth turns with large data payloads.

How do message threads work?

The mechanism addresses an inefficiency that has always existed in model messaging. Agents frequently send a stream of requests to a model during a single conversation. Before message threads, every individual message transmitted the entire conversation history along with each new request.

Gewirtz offers a precise analogy: "Imagine if you're in a very long texting chat with a friend. Now imagine if every time you sent a text to that friend, you also had to send every other text and every other reply along with that original text. That's how model messaging has always worked. Except now, with message threads, there's a better way."

With the feature turned on, agents send only what has changed since the previous turn. This reduces the volume of data transmission and increases responsiveness. The benefit is strongest in sessions running contexts of 500,000 to 1 million tokens — precisely the long-running, heavy workloads that define serious agentic coding.

Computer-using agents see a specific advantage. Screenshots from those agents "stay with the thread instead of being re-uploaded on every turn," according to the Anthropic blog post on the feature. For image-heavy workloads, that distinction compounds across hundreds of turns.

Faster, but is it cheaper?

No. Gewirtz is explicit on this point: even though threads reduce latency in the Messages API, token usage and therefore cost will not go down. The reason is architectural — the model itself still processes the full conversation during every turn, even though the transmission layer no longer re-uploads it. Rate limits also remain unchanged.

Prompt caching (a capability that has existed for roughly two years and allows the model to avoid re-processing identical prompts, for example in looping analysis calls) still saves money, and the two features can work together to reduce workload. But message threads themselves offer, in Gewirtz's phrasing, only "an extra smidge of performance, at no extra cost."

That framing carries the practical takeaway: there is no financial downside to enabling threads, and there is no financial upside either. The 35% figure is Anthropic's measurement of latency reduction, not a cost savings — a distinction Gewirtz flags directly.

Does it make Claude smarter?

It does not. Context (the size of the full session Claude is working with, roughly equivalent to human working or short-term memory) is unaffected. Most Claude Code sessions max out at a 1-million-token context; by comparison, Gewirtz notes that a locally hosted AI on his 128GB Mac Studio handles a context no larger than 64K tokens — about 6% of the Claude Code context size.

The feature also does not eliminate context management or compaction. Compaction is the process by which the AI reduces and discards information to fit a session's turns into the available context. Gewirtz compares it to saving a JPEG at very low quality: "You lose a lot of the visual fidelity, but you still get the main idea."

Larger contexts allow longer sessions before compaction must begin, but they carry a known failure mode. The larger the context, the greater the chance the model loses track of its task or makes reasoning errors — a limitation threads do nothing to address.

Where the feature does not help

Two boundary conditions limit the benefit. Individual one-off requests see no improvement from message threads. And any conversation that pauses longer than 5 minutes between turns will send the full message contents rather than only the new material, forfeiting the optimization entirely.

The feature's value therefore concentrates in exactly one scenario: continuous, high-frequency agent sessions with large payloads. For interactive one-off queries or intermittent usage, the status quo applies.

Why a 35% latency cut matters

Gewirtz's overall assessment positions message threads as "a good thing, a solid if small innovation that increases responsiveness." The feature does not reduce costs, but it also carries no additional charge for the additional performance — which he counts as a win in itself.

The market context is straightforward. Claude Code operates in direct competition with tools like OpenAI's Codex, and Gewirtz's own prior survey found that 75% of developers he polled prefer Claude Code. In agentic coding, where a single session can involve hundreds of model calls and contexts approaching a million tokens, latency accumulates. A 35% median reduction in time-to-first-token, compounded across 100 to 225 calls in a four-hour stretch, is where the 2-to-4-minute figure comes from.

For enterprises running very long-lived coding agents, document-heavy workloads, or computer-using agents that transmit constant screenshots, the reduction grows more valuable. Gewirtz concludes that while the time savings may not seem huge in an individual session, any latency reduction registers in deployments where faster AI responses are a requirement — and in every application of Claude technology with substantial back-and-forth traffic and large data payloads. The feature is on by default for most Claude Code users, so most developers are already receiving the benefit without changing a setting.