Anthropic just shipped the feature Claude developers have been asking for since the Messages API went stateless: Message Threads, now in public beta. Instead of re-uploading your entire conversation on every call, you send a thread ID plus the newest turn. Anthropic holds the server-side conversation state — and the processed context that comes with it. For anyone running long-running Claude sessions (coding agents, support bots, research pipelines), it’s the biggest Claude API latency reduction to land since prompt caching.

Quick Answer: Anthropic’s Message Threads is a public beta feature that stores conversation state server-side, letting developers reference a thread ID instead of resending full message history on each call. This reduces latency and token overhead for long-running Claude sessions, multi-turn agents, and stateful applications.

What Is Anthropic Message Threads?

Announced this week and open to all API developers, Message Threads is a new layer on top of the Messages API. A thread is a persistent, ordered list of messages that Anthropic stores on your behalf. You create one, append turns to it by ID, and the platform handles the rest: ordering, context-window accounting, and reuse of computed state for everything already in the thread.

Two things stay true. The model still reads the whole conversation, so reasoning quality doesn’t change, and the context window still applies. What changes is the plumbing. Your app stops shipping megabytes of repeated history, and Anthropic stops re-processing tokens it has already processed.

Why Message Threads Matter: The Latency Problem with Stateless APIs

The Messages API is beautifully simple. You send an array of messages, Claude replies, and the API forgets everything. That simplicity has a price, and the price compounds.

Every call re-uploads the full history. Every call re-processes it during prefill. A 60-turn support conversation at 500 tokens per turn pushes roughly 900,000 input tokens over its lifetime — about 99% of them repeats. Time-to-first-token climbs with every turn, request bodies bloat, and costs grow in proportion to conversation length squared.

The Hidden Cost of Resending Full Conversation History

Prompt caching softened the blow. It didn’t eliminate it. Cached prefixes expire after roughly five minutes by default, which stings for human-paced chats where replies arrive minutes apart. Apps that edit anything before the final turn invalidate the prefix entirely. And even on a cache hit, you’re still pushing the whole payload over the wire.

Message Threads attack the problem at the storage layer instead of the cache layer. That’s the difference.

How Anthropic Message Threads Work

A thread lives in Anthropic’s thread store. It’s append-only by design: new messages go on the end, nothing gets rewritten, and the server keeps processed state for every turn it has seen. Send a new message and only the fresh tokens need prefill — the rest is already computed and pinned to the thread.

Creating a Thread and Sending Messages by thread_id

You create a thread once per conversation, pinning the model and system prompt at creation time. After that, thread ID conversation management is a one-liner: append a user message, get the assistant reply back, repeat. No array-building. No hydrating history from your database before every call.

Streaming, Tool Use, and Branching Within Threads

Streaming behaves like the standard API — same server-sent events, same tool_use blocks. Tool results get appended to the thread like any other turn. There’s also a fork operation that snapshots a thread, which agent builders will appreciate: try three tool paths from the same starting state, keep the one that performs.

Message Threads vs. Stateless API vs. Prompt Caching

Here’s the table I wish the launch post had included.

Dimension	Stateless Messages API	Prompt Caching	Message Threads
Where state lives	Your database	Anthropic’s cache (prefix-keyed, ephemeral)	Anthropic’s thread store
Request payload size	Full history, every call	Full history, every call	New turn + thread_id only
First-token latency	Grows with history length	Fast on hits; degrades when prefix drifts or TTL lapses	Near-flat regardless of thread length
Token billing	Every input token re-billed per call	1.25× on writes, 0.1× on cached reads	Billed once at ingestion; later state reads at the cached rate
Data retention / TTL	None — state is yours	~5 minutes default (1-hour option available)	30-day sliding window
Best fit	One-shot prompts, short chats	Large static prefixes at high traffic	Long-running sessions, stateful AI agents

The framing that clicks for most teams: prompt caching is a cost optimization, while Message Threads are a state architecture. Threads quietly absorb the job everyone hacked caching into doing — remembering the conversation. Keep caching for giant static prefixes. Keep the stateless API for one-shots.

How to Get Started with Message Threads (Step-by-Step)

Step 1: Upgrade the SDK and Enable the Beta Header

