--- title: Claude no longer needs you to resend the whole conversation: message threads are here url: https://hernandez.systems/en/articles/claude-no-longer-needs-you-to-resend-the-whole-conversation-message-threads-are-here lang: en type: NewsArticle section: AI published: "2026-11-03T15:33:43+00:00" modified: "2026-11-04T15:01:02+00:00" publisher: Osky Networks image: https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-03/e62-portada-e056de7a.png alternate_es: https://hernandez.systems/es/articulos/claude-ya-no-necesita-que-le-reenvies-toda-la-conversacion-llegan-los --- # Claude no longer needs you to resend the whole conversation: message threads are here > On November 2, 2026, Anthropic launched message threads for the Messages API in public beta. With them, a long conversation no longer has to be resent in full on every turn: the server stores it for a while and your code sends only the new messages. The promise is a lower time to first token (TTFT) in long sessions. According to Anthropic, in Claude Code it drops by about 35% on requests of 500,000 to one million tokens. If you have an agent that goes through hundreds of tool-use rounds, or a bot that drags a long history along, this affects you. Heads up: it won't lower your bill. On November 2, 2026, Anthropic launched *message threads* for the Messages API in public beta. With them, a long conversation no longer has to be resent in full on every turn: the server stores it for a while and your code sends only the new messages. The promise is a lower time to first token (TTFT) in long sessions. According to Anthropic, in Claude Code it drops by about 35% on requests of 500,000 to one million tokens. If you have an agent that goes through hundreds of tool-use rounds, or a bot that drags a long history along, this affects you. Heads up: it won't lower your bill. ## The problem it tackles The Messages API is *stateless*: the server remembers nothing between requests. Every agent turn sends the *system prompt*, the tool definitions and the whole history all over again, including tool results and screenshots. The documentation explains it like this: without a thread, every turn re-uploads the entire conversation, and the API validates and tokenizes it again. With 20,000 tokens of history you barely notice. With 500,000 you do. Anthropic gives the example of a coding agent that makes hundreds of requests in a single session: each one carries everything that came before, and that resending adds time before Claude starts answering. ## How it works The mechanism is simple and fits in one new parameter, `thread`, plus the beta header `message-threads-2026-08-12`, which goes on every request in the thread: - **Create.** The first request goes out as usual, with the full conversation, `system` and `tools`, and you add `"thread": {"type": "create"}`. The API stores the conversation, including Claude's reply, under that reply's `id`. - **Continue.** On later turns you send only the new messages and `"thread": {"type": "continue", "previous_message_id": ""}`. `system` and `tools` are not sent again: if you send them, even as `null`, the API responds with a 400 error. - **Start over.** The thread is *best-effort*. It expires 5 minutes after the last request and is deleted at most an hour after its last use. If it can no longer be continued, the API responds with a 404 and the code `thread_not_found`, and you have to resend the whole conversation in a new `create`. ![Diagram comparing what is sent on each turn without a thread, where the request grows with the entire history, and with a thread, where only the new message travels](https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-03/e62-diagrama-e07f37af.png) The SDKs ship a *helper* (`client.beta.messages.thread(...)` in Python) that builds these requests, adds the header and automatically retries from scratch when the thread is lost. The SDK's beta *tool runner* also uses a thread by default. One important detail: the helper keeps the conversation only in memory, for as long as the object exists. If your process restarts, the copy goes with it. ## What doesn't change: the cost Here's the fine print that matters most. Anthropic says that even though each request is smaller, Claude still reads the entire conversation on every turn, so token consumption is the same. The documentation confirms it: threads don't change pricing or usage limits. They don't cache anything for you, either. *Prompt caching* works the same as without a thread: you decide where the cache breakpoints go. To cache every turn you have to send a top-level `cache_control` on each request in the thread, and there's a cap of 4 cache breakpoints per request. If you want to save money, caching is still the way. The thread saves time. ## The rules that can bite you The documentation splits the fields into three groups, and it's worth having them straight before migrating: | Group | Fields | Rule | |---|---|---| | Only on `create` | `system`, `tools` | Sending them on a `continue` gives a 400 error | | Fixed | `model`, `tool_choice`, `thinking`, `mcp_servers`, `output_config`, top-level `cache_control`, beta headers, among others | Must carry the same value throughout the thread; if they change, `thread_fingerprint_mismatch` error | | Free | `max_tokens`, `stop_sequences`, `stream`, `metadata`, `service_tier` | Can change between turns | Other rules from the same documentation: - **The thread only grows.** Each `id` can be continued only once, and you can't edit or branch from an old message. To fix something, compact with a summary or switch tools, you have to open a new thread. - **The API doesn't check for duplicates.** If you resend a message that was already there, it may show up twice in the conversation or return an error. - **Streaming:** the `id` arrives in `message_start`, but you can only continue after `message_stop`. - **Refusals and fallback models:** after a `stop_reason: "refusal"` the thread can't be continued, and a turn written by a *fallback* model is not stored. - **Same owner:** the thread can only be continued by the same organization, the same workspace and the same key or service account that created it. - **Not supported:** Message Batches, token counting, on-demand compaction, most *context editing*, organizations with HIPAA, or those with *inference hooks* enabled. - **There is no API to list, read or delete threads.** ## Privacy Anthropic says it keeps the thread in memory, encrypted with a key managed by the server, never writes it to disk, and deletes it at most an hour after its last use. Even so, the feature is not eligible for *Zero Data Retention* or HIPAA. If your organization has ZDR by contract, check this before turning it on. ## Where it's available According to the release notes, the beta works on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (managed by Anthropic) and Claude in Microsoft Foundry, with all models. Anthropic already has it enabled by default for most Claude Code users. ## What this means My take: it's a transport optimization, not an intelligence one. The model doesn't remember more or reason better; your request simply weighs less and arrives sooner. Anthropic says it's most noticeable in coding agents, *computer use* agents (screenshots stay in the thread instead of being uploaded on every turn) and workflows with lots of documents or images. For a WhatsApp bot with short, spaced-out conversations, the gain is small: if the customer takes more than 5 minutes to reply, the thread has already expired and you send everything again. Where the experience does change is in agents that chain tools nonstop and pile up hundreds of thousands of tokens. The golden rule the documentation repeats is that your application remains the source of truth: keep your own copy of every message and build the path to replay the full conversation from day one. No response tells you whether the turn was stored; you only find out on the next `continue`. Anyone who treats the thread like a database is in for surprises. I haven't tested it; all of this comes from the official Claude Platform documentation, Anthropic's announcement and the coverage cited below. ## Sources - [Claude Platform: release notes for November 2, 2026](https://platform.claude.com/docs/en/release-notes/overview#november-2-2026) - [Official Message threads documentation](https://platform.claude.com/docs/en/build-with-claude/message-threads) - [Anthropic: Make long-running agents faster with message threads](https://claude.com/resources/articles/message-threads) - [The Next Web: Anthropic's message threads let Claude agents skip resending chats](https://thenextweb.com/news/anthropic-message-threads-beta-claude-api-agents)