Claude Code message threads are now on by default for most users, and an analysis of real coding logs suggests the feature offers a small but real responsiveness gain. The catch: it does not lower token costs. The findings come from roughly 980 turns recorded before the feature arrived, combined with Anthropic’s published benchmark for the Messages API update.
What message threads actually change
Anthropic introduced message threads as part of its Messages API. The feature alters how conversations are sent to the model. Previously, every API request carried the entire conversation history. With threads enabled, the model receives only what has changed since the previous turn. Anthropic compares the old behavior to resending every text in a long chat each time you send a new message.
That reduction in repeated data transmission speeds up the start of a response, a metric called time-to-first-token. Anthropic reports a 35% median reduction for requests with contexts between 500,000 and 1 million tokens. Message threads are on by default for most Claude Code users; API users can activate them with a thread parameter.
What the logs showed
The log analysis covered about 980 turns from before message threads became available. In contexts of 500,000 tokens or more, Claude typically began responding roughly 3 seconds after each mid-task request. During five busy evenings, sessions generated about 100 to 225 model calls across four-hour stretches.
Applying Anthropic’s 35% figure as a projection, the estimated saving came to 2 to 4 minutes per four-hour session. About half of the logged sessions reached the 500,000-token context level multiple times in a night.
Where the gains are larger
The benefit grows with long-running coding agents and workloads that carry documents or many images. Anthropic notes that for computer-using agents, screenshots remain attached to the thread instead of being uploaded again on every turn. Any application with heavy back-and-forth and large payloads stands to notice reduced latency, even if the per-session gain looks modest.
No change to cost or rate limits
Faster responses do not translate into cheaper ones. The model still processes the full conversation on every turn, so token consumption and rate limits remain the same. Message threads can be combined with prompt caching, a separate feature that has existed for about two years and does reduce cost by avoiding repeated prompt processing.
The new capability also does not expand context or improve reasoning. A session can still hit the one-million-token ceiling, and larger contexts increase the chance the model loses track or makes reasoning errors. Compaction, the process of shrinking session data to fit available context, is unaffected. Individual one-off requests see no improvement. Conversations with more than five minutes between turns revert to sending the full message contents rather than just the new material.
The bottom line
Message threads are a focused optimization: responses start sooner in large-context sessions, at no additional charge, while costs and limits stay put. For developers running demanding, hours-long Claude Code sessions, that is a small but useful improvement rather than a transformation.
