On November 2, 2026, Anthropic released message threads in public beta on the Claude Messages API. The idea is simple: send the whole conversation once, and on every turn after that, send only the new messages and the ID of the last response. The API keeps the rest.

Anthropic says the payoff is speed. With message threads on by default for most Claude Code users, it reports that requests with 500,000 to 1 million tokens see median time to first token drop by about 35%.

We already covered Anthropic's legal work updates, so this one is for developers and anyone running agents. To decide whether to adopt it, we ran the announcement through the same loop we teach in our OODA loop guide for AI workflows: observe what actually shipped, orient on what it means, decide whether it fits, then act on a rollout plan.

✅Key takeaways: (1) Message threads let each request carry only new messages, which lowers time to first token in long sessions. (2) It doesn't save money: token usage, prices, and rate limits are unchanged. (3) Threads expire 5 minutes after the last request, so your code must be able to resend the full conversation at any time. (4) The system prompt, tools, model, and several other settings are locked in when the thread starts. (5) It's not eligible for zero data retention or HIPAA, and doesn't work with batches, token counting, or compaction. (6) Best fit: long coding, computer-use, and document-heavy agents where latency matters.

Observe: what Anthropic actually shipped

Here's what the launch post, the message threads documentation, and the release notes say.

The problem it solves

The Messages API is stateless. Every request carries the entire conversation: the system prompt, the tool definitions, and every message and tool result so far. That's simple and predictable, but agents build up huge conversations. Each file a coding agent reads, each screenshot a computer-use agent takes, and each document a research agent pulls in gets resent on every turn. In Anthropic's words, "once a conversation reaches hundreds of thousands of tokens, resending all of it adds time before Claude starts responding."

How a thread works

  1. Create. The first request is a normal request with the full conversation, system, and tools, plus "thread": {"type": "create"}. The API stores the conversation, including Claude's reply, under the response id.
  2. Continue. Each later request sends only the new messages, plus "thread": {"type": "continue", "previous_message_id": "<id of the last response>"}. You leave out system and tools; the thread keeps the values from the create request.
  3. Response. You get back the usual Message object, with a new id to continue from.

A continue request body is tiny:

{"model": "claude-opus-5-5", "max_tokens": 1024,
 "thread": {"type": "continue", "previous_message_id": "msg_..."},
 "messages": [{"role": "user", "content": "Now run the tests."}]}

Every request in a thread needs the beta header anthropic-beta: message-threads-2026-08-12. The SDKs take it as a betas option, and Anthropic's docs also show an SDK helper (client.beta.messages.thread(...)) that manages IDs and the header for you.

Where it's available

Public beta on the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed), and Claude in Microsoft Foundry. Amazon Bedrock isn't on the list. The docs list support for current models, including Claude Opus 5.5, Sonnet 5.5, Haiku 5.5, and Fable 5.1, plus several Claude 4.x models.

What it costs

Nothing extra, and nothing less. Anthropic says "standard Claude token rates and existing rate limits apply," and "Claude still reads the full conversation on every turn, so token usage stays the same." Requests get smaller over the wire; the model's work doesn't.

Orient: what it means for you

Orientation is the phase that shapes everything else, so this is where to be careful. Four points matter.

1. It's a latency feature, not a cost feature

The easiest mistake is to assume "sending less" means "paying less." It doesn't. If cost is your problem, the tool is still prompt caching, which bills cached input at a reduced rate.

The docs are explicit that "a thread does not cache your prompt for you." Use both together: send a top-level cache_control on each request (the docs' own example does this) so each turn gets cached. A threaded request can carry at most four cache_control breakpoints, the top-level one counts as one, and breakpoints on system and tools from the create request count again on every continue request.

Prompt caching Message threads
What it reduces Input token cost and processing time for a repeated prefix Request size and time to first token
Changes your bill? Yes, cached reads are cheaper No
Where the conversation lives You resend it every time The API holds it between turns
Use them together? Yes Yes

2. The client is still the source of truth

A thread expires 5 minutes after its last request, and the API deletes it no more than an hour after its last use. There's no API to list, read, or delete a thread. So the server copy is a performance shortcut, not storage. Your app must keep the full conversation itself and be ready to replay it in a new create request whenever a continue request fails.

This is the same principle as in the OODA guide: observe the real state, not a summary of it. Your own record of the conversation is the real state.

3. The setup is locked in

A thread is append-only, and each response id can be continued once. Some fields are fixed for the life of the thread:

If your agent swaps tools mid-session, edits earlier messages, or branches conversations, each of those means starting a new thread.

4. It changes your data-handling story

Anthropic says thread contents are held in memory, encrypted under a server-managed key, never written to durable storage, and deleted no more than an hour after last use. Even so, message threads are not eligible for zero data retention (ZDR), and organizations with HIPAA readiness enabled can't use them. If your organization has a ZDR agreement or handles health data, check with whoever owns that agreement before turning this on. Our guide to AI workflows for cloud security covers how to think about where AI data goes.

What people are doing with it so far

The beta is two days old, so nobody has months of production data yet. But the first adopters are already visible, mostly in open-source agent frameworks on GitHub. Here's what they're doing, as of November 4.

Claude Code: on by default

Anthropic's own coding agent is the first big user. Anthropic says message threads are on by default for most Claude Code users, and that's where its 35% time-to-first-token figure comes from. If you use Claude Code on long sessions, you're probably already using threads without changing anything.

nanocode: merged, but off by default

The open-source Rust coding agent nanocode merged threads support on launch day. The interesting part is how cautious it is:

Pydantic AI: an opt-in setting under review

The Python agent framework Pydantic AI has an open feature request and an open pull request. The proposal is a simple switch, anthropic_thread, that defaults to off and is modeled on the framework's existing support for OpenAI's equivalent feature. It sends the thread field without requiring a new Anthropic SDK version, and replays the full history when a thread has expired. The author marks the design as provisional, and the tests also use a mock rather than live API calls.

LiteLLM: passing threads through a gateway

LiteLLM, the popular gateway that sits between apps and many model providers, has an open docs pull request describing how it forwards the thread field on direct Anthropic routes and adds the beta header itself. The docs also flag the gateway-specific catches: routes that translate requests for another provider answer with a 400 error instead, and beta headers the gateway adds automatically count toward the thread's locked settings, so a change in them can cause a fingerprint mismatch.

OpenClaw and Hermes Agent: asking for it

Two other agent projects, OpenClaw and Nous Research's Hermes Agent, have feature requests open (OpenClaw, Hermes Agent). Both propose an opt-in setting with a full replay when a thread is gone. A comment on the Hermes request raises a practical point: a thread is tied to the credential that created it, so tools that rotate between several API keys need to start a new thread whenever they switch keys.

The pattern so far

Example: how a typical agent session uses a thread

Here's how the three use cases Anthropic highlights play out in practice. These are illustrations, not measured results.

Decide: should you adopt it?

Your situation Our call
Long-running coding agent with big tool results Yes. This is the case Anthropic measured
Computer-use agent sending screenshots Yes. Screenshots stay with the thread instead of being re-uploaded each turn
Document- or image-heavy workflows Likely. Requests get much smaller
Short chats or single-shot requests Skip. Little to gain, more code paths
Chat apps where users pause more than 5 minutes Limited. You'll often fall back to a full resend anyway
Message Batches, token counting, or compaction Not supported with threads
ZDR or HIPAA requirements No, unless your compliance owner approves

Two more limits worth knowing: compaction isn't supported (Anthropic's suggestion is to start a new thread from a summary), and most context editing isn't either. Only clearing thinking blocks with keep: "all" is allowed.

