Faysal AzizClaude message threads: less upload, same token bill
Anthropic’s message threads beta lets busy agents send only new messages and a response ID after the first turn. That can cut upload time, but the full context is still processed and billed.
By George the bot
Edited and approved by Faysal Aziz
Published
If you have built an agent that keeps talking to Claude, you know the routine: every new turn usually sends the entire conversation again. The latest question may be one sentence, but the request can drag along pages of tool results, code and screenshots. Anthropic’s new message threads beta changes the trip to the server, not the amount of work Claude does once the request arrives.
What changes
Your first Messages API request still sends the full conversation, system prompt and tool definitions. Add `thread: {type: "create"}` and the beta header. Anthropic returns a normal response ID. For the next turn, send only the new messages with `thread: {type: "continue", previous_message_id: "<previous response ID>"}`. Leave the system prompt and tools out of that continuation; the thread retains them. Save each new response ID for the next turn.
That is the practical idea: stop repeatedly uploading the same bulky JSON. Anthropic reconstructs the conversation before calling Claude, so the model still sees the full context.
The speed claim, in context
Anthropic says median time to first token fell by about 35% in Claude Code requests carrying 500,000 to one million tokens. AlphaSignal reports Anthropic’s comparison of roughly 800 KB versus 1.8 KB for median request size in long Claude Code sessions. Those are vendor-reported observations from a large-context workload, not a promise that every app will feel 35% faster. A short chat with tiny requests may barely notice.
Nor does a small upload mean a small token bill. Claude still processes the full conversation each turn. Standard token rates, rate limits and context-window limits remain. Message threads are transport and request-processing optimisation, not a substitute for prompt caching or conversation pruning.
The five-minute catch
A thread expires five minutes after its last request. If a continuation can no longer be resumed, the API returns 404. Your application must keep its own complete conversation and start a fresh thread by replaying it. Do not treat the response ID as your only copy of the chat.
Anthropic says thread contents are encrypted in server memory and not written to durable storage. Its API documentation also says this feature is not eligible for zero-data-retention terms and that expired thread data is deleted no more than one hour after last use. That distinction matters if you handle sensitive material: “five-minute expiry” is not the same statement as immediate deletion.
What to try in your own agent
Start with a long-running workflow, such as a coding assistant or a computer-use loop. Keep a canonical message log, then use a thread for active turns. Measure upload bytes and time to first token with and without the feature, especially after the conversation grows. Test an idle period longer than five minutes and make sure the 404 replay path actually works. If you use the SDK thread helper, remember it keeps the history only in memory while that helper exists; persist it yourself if the session must survive a process restart.
The beta is available on the native Claude Platform and the Anthropic-managed Claude offerings on AWS, Microsoft Foundry and Google Cloud. It is worth learning if your agent carries a large context and makes frequent turns. Just keep the accounting straight: fewer bytes on the wire, same tokens at the model.