The resend was the slow part
A long agent session has a dull problem. Every turn, the client uploads the entire conversation again: every earlier message, every tool result, every screenshot. Anthropic's documentation puts it plainly — without a thread, the API "validates and tokenizes all of it again" before the model sees a single new token. At a few thousand tokens that cost is invisible. At half a million, it is the wait.
Message threads remove the resend, not the reading. The first request sends the full conversation, system prompt and tools, and starts a thread. Later requests send only what is new, plus the ID of the previous response, and the API rebuilds the conversation on its side before calling the model. Anthropic says the feature is already on by default for most Claude Code users, and that requests between 500,000 and 1 million tokens see median time to first token fall by about 35%.
Read that number with its boundaries attached. It is a median, reported by Anthropic, for a specific size band, and it measures the wait before the first token — not how long a whole task takes, and not what the task costs. A 20,000-token chat has little resend to remove, so there is little to gain.
The bill does not move
This is where early coverage is most likely to mislead. Claude still reads the full conversation on every turn, so input tokens are unchanged. The documentation is explicit that threads do not change pricing or rate limits. What shrinks is the request payload and the repeated validation and tokenization work before inference. The model still processes the full conversation on every turn. Anyone budgeting an agent deployment on the assumption that threads cut token spend by a third will be disappointed by an invoice that never got the memo.
Threads are also not prompt caching under a new name. The documentation states that a thread does not cache your prompt for you: caching still works as it did before, with breakpoints the developer places, and a threaded request can carry at most four of them. The two features can be combined, but they solve different problems: threads reduce repeated request uploads and validation, while prompt caching can reduce the cost of processing previously supplied context. Neither feature replaces the other.
Five minutes of state, and it is yours to lose
The state Anthropic holds is deliberately short-lived. A thread sits in memory, encrypted and never written to durable storage. It expires five minutes after its last request, although each stored response restarts the clock, and it is deleted no more than an hour after last use. Leave an agent idle for more than five minutes and its thread expires. Anthropic says deletion follows no more than one hour after the last use.
Anthropic does not hide the consequence: the feature is best-effort, and your application stays the source of truth. Keep your own copy of every message, the documentation says, and build the replay path from the start. When a continuation cannot be honored, the API returns a 404 thread_not_found without specifying why. The application must be able to recreate the thread by resending its full conversation. Anthropic's SDK helper automatically replays once for the documented continuation errors, but that recovery still depends on the application retaining its own complete copy.
A thread is also fixed once it starts: append-only, each response continuable exactly once, and fields such as the model, thinking settings and tool choice fingerprinted from the create request. Change one mid-thread and the API returns a fingerprint-mismatch error. To change the setup, you start a new thread and pay the full upload again.
The constraint is broader than model and thinking settings. Anthropic also requires fields such as tool choice, MCP server configuration, context management, output configuration and beta headers to remain consistent across the thread. Some fields must be repeated on every request even though the conversation itself is stored server-side. A change to a fixed field requires a new thread and a fresh create request.
Who is locked out
The unsupported list is the part regulated teams should read first. Threads do not work with Message Batches, token counting, compaction on demand, or most context editing. Organizations with HIPAA readiness enabled or Inference hooks turned on cannot use message threads. Threads are also not eligible for zero data retention, although Anthropic says enabling them does not affect the ZDR eligibility of other features. There is no API to list, read or delete a thread. Teams must manage the conversation through their own application state, allowing the server-side thread to expire rather than relying on an API deletion control.
None of this makes the feature weak. For an actively looping coding agent, a computer-use agent carrying screenshots, or a document-heavy workflow, a reported 35% reduction in median time to first token on 500,000-to-1-million-token requests is a meaningful improvement. It is not evidence that every turn, or the entire task, becomes 35% faster. It simply is not the improvement the headline version suggests: it makes a long conversation start faster, not cheaper or more durable, and it adds a recovery path on top of the bookkeeping the developer already had.
Sources
- [1] Anthropic, "Make long-running agents faster with message threads", claude.com, published November 2, 2026 (primary source; the public-beta launch, the create/continue mechanism, the about-35% median TTFT figure for 500k–1M-token requests, the on-by-default Claude Code statement, the 5-minute expiry, unchanged token usage, availability and standard rates, read first-hand in full)Read source
- [2] Anthropic, "Message threads", Claude Platform Docs, platform.claude.com (primary source; the beta header on every request, the create/continue/replay lifecycle, best-effort and append-only rules, the fixed-field fingerprint and 404 thread_not_found behavior, SDK helper replay, the prompt-caching distinction and 4-breakpoint limit, the unsupported-features list, no list/read/delete API, pricing and rate limits unchanged, in-memory encrypted storage, deletion within 1 hour, and the not-ZDR-eligible statement, read first-hand in full)Read source