Claude API adds server-managed message threads

• Claude’s Messages API now supports incremental conversation requests: clients send new messages plus the previous response ID, as described in Anthropic’s announcement.
• Large Claude Code requests start responding sooner: Anthropic reports about 35% lower median time to first token for requests carrying 500K to 1M tokens.
• The public beta spans four Claude platforms at standard token rates, according to Anthropic’s availability announcement.
• Smaller requests leave token usage unchanged: Claude still reads the full conversation with message threads, according to the launch post.

The API contract carries system and tools forward automatically, so continuation requests omit both. Server-side threads expire after five minutes of inactivity, while prompt caching remains a separate opt-in.

Message threads are already enabled by default for most Claude Code users, a rollout WesRoth noted in his launch coverage. Anthropic also reports that the median request size in long conversations fell from about 800 KB to 1.8 KB.

Much of the avoided work happens before inference: the documentation says threads reduce repeated uploading, validation, and tokenization of conversation history. Most of that work then covers only the new turn.

Every thread request carries anthropic-beta: message-threads-2026-08-12, according to the request documentation. The response remains an ordinary Messages API response.

The documented lifecycle has three operations:

1. Create: Send the full conversation, system, and tools, plus "thread": {"type": "create"}. The API stores the conversation, including Claude’s reply, under the response id.
2. Continue: Send only new messages with "thread": {"type": "continue", "previous_message_id": "<prior-response-id>"}. The thread supplies the original system and tools; each new response ID becomes the reference for the next turn.
3. Replay: An unavailable thread produces a 404 on continuation. Recovery resends the full conversation in a new create request, then continues from that response’s ID.

Thread storage and prompt caching are independently enabled. The SDK examples use optional top-level cache_control: {"type": "ephemeral"} to request prompt caching on each turn; without that field, caching requires explicit cache breakpoints.

Prompt caching reuses prompt prefixes to reduce processing and cost. Sending only a conversation’s delta through a thread leaves its full-context token accounting intact.

The availability announcement lists four surfaces:

• Native Claude Platform.
• Claude Platform on AWS.
• Claude in Microsoft Foundry.
• Claude Models on Google Cloud, specifically the Anthropic-managed offering.

Alongside standard token pricing, the launch post says existing rate limits continue to apply.

Threads are held encrypted in memory and never written to disk. The lifecycle documentation adds three operational details:

• Expiry and deletion differ: Each stored response restarts the five-minute lifetime. The API deletes a thread no more than one hour after its last use.
• Storage acknowledgment is missing: The sharpest edge is silent cache loss. Neither a successful create response nor a successful continuation confirms that the API stored the turn; the next continuation exposes an unavailable thread.
• The SDK keeps a local transcript: Its thread helper retains the full conversation in memory and automatically performs replay when needed. That copy lasts only as long as the helper object and has no durable storage behind it.