Anthropic opens message threads beta for smaller agent requests Anthropic opens message threads beta for smaller agent requests

Short-lived state for active sessions

The first request sends the conversation; later turns reference the previous response. Anthropic says the state stays encrypted in memory and is not written to disk. Claude still reads the complete conversation, so token usage is unchanged. The public beta follows earlier client-library work, rather than introducing every supporting component at once.

The client still owns recovery

Anthropic’s Python implementation, committed on October 22, keeps a local view of the complete conversation and tracks which response the server holds. It rejects overlapping send, parse or stream operations on one helper. A fork copies the history into a new thread instead of continuing the old response. Interrupted streaming receives separate treatment: the helper retains completed blocks and any unfinished text, while dropping an incomplete tool call. Its next turn rebuilds the thread because the client cannot assume the server saved exactly the partial response it received. If a fallback model produced the answer, the helper also starts a new thread on the following turn. An optional continuation setting can stop using threads after an immediate repeat loss after replay. These behaviors make local conversation management part of the feature’s operating contract. A server-side shortcut does not remove the application’s responsibility for deciding which complete results its own tools can act on.

Caching remains separate

Anthropic’s prompt-caching cookbook provides a concrete comparison. Its multi-turn example continues sending the accumulated conversation list, even when caching is enabled. A top-level cache-control setting moves the cache breakpoint forward as the conversation grows. Earlier context can be read from cache while the newly added turn is written. The notebook reports cache-read and cache-creation tokens separately, alongside ordinary input and output usage. It also compares a baseline call, a cache write and a subsequent cache hit, distinguishing the cost of establishing reusable context from benefiting from it. Developers can instead place explicit breakpoints on content blocks, or combine those with automatic handling. The notebook supports up to four explicit breakpoints, with automatic caching consuming one slot. This is existing caching behavior, illustrated in an October 24 revision, not an additional feature announced with threads. The cache has its own five-minute default lifetime, refreshed by hits, and an optional one-hour lifetime with different pricing. Five-minute cache writes cost 1.25 times the base input price; reads use a model-dependent fraction of that rate.