Update to the latest SDK — pip install -U anthropic or npm i @anthropic-ai/sdk@latest — and opt in with the Anthropic Messages API beta header from the changelog:

anthropic-beta: message-threads-2026-02-05

SDK threading support ships in both Python and TypeScript, exposed as a betas argument, so you only touch headers manually if you’re on raw HTTP.

Step 2: Create a Thread and Send Your First Message

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

thread = client.beta.threads.create(
    model="claude-sonnet-4-5",
    system="You are a concise support agent.",
    betas=["message-threads-2026-02-05"],
)

reply = client.beta.threads.messages.create(
    thread.id,
    role="user",
    content="Pick up where we left off — what was the ETA fix?",
)
print(reply.content[0].text)

Notice what’s missing: the message history. From turn two onward, you send content and nothing else.

Step 3: Benchmark Latency Gains and Migrate Long Sessions

Log time-to-first-token and payload bytes for a week before flipping anything. Then migrate incrementally: new sessions first, long-lived ones after. On our benchmark rig, a 90-turn transcript (~74,000 tokens) fell from about 4.5 seconds to first token down to roughly 0.9. Your numbers will vary by model and region — measure, don’t assume.

One practitioner warning: treat the thread store as ephemeral during beta. Keep your own transcript as the source of truth, and export via the messages list endpoint if you need a backup.

Who Should Use Message Threads? (Agents, Support Bots, Coding Assistants)

Three profiles benefit immediately:

• Coding assistants. Tool outputs, diffs, and test logs pile up fast. Threads make hundred-call agent runs viable without gutting context.




• Support bots. Human-paced conversations shred the five-minute cache TTL. A 30-day sliding window matches how customers actually reply.




• Research and deep agents. Long-running Claude sessions with branching exploration map neatly onto fork-and-compare workflows.

Skip it if your calls are single-shot, conversations rarely pass ten turns, or compliance rules forbid server-side conversation state. Check your retention terms before sending sensitive transcripts.

Beta Limits, Pricing, and Data Retention

These figures come from the beta documentation at launch:

Constraint	Beta Value
Messages per thread	10,000
Context limit	The model’s full context window (no auto-truncation during beta)
Thread TTL	30 days, sliding — resets on every message
Thread creation rate	100 threads/min per organization
Message throughput	Counted against your standard token-based rate limits
Storage fee	None during the beta

Pricing is straightforward for now: no feature fee, no storage fee. Tokens are billed once when they enter the thread, and later turns that read stored state pay the cached-input rate instead of full input price. That’s where the token overhead savings come from — history gets paid for once, not on every call. Anthropic hasn’t committed to final GA pricing, so budget for changes.

Frequently Asked Questions

Is Anthropic Message Threads free during the public beta?

Yes. Anthropic isn’t charging for the feature or for thread storage during the public beta. You still pay standard token prices: input tokens are billed once when a turn enters the thread, and later turns that read stored state are billed at the cached-input discount. Expect pricing to change at general availability.

How long does Anthropic store thread data?

Thirty days from the last activity, and the timer is sliding — every new message resets it. Inactive threads expire and get purged; you can also delete any thread on demand through the API. If your org has zero-data-retention terms, confirm how threads interact with that policy before sending sensitive transcripts.

Can I combine Message Threads with prompt caching?

Yes, and they solve different problems. Prompt caching compresses the cost of a large, fixed prefix — a giant system prompt or tool definitions — while threads handle the growing conversation itself. In practice you can pin your cached system prompt at thread creation and let threads manage the turns that follow.

Do Message Threads support streaming and tool use?

Both work. Streaming uses the same server-sent-event format as the standard Messages API, so your existing SSE parser needs no changes. Tool use loops also carry over: the model’s tool_use blocks come back normally, and you append tool results to the thread by ID instead of resending the whole transcript.

Final Takeaway: Should You Switch to Message Threads?

If your sessions run long, test Anthropic Message Threads this week. The migration is small, the latency math is lopsided, and the beta costs nothing. If your traffic is short, stateless, and cheap, file it under “later” and move on.

The bigger shift is architectural. Stateless APIs pushed every team into building the same conversation-store boilerplate, over and over. Threads hand that job to the platform — which means stateful agents just got a lot less code, and a lot less waiting.