Claude's Messages API gets message threads in beta: send only the new turn, not the whole conversation

Anthropic has put message threads for the Claude Messages API into public beta. Announced on November 2 by the ClaudeDevs account and described in a Claude blog post and the API docs, the feature lets a client stop resending the whole conversation on every turn. The server keeps the conversation for a few minutes, and each new request sends only what is new.

The Messages API has always been stateless: every request carries the full history, tool results and all. For long-running agents that means a growing upload on every step. Anthropic has already switched threads on by default for most Claude Code users, and its numbers come from there: on requests of 500K to 1M tokens, median time to first token is about 35% lower, and in long conversations the median request went from about 800 KB to 1.8 KB. Those are Anthropic's own measurements, not independent ones.

How it works

You opt in with the beta header message-threads-2026-08-12 and a thread parameter. The first request creates the thread; later requests continue from the id of the last response and send only the new messages.

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

A continue request must leave out system and tools, which stay fixed for the thread. Fields that define the thread have to match on every request, or the API answers with thread_fingerprint_mismatch. Threads are append-only, and each response id can be continued only once, so you cannot branch a conversation from an earlier point.

The SDKs add a thread helper, client.beta.messages.thread(...) in Python and TypeScript, which adds the beta header, resends the fixed fields and replays the conversation when a thread is lost. The SDK's beta tool runner now uses a thread by default.

What it does not change

Threads save bandwidth and latency, not tokens. Claude still reads the whole conversation on every turn, standard token prices apply, and existing rate limits stay as they are. Prompt caching is not automatic inside a thread either: without cache_control, later turns send only the new messages but nothing is cached.

The client also stays the source of truth. Threads are best-effort: a continue can fail with a 404 thread_not_found, and the client is expected to replay the full conversation from its own copy. A thread expires five minutes after its last request and is deleted within an hour. Anthropic says a thread's contents, including the system prompt and tools, are held in memory, encrypted under a server-managed key and never written to durable storage. Even so, threads are not eligible for zero data retention.

Several things do not work with threads yet: Message Batches, token counting, compaction, and context editing other than clearing thinking. Organizations set up for HIPAA cannot use them. Server-side fallback to another model needs extra handling, and after a response that ends in a refusal the docs say not to continue the thread.

Where it is available

The beta covers the Claude Platform, the Claude Platform on AWS, Microsoft Foundry and Google Cloud (where Anthropic runs the endpoint), for models from Sonnet 4.5 up to the current Fable 5.1 and Mythos 5.1.

The closest equivalent elsewhere is the previous_response_id field in OpenAI's Responses API, which also lets a client continue from a stored response. Anthropic's version is deliberately short-lived: five minutes of idle time is enough for an agent loop, not for a chat a user comes back to the next day.