Claude API Launches Message Threads Beta to Speed Up Long Conversations
Anthropic has launched a beta for 'Message Threads' in the Claude Messages API, allowing the server to cache conversation context so developers no longer need to resend full history each turn. This feature significantly reduces request payload size (from ~800KB to 1.8KB) and cuts time-to-first-token by ~35%, though token pricing remains unchanged. It is particularly beneficial for long-running agents and multimodal interactions.
Full Report
Baoyu (@dotey) · 2026-11-02 19
Claude API launches public beta for Message Threads: No need to resend history every turn in long conversations, faster responses, same pricing.
Anthropic today launched the "Message Threads" public beta for the Messages API (the primary interface developers use to call Claude). The server temporarily stores your conversation for a few minutes, so in subsequent turns you only need to send new messages and the ID of the previous response.
Previously, this API did not retain message history; every request required resending all prior messages and tool results from scratch. An agent session might involve hundreds of requests. Once the conversation grows to hundreds of thousands of tokens, simply resending the data significantly delays the time it takes for Claude to begin responding.
Claude Code has already enabled this feature by default for most users. Official data shows that for requests with 500k–1M tokens, the median time-to-first-token (TTFT) is reduced by approximately 35%. In long conversations, the median size of individual requests drops from ~800 KB to 1.8 KB.
[Does it cost more?]
No, but it doesn't save money either. Billing remains at standard token prices, and rate limits are unchanged. Although requests are smaller, Claude still reads the full conversation context each turn, consuming the same number of tokens as before.
[How does it differ from Prompt Caching?]
Prompt caching allows the server to avoid reprocessing content it has already read, with cached portions billed at a lower rate, saving both cost and compute. Message threads save on upload bandwidth—you no longer need to transmit the entire history. Threads do not automatically handle caching; you must still set cache breakpoints manually. Official examples show the two features being used together.
[How do developers use it?]
Add the thread parameter and the beta header (message-threads-2026-08-12) to your requests. For the first turn, send the full conversation, system prompt, and tool definitions as usual, marking it as creating a new thread. Subsequent turns should only include new messages along with the ID of the previous response.
Threads expire if there are no new requests for 5 minutes, returning a 404 error. At this point, you must recreate a thread using the full conversation history stored locally. Therefore, you still need to maintain a complete local record. Helper methods in the official SDK can automate this step.
System prompts and tools cannot be modified mid-thread. Model settings and thinking configurations must remain consistent with the first turn; changing them requires restarting the thread. Thread data is encrypted and stored in memory, never written to disk. However, it does not support Zero Data Retention (ZDR) or HIPAA compliance, so enterprises with strict data retention requirements should take note. Batch processing APIs are currently unsupported.
This feature is suitable for long-running agents, computer-use agents (no need to resend screenshots every turn), and conversations involving large documents or images. It is available on Anthropic's own platform, AWS, Microsoft Foundry, and Google Cloud (Anthropic-hosted version).
Blog: https://t.co/cv3hNAAOEJ Docs: https://t.co/ttwODbh0do
↳ Quoting @ClaudeDevs (ClaudeDevs): Message threads are now in public beta on the Messages API.
The API caches your conversation on the server between turns, so instead of resending the full conversation, you send only new messages and the previous message ID, and Claude starts responding sooner.
