Claude Message Threads: 35% faster first token, same token bill
Anthropic's Messages API has been stateless since it launched: every turn resends the entire transcript, tool results and screenshots included. That is fine until an agent loop passes half a million tokens, at which point the resend becomes the slowest part of the request. As of this week the API can hold the conversation on its own side instead.
Anthropic put message threads into public beta on Monday, and the number attached to it is a median 35% cut in time to first token for requests between 500,000 and one million tokens, according to Anthropic's announcement. The mechanism is the obvious one. The first request sends the full conversation with the system prompt and tools and opens a thread; each later turn sends only the new messages plus the ID of the previous response, and the API rebuilds the conversation before calling the model. Anthropic says the feature is on by default for most Claude Code users, which is why it can quote a median at all rather than a lab measurement.
The 35% is worth understanding before anyone plans around it. Without a thread, every turn uploads the whole conversation, and the API validates and tokenizes all of it again before the model reads a single new token. At 500,000 tokens that bookkeeping is the dominant term in the wait, so removing it moves the number; at 20,000 tokens it is noise. The gain scales with context, which is why Anthropic's own list of beneficiaries reads like a catalogue of long sessions: coding agents where every tool result and file edit accumulates, computer-use agents where screenshots otherwise get re-uploaded as base64 on every turn, and document pipelines that carry dozens of images.
The first catch: the bill does not move. Claude still reads the full conversation on every turn, so input tokens are unchanged, and Anthropic says standard token rates and existing rate limits apply. This is a latency feature, not a cost feature, and that distinction matters because "35% faster" is going to get read as "35% cheaper" in a lot of planning documents this week. The Next Web's write-up makes the same point in plain terms: the beta cuts the wait before Claude replies by about a third, and nothing else.
The second catch is the state, and it is where the engineering work lands. A thread is best-effort. It is held in memory encrypted, never written to durable storage, and expires five minutes after its last request; the API deletes it no more than an hour after last use. Continue against one that is gone and you get a 404, and you resend the full conversation from your own copy. No response tells you whether the API stored that turn — you find out on the next request. Threads are append-only, each response ID can be continued exactly once, system and tools are create-only and resending them returns a 400, and the model, thinking setting, tool choice, MCP servers, context management and top-level cache settings are fingerprinted, so any drift between turns returns a fingerprint-mismatch error. There is no API to list, read or delete a thread. Message Batches, token counting, compaction, most context editing and inference hooks are all unsupported, and threads are not eligible for zero data retention or HIPAA. Regulated workloads are out.
Prompt caching still does its own job and does not overlap. A thread does not cache your prompt for you: you place the cache breakpoints yourself, up to four per request once a thread is set, and a breakpoint you have already sent can never be moved or removed, because a continue request cannot resend an earlier message. Caching cuts the compute spent on the prefix; threads cut the upload and validation of it. Teams serious about both will run them together, which is exactly what the SDK's thread helper example shows.
The practical takeaway for anyone shipping an agent is unglamorous: keep your own copy of every message, build the replay path first, and treat automatic recovery as convenience rather than durability. The SDK helper replays once when a continue fails, and the beta tool runner uses a thread by default — which means the replay logic is now load-bearing inside tooling that previously did not need it. Fallbacks complicate it further: a turn written by a fallback model is never stored, so the next turn resends everything regardless.
The architectural shift is more interesting than the percentage. Anthropic's Messages API is becoming stateful by opt-in, the pattern OpenAI's Responses API already established, and the five-minute idle window is the tell that this first version is built for machine-speed loops rather than humans. Any workflow with an approval gate will fall off the thread and pay the replay. If that window is still the only option at general availability, most production agents will use threads as the fast path and keep the full resend as the fallback — the docs effectively tell you to.
PagerDuty shipped Paige, an SRE agent that can join an on-call rotation as a responder, and renamed its flagship product the PD Reliability Platform, per PagerDuty's release. Both are generally available today, alongside PD Labs, an early-access shop for features still in development. Permissions are set team by team: a team that wants a human in the loop gets faster triage with remediation held for approval, while autonomy is limited to low-risk scenarios the team explicitly authorises. PagerDuty's pitch is that AI-written code is reaching production with less review and failing in new ways — model drift, runaway token spend, leaked personal data — and CEO John DiLullo calls it a "tsunami of fragile AI-generated code".
The launch also carries a benchmark claim that Paige diagnosed simulated IT incidents better than leading AI coding agents. It is a vendor-run comparison with no independent replication, so treat it as a press release until someone else runs it. The more durable change is the pricing: a platform fee plus AI action credits, with spend allocatable between people and agent actions instead of seats alone, and bonus AI Actions for the first year on plans bought before January 15, 2027. Seat-based operations software is being repriced per agent action, which is a budget argument every reliability team is about to have.
Would you trust an SRE agent to resolve a low-priority incident without a human on the call? Write to us via our contact page.
