Claude code message threads win on latency for very long agent sessions, but they do not replace prompt caching, because they save time rather than tokens. Anthropic reports that median time to first token falls by about 35% on requests of 500k to 1M tokens, measured on Claude Code users. Token usage, token rates and rate limits stay the same, so use threads for speed on long sessions and keep prompt caching for cost.
Last verified: 4 November 2026
Message threads are an API-level change to how the Messages API handles long conversations. The first request carries the full conversation and starts a thread. Every later request carries only the new messages and a reference to the previous response, and the platform holds the rest in memory, encrypted and not written to disk, according to Anthropic's announcement.
It is not a new model. It is plumbing that matters when a coding agent has accumulated hundreds of tool results and file edits. Anthropic says threads are on by default for most Claude Code users, so many people get the benefit without touching any configuration. Developers building their own agents on the API need to opt in.
Each option addresses a different cost: waiting time, tokens, or money. The table separates them.
| Approach | What it saves | What it does not save |
|---|---|---|
| Message threads | Time to first token on long requests; upload size per turn | Tokens, money, rate-limit headroom |
| Full-history resend (the old default) | Nothing; simplest to implement | Time, bandwidth |
| Prompt caching | Money on repeated prefixes; some processing time | Upload size, since you still send the history |
| Threads plus prompt caching | Time and money together | Anything on short sessions |
The two features are complementary rather than competing. If you are choosing between Claude pricing tiers for heavy agent use, our Claude Code price comparison covers the cost side, and threads do not change those numbers.
Every turn in a coding session adds to the history, and without threads the client sends all of it again. The arithmetic below is our own illustration, not an Anthropic figure.
Assume a 900k-token history at roughly 4 bytes per token. That is about 3.6 MB per request. On a 5 Mbps upload link, 3.6 MB takes about 6 seconds to send, on every turn, across hundreds of turns. With a thread, the per-turn payload shrinks to the new messages only.
Upload time is only one part of time to first token, and Anthropic has not published how the 35% divides between transfer and server-side work. Treat the numbers above as a way to see why resending hurts, not as a prediction of your own savings.
You need three things, all described in the official message threads documentation. Check that page for the exact request shape, because the beta may change.
message-threads-2026-08-12 on every request, including continuations.thread parameter, which creates the thread. The API stores the conversation, including Claude's reply, under the response id. system and tools out of continuation requests, since the thread keeps the values from the create request.
Two details affect your design. There is no API to list, read or delete threads. And threads are best-effort: a thread expires 5 minutes after its last request, and the API deletes it no later than 1 hour after last use.
A continuation against an expired or missing thread returns a 404. Your client must then resend the full conversation to start a fresh thread. This replay path is by design, so build it from the start rather than treating it as an error case.
A practical pattern is to keep the complete message list in your own application state, always. Use the thread as an optimisation on top of it. If you an agent for a coffee break longer than 5 minutes, expect the next turn to pay the full-resend cost once.
It does not save tokens or money. Claude reads the full conversation on every turn, and standard token rates and existing rate limits apply, per Anthropic. If your bill is the problem, threads will not help.
Other limits worth knowing:
Adopt them if you run long-lived coding agents, computer-use agents that accumulate screenshots, or document-heavy and image-heavy workflows. These are the cases Anthropic names as best suited. If you are still choosing tooling, see our guides to the best AI agent for coding in 2026 and agentic AI coding tools.
Skip them, for now, if your sessions are short, your data needs zero retention, or you have not yet built a replay path. Model choice still drives output quality more than transport does, as covered in our best LLM for coding comparison. If you are weighing providers on API economics, Gemini versus Claude API pricing is the relevant read.
The sensible expectation is that other providers will ship comparable features. Until they do, this is a latency improvement specific to Claude.
Third-party outlets confirm the launch with independent framing. The Next Web covered it as an agent-efficiency story, noting Anthropic has already switched threads on for most Claude Code users and that prices and rate limits are unchanged. AI Chat Daily's write-up adds the 35% median TTFT figure was drawn from Claude Code users, who already have the feature enabled by default. Magica's analysis is the necessary caution: the 35% is a company-reported result for a specific band of unusually large requests, with no absolute waiting times, sample size or detailed testing method published. No outlet has yet published independent latency benchmarks.
Q: Do Claude Code message threads reduce my token bill?
A: No. Claude still reads the full conversation on every turn, so token usage is unchanged, and standard token rates and rate limits apply. Threads reduce waiting time, not cost.
Q: How much faster are message threads?
A: Anthropic reports a median time-to-first-token drop of about 35% for requests of 500k to 1M tokens, measured on Claude Code users. It has not published absolute times or sample size, so your result will vary.
Q: Do I need to enable message threads in Claude Code?
A: Anthropic says threads are on by default for most Claude Code users. If you build your own agent on the Messages API, add the thread parameter and the message-threads-2026-08-12 beta header.
Q: How long does a message thread last?
A: A thread expires 5 minutes after its last request, and the API deletes it no later than 1 hour after last use. A continuation against an expired thread returns a 404, and your client then replays the full conversation.
Q: Can I use message threads with prompt caching?
A: Yes, and they address different problems. Threads cut transfer and wait time on long sessions, while prompt caching reduces the cost of repeated prefixes.
Q: Are message threads suitable for regulated data?
A: Not currently. Threads are reported as not eligible for zero data retention or HIPAA, so confirm against Anthropic's documentation before using them with sensitive data.
No corrections to date.
This article was produced with AI assistance and reviewed against Anthropic's published documentation. Facts are checked against primary sources where available.