Claude message threads: what they are and how to use them

Claude message threads are a new public beta on the Messages API: the server keeps your conversation for a few minutes between turns, so each new request carries only the new messages and the ID of the previous response. You pay the same per token. What you get is a faster start on long agent sessions: Anthropic says median time to first token drops by about 35% on requests between 500K and 1M tokens.

The posts on X

Anthropic's developer account announced it on Monday, November 2. @ClaudeDevs wrote that instead of resending the full conversation, "you send only new messages and the previous message ID," and Claude starts responding sooner. The post came with a short video.

A few hours later @WesRoth picked up a line from Anthropic's announcement that's easy to skim past: the feature is "already enabled by default for most Claude Code users." If you use Claude Code on long sessions, you may already be on threads without having touched a setting. He also listed where it runs: the Claude Platform, Claude Platform on AWS, Microsoft Foundry and Anthropic-managed Claude on Google Cloud, at standard token rates.

What changes, and what doesn't

Until now, every call to the Messages API was stateless. On turn 40 of an agent session, you uploaded turns 1 through 39 all over again. With a thread, the first request sends everything and opens the thread. Every later request sends only what's new.

The bill stays where it was. Anthropic's announcement says so directly: Claude still reads the full conversation every turn, so token counts match a normal request. You get smaller payloads and a quicker first token, and that's it. If cost is your problem, prompt caching is still the tool for that, and the message threads docs say plainly that a thread does not cache your prompt for you.

Threads pair well with the request size increase we wrote up last week in the Claude API 128 MB limit. Both help the same kinds of work: long computer-use sessions, document-heavy agents and coding agents that run for hours.

How to use it

Send the beta header anthropic-beta: message-threads-2026-08-12 on every request in the thread. Then:

1. Open the thread. Add "thread": {"type": "create"} to an ordinary Messages request with your system prompt, tools and full message history.
2. Continue it. On the next turn send only the new messages plus "thread": {"type": "continue", "previous_message_id": "<id of the last response>"}. Leave system and tools out completely. The docs say sending either one, even as null, returns a 400.
3. Keep fixed settings fixed. model, thinking, tool_choice, mcp_servers and your beta headers have to match the create request, or you get thread_fingerprint_mismatch. max_tokens, stream and metadata can change per turn.
4. Handle expiry. A thread expires 5 minutes after its last request. A continue call after that returns a 404 with thread_not_found, and the fix is to resend the whole conversation as a new create request.

In the Python SDK, a sketch based on the docs looks like this:

first = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system="You are a support agent for Acme. Keep replies short.",
    messages=[{"role": "user", "content": "Hi! I have a question about an order."}],
    thread={"type": "create"},
    betas=["message-threads-2026-08-12"],
)

second = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "It's order 1042."}],
    thread={"type": "continue", "previous_message_id": first.id},
    betas=["message-threads-2026-08-12"],
)

Some rules to know before you build on it. Threads are append-only, and each response ID can be continued only once, so editing or branching means starting a new thread. With streaming, the ID shows up in message_start, but you should wait for message_stop before continuing. A thread request can carry at most four cache_control breakpoints. The docs also list threads as not eligible for zero data retention. If you handle regulated data, check that before turning it on.

Our read

This is plumbing, and we like it anyway. The part to design around is the 5-minute window. Developer Gabriel Anhaia summed it up in the title of his write-up on DEV: keep your own copy. Treat the server's copy as a speed boost and keep the real record of the conversation in your own app.

We've seen a run of changes like this lately. OpenAI's 12-hour prompt caching and Anthropic's Fable 5.1 cache read changes also made long agent sessions cheaper or quicker to keep going. Both labs seem to be planning for agents that stay on a task for hours.

What it means for businesses using AI

Wait time matters more than most owners expect. An assistant that pauses before every answer tends to get ignored by staff, and threads shorten that pause on the longest sessions at no extra cost. If you have a back-office task in mind for an agent and want to know whether it's ready, New Face Design's free process audit can tell you.