Anthropic’s Claude threads target upload delays, with token bills unchanged

Claude still reads the full history on every turn, so token usage is unchanged. Threads also leave standard pricing and rate limits intact. The benefit is less data retransmission, without a corresponding reduction in the amount of context billed.

Prompt caching remains a separate mechanism for reusing earlier context. The thread documentation explicitly says a thread does not cache a prompt automatically: developers still configure cache controls. An application can use both features, but turning on threads alone does not produce cache savings.

Anthropic has separately lowered some cache prices. Its release notes record an October 7 cut in the price of prompt-cache reads for Claude Sonnet 5.5, a model aimed at coding and agents, from $0.20 to $0.10 per million tokens. Cache writes and all other prices were unchanged. That reduction applies to a particular model and billing category; threads do not add another token discount.

A Claude addition with an established precedent

Support was appearing in Anthropic’s software development kits before the public announcement. The October 23 releases list message-thread support in Python v2.2.0, TypeScript sdk-v1.2.0, Ruby v2.2.0, Java v3.2.0 and C# v13.2.0.

The new option extends a Messages API whose reference still describes stateless multi-turn conversations. It also follows a broader precedent: OpenAI, a competing model and API provider, described its Responses API as stateful in a September 2025 technical explanation, with conversation and tool state tracked automatically. Server-managed conversation state therefore predates Anthropic’s beta. That precedent does not establish equivalent retention rules or comparative speed.

Anthropic’s implementation is aimed at active sessions. The company identifies coding agents, computer-use agents carrying screenshots, and document- or image-heavy workflows as suitable uses. Its documentation and a report on the launch describe availability across all Claude models. Supported platforms are the native Claude Platform, Claude Platform on AWS, Claude in Microsoft Foundry and Anthropic-managed Claude Models on Google Cloud.

Anthropic’s documentation distinguishes create-only instructions and tool definitions, fixed settings, and fields that can change between turns. Source: Message threads.

Temporary state still needs a recovery plan

The five-minute expiry makes a thread a temporary aid to an ongoing conversation. After it expires, the client must resend the complete history to create another. Developers therefore still need their own recoverable copy.

Thread expiry and data deletion are separate commitments. Anthropic’s announcement says a thread expires five minutes after its last request. Its documentation says the contents are encrypted in memory under a server-managed key, never written to durable storage, and deleted no more than one hour after last use. The feature is not eligible for zero data retention and does not support organizations with HIPAA readiness enabled. There is no API to list, read or delete a thread.

The conversation is also append-only. Each response can be continued once, from the latest response ID. Editing or branching earlier turns requires a new thread. System instructions and tool definitions are supplied at creation; changing those or other fixed settings, including the model, also requires starting again.

Those limits matter for agents that revise their operating instructions or toolset during a task. Anthropic’s TypeScript helper documentation says the tool runner uses threads by default. Replacing its top-level system instructions or tool definitions during a run requires disabling threads. The same guide describes a separate inline-tools beta that can send tool additions and removals as messages, so that restriction does not rule out every tool change.

Recovery adds another qualification to the latency benefit. A missing thread requires replaying the full conversation. Responses written by a fallback model are not stored in the thread, so subsequent turns also require a new create request. Anthropic’s documentation says even a very large conversation can fail to be stored; if replay does not fix that, the client should send it without a thread. SDK helpers automate several replay cases, but applications still have to handle unsupported features and interrupted streams.

What developers still need to measure

The beta does not support built-in compaction, message batches, or thread-bearing token-counting requests. To replace old turns with a summary, developers must create that summary themselves and start a new thread from it. Most context-editing features are unsupported, as are organizations with inference hooks enabled.

The practical decision is whether an application spends enough time repeatedly sending large, active conversations to justify those constraints. Anthropic’s published result gives developers a reason to test that question, but no general latency guarantee. The useful next evidence is workload-specific: response-start times across conversation sizes, the frequency of expiry and replay, and whether the gain survives the application’s normal pauses, tool changes and recovery paths.