A long conversation can make each new agent request carry the weight of every earlier turn.
Anthropic announced message threads for the Claude Messages API on November 2. The beta lets an application send new messages while the service temporarily holds the preceding conversation. Anthropic says smaller requests can reduce the wait for the first token.
The next request carries the new turn
The message threads documentation describes a create-and-continue pattern. A later request refers to the previous response and supplies the additional messages. The application uses the latest response ID for the next continuation.
The beta header is message-threads-2026-08-12. That identifier is not the public announcement date. Anthropic lists support on the Claude API, Claude Platform on AWS, Anthropic-managed Google Cloud, and Microsoft Foundry.
A thread is temporary storage
A thread expires five minutes after its last request. Anthropic says the service deletes it no more than one hour after its last use. The documentation instructs applications to keep their own copy of every message.
When a continuation returns 404 because its thread is no longer available, the application must create a new thread with the full conversation. The documented SDK helper handles this replay. A service-side response ID cannot replace your application’s durable transcript.
| Situation | Application responsibility |
|---|---|
| Thread remains available | Continue from the latest response ID with the new messages. |
| Thread has expired | Create a new thread by replaying the saved conversation. |
| Application restarts | Recover its own transcript and continuation state. |
Smaller requests do not mean cheaper tokens
Anthropic says threads leave pricing and rate limits unchanged. The benefit is in request size and potential latency, not a new token discount. We have not measured the latency difference.
Message threads are not eligible for Zero Data Retention. Anthropic describes encrypted in-memory storage that is not written to durable storage. Teams with retention requirements should review that distinction before enabling the beta.
Separate transport from memory management
Threads change how a conversation reaches the API. Our Claude compaction guide addresses a different issue: replacing older history with a summary. Treating these as separate decisions makes it easier to identify why information disappeared.
For a first evaluation, I would use a short saved transcript and deliberately wait beyond the expiry window. The useful result is whether the application recovers the conversation correctly. This is a proposed test, not a completed beta trial.
Read the November 2 release note and thread lifecycle guide before changing a production client. Does your current agent already have a reliable transcript replay path?
Abdessalam Alaoui
I'm Abdessalam Alaoui, founder of Musthave.AI. I write practical guides to AI models, tools, generative media, and ways real people make money with this stuff. No press-release fluff. 20+ years shipping digital products; you'll also find my work around HowTik, Yumasty, and IncomeHelpful.
