Image: Anthropic — Claude logo (official logo, public domain via Wikimedia Commons).
📌 KEY HIGHLIGHTS
- Anthropic opened Message Threads in public beta on the Messages API on 2 November 2026; the feature is already on by default for most Claude Code users, according to Anthropic.
- How it works: the first request sends the full conversation, system prompt and tools with a
threadparameter; later turns send only new messages plus the previous response ID. - Anthropic's claim, from its Claude Code rollout: median time to first token falls by about 35% on requests of 500,000 to 1 million tokens, and median request size in long conversations drops from about 800 KB to 1.8 KB.
- It does not cut costs. Token usage, pricing and rate limits are unchanged — Claude still reads the full conversation every turn.
- The limits are real: a thread expires 5 minutes after its last request, is best-effort with no list/read/delete API, and is not eligible for zero data retention or HIPAA use.
What happened?
On 2 November 2026, Anthropic opened Message Threads in public beta on the Claude Messages API. The problem it attacks is one every developer building an AI agent knows well: the API is stateless, so until now every turn of a long conversation re-sent the entire history — every earlier message, every tool result, every screenshot — and the API validated and tokenised all of it again before Claude could start answering. In a coding-agent loop that runs for hours, that re-upload grows with every turn, and the wait before the first token grows with it.
Message Threads move that state to Anthropic's servers for a short time. The idea is deliberately narrow: it is a latency feature for active sessions, not a memory feature and not a discount. Anthropic says it is already on by default for most users of Claude Code, its terminal coding agent, and the beta runs on every Claude model across four surfaces: the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry, and Claude Models on Google Cloud (Anthropic-managed).
That framing matters, because the launch has already produced one popular misunderstanding — that smaller requests mean a smaller bill. Anthropic's own documentation says the opposite in plain terms: threads do not change pricing or rate limits.
Claude Message Threads public beta explained: how it works
A thread has three moves: create, continue and replay. On the first turn, you send the request exactly as you do today — the full conversation, the system prompt and the tools — and add "thread": {"type": "create"}, plus the beta header message-threads-2026-08-12 on every request. The API stores the conversation, including Claude's reply, under that response's ID.
On every later turn, you send only the messages since the previous response, with "thread": {"type": "continue", "previous_message_id": "<previous id>"}, and you leave system and tools out — the thread keeps the values from the create request. The API rebuilds the full conversation on its side before calling the model, and the response is an ordinary message. You always continue from the latest response ID, because a thread is append-only and each response ID can be continued only once.
The official SDKs do most of this for you through a thread helper — client.beta.messages.thread(...) — which adds the beta header, leaves system and tools out of continue requests, and replays the full conversation once when a continue fails with certain errors. If you build requests yourself with cURL or the SDK's usual create method, you add the thread field by hand.
| Step | What you send | What the API does |
|---|---|---|
| Create | Full conversation + system + tools + "thread": {"type": "create"} | Stores the conversation under the response ID |
| Continue | Only new messages + "thread": {"type": "continue", "previous_message_id": "..."} | Rebuilds the conversation, calls the model, returns an ordinary message |
| Replay | Full conversation again in a new create request | Starts a fresh thread when the old one can't be continued (404) |
.jpg?width=900)
Image: Wikimedia Commons / Markus Spiske, CC0 — code on a monitor. Illustrative image; the feature is an API change, not a visible product.
What it does not do — the token-bill myth
This is the part worth getting right before you change any code. A thread makes the request you send smaller; it does not make the work Claude does smaller. Claude still reads the full conversation on every turn, so input tokens, token charges and rate limits are exactly the same as before. The saving is in what travels over the wire and what the API has to re-validate and re-tokenise before the model starts — not in what you are billed for.
Two related points follow from that. First, a thread does not cache your prompt for you. Prompt caching still works exactly as it does without a thread: you choose where the cache breakpoints go, and to cache each turn you send a top-level cache_control on every request. A threaded request can carry at most four cache_control breakpoints, and the top-level one counts as one. Second, the 35% figure is Anthropic's own claim from its Claude Code rollout, on requests of 500,000 to 1 million tokens — not an independent benchmark, and not a promise for short conversations, where there is little re-upload to remove in the first place.
| What changes | What stays the same |
|---|---|
| Request size: Anthropic says median ~800 KB → 1.8 KB in long conversations | Token usage: Claude reads the full conversation every turn |
| Time to first token: ~35% lower median on 500K–1M token requests (Anthropic's claim) | Pricing and rate limits: unchanged |
| Upload per turn: only new messages after the first | Prompt caching: still needs breakpoints you set yourself |
The limits that decide whether it fits your app
Message Threads is a public beta, and it behaves like one. The limits below come from Anthropic's own documentation, and they decide whether threads fit your app at all.
Threads expire fast. A thread expires 5 minutes after its last request. Each response the API stores restarts that clock, but an idle session is gone quickly — and when it is gone, a continue request returns a 404 (thread_not_found) and you resend the full conversation to start a new one. Threads are deleted no more than one hour after last use. That makes them a poor fit for human-in-the-loop flows where a person takes ten minutes to review a step — a common pattern in agency and services work, including in India — because every long pause pays the full upload again.
They are best-effort. No response tells you whether the API stored a turn; you find out on the next continue. The thread is held in memory under server-managed encryption and never written to durable storage. Your application stays the source of truth: keep your own copy of every message and build the replay path from the start, because there is no API to list, read or delete a thread.
Some things are excluded. Threads are not eligible for zero data retention (ZDR) or for HIPAA organisations, and they do not work with Message Batches, the Token Counting API, on-demand compaction, most context editing, or organisations with Inference hooks enabled. Changing a create-only field such as system or tools, or a fixed field such as the model, needs a new thread with the full conversation sent again.
Why it matters for Indian developers. India has a large base of developers and agencies building coding agents and support agents on the Claude API, and long agent loops are exactly where the latency gain shows up. But the same teams should note the trade-offs before adopting a beta: the 5-minute expiry punishes slow human review, the lack of ZDR rules it out for regulated clients, and there is no India-specific pricing — API charges are in USD, as with the rest of the Claude Platform. Threads are a speed optimisation for active loops, not a reason to drop your own conversation store.
Should you care?
The wider picture is that the coding-agent race is now being fought in the plumbing, not just in model quality. In the same week, PhpStorm 2026.3 shipped an agent workspace for coordinating coding agents inside the IDE, and Anthropic's models keep showing up in research headlines — one just helped prove a maths conjecture open since 2008. Threads are Anthropic's answer to the same pressure: agents that run for hours need the API to stop making them re-upload everything, every turn.
FAQs
What are Claude Message Threads?
Message Threads are a public beta feature of the Claude Messages API, announced on 2 November 2026. They let the API keep a conversation on Anthropic's servers for a short time, so after the first request an agent sends only new messages plus the previous response ID instead of the full history on every turn.
Do Claude Message Threads reduce token costs?
No. Claude still reads the full conversation on every turn, so token usage is unchanged, and Anthropic's documentation says threads do not change pricing or rate limits. The gain is lower latency — a shorter wait before the first token on long conversations — not a smaller bill.
How do you use Claude Message Threads?
Add the thread parameter to a Messages API request and send the message-threads-2026-08-12 beta header on every request. The first request is a create with the full conversation, system prompt and tools; later requests are continues with only new messages and the previous response ID. The official SDKs provide a thread helper that handles the header and replays the conversation if a continue fails.
What do Claude Message Threads not support?
Threads do not support Message Batches, the Token Counting API, on-demand compaction or most context editing, and they are not available to organisations with HIPAA readiness or Inference hooks enabled. They are not eligible for zero data retention, they expire 5 minutes after the last request, and there is no API to list, read or delete them.
Takeaway: Message Threads fix the shipping, not the reading. If your Claude agent spends its time re-uploading a long conversation, the beta is worth a try — with your own replay path built first. If your bill is the problem, look at prompt caching instead.
If you build on the Claude API, try a thread on your longest agent loop this week and read Anthropic's message threads documentation before you change your replay logic — the 5-minute expiry and the 404 recovery path are the two details that will bite first.
Sources
- Anthropic — Message threads (Claude Platform Docs, primary source)
- Unite.AI — Anthropic Launches Message Threads Beta for Long-Running Agents
- HardiAI — How do Claude message threads speed up long-running agents?
- aicodewith — Claude Message Threads: thread Parameter, Beta Header and Test (Messages API)
Comments
Post a Comment