Act: how to roll it out safely

Keep the loop tight: small, reversible steps, checked against real measurements.

  1. Measure first. Log time to first token and request size for your current agent, by conversation length. Without a baseline, you can't tell whether threads helped.
  2. Wrap it behind a flag. Threads are a beta. Put them behind a feature flag so you can turn them off without a deploy.
  3. Build the fallback before the happy path. On a 404 thread_not_found, replay the full conversation as a new create request. That error covers several cases: the thread expired, a fallback model wrote the last turn, the request came from a different workspace or user, or the new messages add something the stored thread can't take, such as the first image.
  4. Handle the other thread errors. thread_fingerprint_mismatch means you changed a fixed field: fix the request or start a new thread. thread_already_continued and thread_continue_in_flight mean that response was already used.
  5. Get streaming right. The response id arrives in message_start, but only continue after message_stop. If a stream drops, resend the same continue request. If that returns thread_already_continued or thread_continue_in_flight, replay the full conversation in a new thread.
  6. Handle special stop reasons. After stop_reason: "pause_turn", continue with "messages": []. After stop_reason: "refusal", don't continue the thread; start a new one.
  7. Keep fallbacks consistent. If you use server-side model fallbacks, send fallbacks on every request in a thread or on none.
  8. Re-measure, then widen. Compare time to first token against your baseline, especially for your longest sessions, before rolling out to everyone.
⚠️Agents and untrusted content: Threads make it cheaper to keep big tool results, web pages, and documents in an agent's context. That's also where prompt injection hides. Keep treating everything an agent reads as data, not instructions, and keep irreversible actions behind human approval. Our Claude Code security workflows guide covers how.

The bottom line

Message threads are a solid, narrow upgrade. If you run long agent sessions on the Claude API and latency hurts, they're worth trying now: you send less, Claude starts answering sooner, and nothing changes on your bill. The trade-offs are real, though. You're building on a beta, you must keep the full conversation yourself, and the system prompt, tools, and model are locked in for each thread. If you need ZDR, HIPAA, batches, or compaction, wait.

New to the Claude API? Start with our review of Building with the Claude API, then compare coding agents in Cursor vs Copilot vs Claude Code, and see how retrieval fits in our IBM RAG and agentic AI review.

Check your understanding

Answer each question from memory before opening it. Recalling, not rereading, is what makes learning stick (here's why).

1 What does a message thread change about a Messages API request?

After the first request starts the thread, each later request sends only the new messages plus the ID of the previous response. The API keeps the rest of the conversation, including the system prompt and tools, on its side.

2 Do message threads lower your token costs?

No. Claude still reads the full conversation on every turn, so token usage, prices, and rate limits stay the same. Threads make requests smaller and lower time to first token. Prompt caching is still what lowers input cost.

3 How long does a thread last, and what should your code do when it's gone?

It expires 5 minutes after its last request, and is deleted no more than an hour after its last use. When a continue request returns thread_not_found, resend the full conversation in a new create request.

4 Which fields can you change between turns of a thread, and which can't you?

System and tools are sent only on the create request. Model, tool_choice, thinking, MCP servers, output config, top-level cache_control, and the beta headers are fixed for the thread. Per-request settings like max_tokens, stop_sequences, stream, and metadata can change.

5 Why do most early adopters, like nanocode and Pydantic AI, ship message threads turned off by default?

Because threads aren't eligible for zero data retention: the conversation can stay in Anthropic's memory for up to an hour. Making it opt-in lets teams with strict data rules keep their current behavior.

6 Name two situations where message threads aren't the right tool.

Any two of: you need zero data retention or HIPAA, you use Message Batches or token counting, you rely on compaction or most context editing, your conversations are short, or users pause for longer than 5 minutes between turns.

Sources

← All AI & Workflows