# Anthropic Message Threads Beta: Stop Resending Conversations > Source: > Published: 2026-11-03 12:06:42+00:00 Anthropic shipped a public beta yesterday that changes how the Messages API handles long agent sessions. Instead of resending the entire conversation on every turn, agents can now send only what is new. For sessions running 500,000 to 1,000,000 tokens, that translates to a 35% drop in time to first token. The feature is called Message Threads, the beta header is `message-threads-2026-08-12`, and the catch is straightforward: you still pay for every token. Threads just stop you from uploading the same context on every turn. ## How Message Threads Work The mechanics are simple. Turn one sends everything: system prompt, tools, and full conversation history. The API stores this in encrypted memory server-side and returns a response ID. Turn two sends only the new messages, plus that response ID. Anthropic reconstructs the full conversation before invoking Claude. There is no compute shortcut — Claude reads every token on every turn. The saving is entirely on the network and pre-processing side. Enabling it requires adding the beta header and a `thread` parameter on the first request: ``` thread = client.beta.messages.thread( model="claude-opus-5-5", max_tokens=1024, system="You are a coding assistant.", betas=["message-threads-2026-08-12"], ) # Turn 1 — sends full conversation, creates thread r1 = thread.send({"role": "user", "content": "Review this function..."}) # Turn 2 — sends only the new message r2 = thread.send({"role": "user", "content": "Now add error handling."}) ``` Subsequent turns reference the previous response ID automatically through the SDK helper. The [beta headers reference](https://platform.claude.com/docs/en/api/beta-headers) has the raw HTTP syntax for those not using the SDK. ## What the 35% Number Actually Means Anthropic is specific here, and you should be too when evaluating this for your use case. The 35% improvement applies to median time to first token on requests between 500,000 and 1,000,000 tokens. That is the latency from submitting a request to receiving the first byte of a response — not total task completion time. If your agent sessions run under 100,000 tokens, the improvement is near zero. If they regularly hit the 500k–1M range — a common reality for coding agents accumulating tool results, file contents, and prior responses — the benefit is real. Billing does not change. Token usage is calculated identically. Rate limits are unchanged. Most Claude Code users already have threads enabled by default. ## The Gotchas That Will Burn You The [developer community has flagged the sharp edges](https://dev.to/gabrielanhaia/claudes-api-now-holds-your-agents-conversation-for-5-minutes-keep-your-own-copy-3a1e) worth knowing before you ship this to production. **The 5-minute expiry is silent.** A thread expires five minutes after its last request. The API returns a 404 — no warning, no explanation of why. You must implement fallback logic that detects this and resends the full conversation to start a new thread. Skip this and your agent will crash in production when a slow tool call or human approval step exceeds the window. **You have no retrieval API.** You cannot list, read, or delete threads. Your application is the only source of truth for the conversation. If the thread expires and you have not persisted your own copy of the messages, that context is gone. The SDK helper holds the conversation in memory only while the object lives — meaning serverless workers and queue processors need explicit persistence logic. **Strict field rules on continuation requests.** The system prompt and tools belong only in the first request. Sending them again on a continuation — even as `null` — returns an error. Model, tool_choice, and thinking must remain constant throughout a thread; changing any of them requires starting a new thread. Fields you can vary freely per turn: max_tokens, stop_sequences, stream, and metadata. **No automatic prompt caching.** Threads do not cache your prompts. You still need to configure `cache_control` breakpoints manually, with a maximum of four per request including the top-level parameter. ## What Threads Do Not Fix Message Threads are not available for HIPAA-regulated organizations, zero data retention customers, or organizations with Inference hooks enabled. They do not support Message Batches, token counting endpoints, or compaction. Each response ID can continue exactly once — there is no branching. If you are building an agent that forks into parallel paths, threads are not the right tool for session management. ## Worth Adopting? Yes, for any agent that regularly runs long sessions. The [Python SDK v2.2.0](https://github.com/anthropics/anthropic-sdk-python/releases/tag/v2.2.0) adds thread support, the API changes are minimal, and the latency win at scale is genuine. The [official documentation](https://claude.com/resources/articles/message-threads) covers the full request structure and field reference. The mental model shift matters more than the code change: stop treating the server as stateless between turns. Threads give Anthropic’s infrastructure room to optimize preprocessing. Your responsibility is to keep your own copy of the conversation and handle the 404 gracefully. Do both, and this is a straightforward upgrade for any long-running agent workflow.