Anthropic's Message Threads Cut Agent Request Size from 800 KB to 1.8 KB

Anthropic has released message threads in public beta for the Messages API. The feature keeps active conversation state on Anthropic’s servers between turns, allowing clients to send only new messages instead of uploading the full history with every request.

Smaller payloads reduce serialization and upload time before Claude begins generating a response. The improvement becomes measurable in coding agents, computer-use loops, and other applications that accumulate hundreds of thousands of tokens across many turns.

Why large agent requests bog down

Messages API clients typically send every earlier message and tool result on each turn. A long-running coding agent may issue hundreds of requests while adding file contents, diffs, command output, and model responses to its context. At large context sizes, each request can contain megabytes of JSON that must be serialized and uploaded over HTTPS.

A message thread changes that request flow. The first request supplies the full conversation and starts a thread. Later requests contain the new messages and the ID returned by the previous response. Anthropic retains the earlier state and reconstructs the complete context for Claude.

Claude Code shows the gain

Anthropic tested message threads in Claude Code and reported the following median results:

Claude still processes the complete conversation on every turn, so input-token charges remain the same. The savings come from moving less data between the client and Anthropic before inference starts.

Send the history once

Enabling the feature requires a thread parameter and the designated beta header. Anthropic’s API documentation provides the current schema.

1. Send the full conversation in the initial Messages API request.
2. Store the response ID returned by Anthropic.
3. Send only the new messages on the next turn and reference the preceding response ID.
4. Repeat the sequence while the thread remains active.
5. Resend the full conversation if the thread expires.

Design for a five-minute lifetime

Threads provide short-lived server-side state, so production clients still need to retain a canonical conversation history for recovery.

Large, active contexts benefit most

Workloads with frequent turns and heavy payloads receive the largest latency reduction:

• Long-running coding agents: File reads, diffs, command output, and tool results steadily enlarge the conversation.
• Computer-use agents: Screenshots remain associated with the thread instead of being uploaded again on every turn.
• Document and image workflows: Large attachments can stay in the active thread while users submit smaller follow-up requests.

Short conversations containing a few thousand tokens may see little difference. Agent loops carrying 500,000 tokens across dozens of steps can avoid substantial repeated uploads.

The model still reads every token

Message threads optimize request transport and short-lived session management. They leave several other API behaviors unchanged:

• Token billing remains based on the full context processed by Claude.
• The model’s context-window limit does not increase.
• Prompt-caching behavior remains unchanged.
• Applications must continue managing conversation length.
• Clients must preserve enough state to recover from thread expiration.

Teams running high-context Claude agents can adopt the feature with a small request change and an expiration fallback. Measuring time to first token and request size will show whether a workload carries enough context to benefit.