Latest in AI
Claude Message Threads: Smaller API Requests, Pricing and Limits
Anthropic's new beta cuts repeated conversation uploads, but developers still need to keep their own history and manage caching separately.
Anthropic introduced message threads in beta on November 2, letting Claude API applications send only new messages after the first request. The change targets long conversations and agent loops, where repeatedly uploading the same history adds work before the model can begin responding.
The release notes describe smaller requests and lower time to first token. Availability includes the Claude API, Claude Platform on AWS, Anthropic-managed Claude Models on Google Cloud and Microsoft Foundry. This is an API feature, rather than a new memory setting in the Claude app.
What changes in an agent loop
Consider an agent reviewing a repository. It reads several files, receives tool results, asks for another file and continues. The growing history contains useful context, but much of the next request repeats material already sent.
With message threads, the server retains that conversation temporarily. Later requests append new messages instead of uploading the whole transcript again. The required beta header is message-threads-2026-08-12; the date in that identifier is different from the November 2 release-note date.
That is most interesting when an application makes many consecutive turns with substantial context. A short, single-request task has less repeated material to avoid. There is no universal speedup figure in the announcement, so teams should measure their own time to first token rather than assume a fixed percentage improvement.
Message threads do not lower token prices
The thread documentation says pricing and rate limits stay unchanged. A smaller upload is not the same as a smaller model context.
Prompt caching is a separate optimization. Claude's caching documentation describes reusing prompt prefixes to reduce processing work and cost. On the Messages API, applications opt in through cache_control, either at the request level or on individual blocks.
A team can therefore have two different problems: repeatedly transferring conversation data, and repeatedly processing the same prompt prefix. Threads address the first. Caching addresses the second. Turning on a thread does not automatically turn on caching.
For the repository-review example, useful measurements include request payload size, time to first token, cache usage and total task cost. Watching only the response time could hide whether an improvement came from transport, cached context or a change in the model's work.
Keep the application as the source of truth
Threads expire five minutes after their last request and are deleted no more than an hour after last use. They are not durable conversation storage.
Keep the complete history in your application. If continuation fails with thread_not_found, send that history in a new create request. Each response ID can be continued only once, so branching needs a new thread rather than two continuations from the same response.
These constraints matter for agents that pause for human approval. A person may return after the server-side thread has expired. The product should resume from its own saved state instead of treating an expired optimization as a lost conversation.
Where the beta does not fit
Threads are not eligible for zero data retention or HIPAA workloads. They do not support Message Batches, compaction or organizations with inference hooks enabled. There is no API to list, read or delete a thread.
That makes adoption a workflow decision. An existing system that depends on compaction or particular data-handling requirements cannot simply enable threads everywhere.
The promising change is narrower and useful: an active agent can stop carrying its entire conversation over the network on every turn. Keep recovery and persistence in the application, then use the thread to make the uninterrupted part of the loop lighter.
I'm Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders turn API changes and product launches into clear stories that developers understand and share.