# Claude's new message threads stop agents re-uploading the whole conversation. What changes, and what doesn't

> Anthropic has put "message threads" into public beta on the Claude Messages API, so long agent loops send only the newest turn instead of the full history. It is pitched as a latency fix, not a cost cut — pricing is unchanged — and it comes with a five-minute expiry and a replay path you have to build.

Published Nov 4, 2026 by TechMeasured Staff · AI · Canonical: https://techmeasured.com/ai/claude-message-threads-beta-send-only-new-messages-what-changes

Anthropic has opened a public beta of **message threads** for the Claude Messages API. Instead of uploading an agent's entire conversation on every turn, a client sends the full history once, then only the new messages plus the ID of the previous response; Anthropic keeps the conversation on its side and rebuilds it before calling the model. The feature was announced on Monday, November 2, according to The New Stack and Data Studios, and Anthropic says it is already switched on by default for most Claude Code users.

Why it matters: long-running coding and research agents can carry hundreds of thousands of tokens of history, and the stateless Messages API has always required clients to resend all of it every turn — which the API then re-validates and re-tokenizes. Threads attack that overhead. According to The New Stack, Anthropic's announcement reports about a **35% drop in median time to first token** for Claude Code requests in the 500,000 to 1 million token range. That figure is Anthropic's own, and the developer documentation itself gives no latency numbers — it says only that time to first token stays "lower and steadier" as conversations grow.

## What it does — and what it doesn't

The key point, which both The New Stack and Anthropic's documentation make plainly: **threads do not change pricing or rate limits.** Claude still processes the whole conversation each turn, so you are billed for the same input tokens as before. What shrinks is the size of each request and the server-side work before the model starts answering.

If you want lower bills on long loops, that is still the job of prompt caching. The docs say a thread does not cache anything for you; you can send a top-level `cache_control` on every request so each turn reads earlier history from the cache and writes the new turn.

## How to use it

Per Anthropic's docs, you add one parameter and one beta header (`anthropic-beta: message-threads-2026-08-12`) on every request in the thread:

```json
// Turn 1: full conversation, system prompt and tools
"thread": {"type": "create"}

// Later turns: only the new messages, no system or tools
"thread": {"type": "continue", "previous_message_id": "<id of the last response>"}
```

The official SDKs include a thread helper that adds the header, creates the thread on the first turn, continues it afterwards and keeps a copy of the history in memory. The docs also say the SDK's beta tool runner uses a thread by default.

## The rules that will trip you up

| Rule | What Anthropic's docs say |
|---|---|
| Expiry | A thread expires **5 minutes** after its last request; each stored response resets the clock |
| Deletion | Contents are deleted no more than **1 hour** after last use |
| Create-only fields | `system` and `tools` go on the create request only; sending them on a continue request (even as null) is a 400 error |
| Fixed fields | `model`, `thinking`, `tool_choice`, top-level `cache_control`, the set of beta headers and others must match the create request, or you get `thread_fingerprint_mismatch` |
| Append-only | Each response ID can be continued once; to edit, branch or compact, start a new thread |
| Cache breakpoints | At most 4 `cache_control` breakpoints per threaded request |
| Failure | A continue request can return 404 `thread_not_found` with no reason given |

That last row is the important one. Anthropic describes threads as **best-effort**: your application remains the source of truth and must keep its own full copy of the conversation. When a continue request fails — because the thread expired, a fallback model wrote the previous turn, the request came from a different user or service account, or other listed causes — you replay the whole history in a new create request. The SDK helper does one replay for you; raw API callers have to build it.

## Where it won't work

The docs list several exclusions: Message Batches, token counting, compaction on demand and most context editing are not supported with threads. Threads are **not eligible for zero data retention**, and organizations with HIPAA readiness or inference hooks enabled can't use them. Anthropic says thread contents are held in memory, encrypted under a server-managed key and never written to durable storage. There is no API to list, read or delete a thread.

The beta covers the Claude API, Claude Platform on AWS, Anthropic-managed Claude models on Google Cloud and Microsoft Foundry.

## Should you turn it on?

- **Agent builders with long, fast loops** (tool call, result, tool call) are the target: turns land well within five minutes, and the history is large.
- **Chat apps with humans in the loop** benefit less — a user who pauses for more than five minutes forces a full replay anyway.
- **Regulated workloads** relying on ZDR or HIPAA should wait.

Whatever you choose, keep caching on and build the replay path first. Data Studios points out that Anthropic hasn't published a maximum stored conversation size or a general-availability date, so treat the beta header as subject to change.


## Sources

1. [Claude Platform Docs — Message threads](https://platform.claude.com/docs/en/build-with-claude/message-threads.md)
2. [The New Stack — Anthropic speeds up Claude Code with message threads. But your token bill stays the same.](https://thenewstack.io/anthropic-claude-message-threads/)
3. [Data Studios — Claude API message threads beta: send only new messages, 5-minute expiry](https://www.datastudios.org/post/claude-api-message-threads-beta-cuts-request-size-long-agent-loops)