Long-running AI agents can spend a lot of time getting each request ready. A coding agent might need to send Claude not only the latest question, but also the conversation history and tool results it has accumulated over hundreds of earlier steps. Once that history gets huge - hundreds of thousands of tokens - resending it every turn becomes both slower and more awkward to manage.
Anthropic's message threads beta changes how developers send that history. Instead of resending the full conversation each time, an agent provides it once, then sends only the new messages along with the ID of Claude's previous reply. Anthropic says this cut the typical wait before Claude started answering by about 35% on very long requests of 500,000 to one million tokens. That's a real latency win for certain workloads. But it's not a "shorter context" feature, and it doesn't change prices or rate limits. Claude still reads the full conversation on each turn.
This article breaks down how threads work, where they can improve an agent's request cycle, and what you'll need to handle before adopting them. The key distinction is simple: threads reduce repeated transmission, and they may reduce how long it takes Claude to begin responding. They do not remove the work of processing the conversation.
What are Anthropic message threads?
Anthropic message threads are a beta API feature for keeping conversation state across requests. With a standard approach, you resend the entire conversation on every turn. With threads, you send the full conversation once. For later requests, the agent sends only the new messages, plus an identifier for Claude's last reply.
This matters most when one user request triggers many model calls. A coding agent is a good example: it might inspect files, ask Claude to plan a change, run a tool, pass back the tool output, and then ask what to do next. Each step adds to the conversation. Without threads, the agent repeatedly includes that growing history so the model has the necessary context.
The conversation still exists; the request changes
Threads change how conversation content is carried between API calls. They don't mean the agent can "forget" earlier messages, or that Claude can respond without prior context. What the feature does is give the API a way to attach new input to an existing conversation, rather than forcing the client to keep transmitting everything again.
So when you evaluate the feature, treat it as a request-flow change - not a claim that long conversations have suddenly become cheap for the model to handle. Anthropic says Claude still reads the full conversation on each turn. The promised benefit is less repeated transmission and a shorter wait before Claude begins responding on very long sessions.
Where this fits in an agent architecture
Most agents need multiple kinds of state: the user's intent, the message and tool history, and the current task status. Threads help with the conversation part between model calls, but they don't replace the rest of your agent state management.
You still need to decide what to store, how to recover after a failure, and what happens when a thread is no longer available. Think of threads as a managed session mechanism, not a complete persistence layer or an agent framework. Keeping that boundary clear makes it easier to build a fallback before you rely on a beta feature.
How do threads change a Claude agent's request flow?
Without threads, an agent typically sends the accumulated conversation with every request. If the session includes lots of prior dialogue and tool output, the same information gets included again and again. The payload keeps growing as the session continues, even when the latest turn adds only a small instruction or tool result.
With threads, the flow looks more like this:
- Start the conversation: Send the full conversation to Claude.
- Receive and record the reply: Keep the returned reply identifier in your app's session state.
- Continue the session: Send only new messages and the identifier of Claude's last reply, rather than resending the transcript.
- Maintain your own record: Store the conversation and any application state you need outside the thread.
The main operational change is incremental communication. Your agent doesn't keep packaging the same history into every request. That can reduce work in both request preparation and transmission - especially when the history is large.
A coding-agent example
Picture an agent working through a multi-step bug fix. It reads a repository, asks Claude to identify likely causes, runs a test command, and then returns the output for analysis. After a few cycles, the conversation may include a lot of code context plus multiple tool outputs.
In a traditional setup, the next call carries all of that history again, along with the latest test output. In the thread model, you still provide the conversation once up front, but after that you send the new test output and the relevant new messages tied to the previous reply's ID. Claude can continue the same conversation without you resending every earlier turn.
Anthropic says it has already enabled threads for most users of Claude Code. For requests between 500,000 and one million tokens, Anthropic reports that the typical wait before Claude starts answering fell by about 35%. That's helpful for planning, but it's not a guarantee you'll see the same improvement in every app or request size.
Keep a client-side source of truth
Threads are convenient, but they don't remove the need for application-owned state. Anthropic says threads are held in memory, encrypted, and expire five minutes after the last request. They are not written to disk.
In practice, that's easy to miss if you assume the thread ID alone gives you everything you need. In production, a process restart, a gap between requests, or a failed tool call can leave your agent needing to rebuild its state. If your application relies only on the thread ID, you may not be able to resume reliably after the thread expires.
What do message threads improve - and what stays the same?
The clearest benefit is reduced waiting before Claude starts responding in very long sessions. If you repeatedly send a large conversation, you add overhead to the request path. By sending only the new part of the conversation, threads can reduce that repeated work. Anthropic's reported 35% reduction applies to the typical wait on requests of 500,000 to one million tokens, not every request and not every way you might measure end-to-end task time.
That distinction matters for product teams. An agent's total completion time includes Claude's response time, tool execution, network delays, retries, and your application logic. If tool calls or slow downstream services dominate the workflow, a faster start from Claude may not change what users experience much. Measure the full task, not just one slice of the API timeline.
Threads do not reduce token charges
Anthropic says prices and rate limits are unchanged. Claude still reads the full conversation on each turn, so threads should not be treated as a way to cut processing tokens or lower the model bill for a long session.
Anthropic also reduced cache prices by 75% in September, according to the source announcement. That's a separate change, not a benefit delivered by message threads. If cost is your main concern, look at your actual usage, prompt caching, model choice, and how much context each task truly needs. Don't assume "less client data" automatically means "fewer billed tokens."
Threads do not eliminate the need to manage context
A long conversation can include old tool output, superseded plans, and details that no longer matter. Threads don't automatically decide what should stay in context, get summarized, or be removed. Anthropic's description says Claude continues to read the full conversation on each turn.
If your agent builds extensive history, you still need to decide what's useful. Keep durable facts and decisions in application state when appropriate, and don't treat every intermediate tool result as something that must live forever in the active conversation. The right approach depends on the task: for debugging, exact command output may matter; for exploratory steps, retaining everything indefinitely usually doesn't.
Availability is broad, but beta status matters
Anthropic says the beta works across Claude models and is available through Anthropic's platform and through AWS, Microsoft Foundry, and Google Cloud. That makes it relevant to teams with different hosting setups. Still, beta software means you should test it in your own deployment with your own request patterns and operational constraints.
Because the feature is in beta, plan around observable behavior and keep a fallback. Confirm how your client creates threads, continues them, handles expiration, and responds to failures. Before rolling out more broadly, make sure your application can continue using its own stored transcript if a thread isn't available. A latency improvement is nice - but turning a session mechanism into a single point of failure is a bad trade.
What should developers consider before adopting threads?
Start with the bottleneck you're trying to fix. If long sessions are making the wait before Claude begins answering noticeably worse, threads are a reasonable beta feature to test. If your bigger problem is model cost, threads won't directly solve it. And if users are mostly waiting on slow tool calls, reducing repeated conversation transmission may have limited impact on the overall experience.
A practical evaluation should compare the current request flow with a threaded version on workloads that match reality. Include both short and long sessions, and measure several outcomes:
- Time to first response: How long does the user wait before Claude starts answering?
- End-to-end task time: How long does it take the agent to complete the full job, including tools and retries?
- Application overhead: How much time and data are spent building and sending requests?
- Reliability: Can the agent resume if a process restarts or a thread expires?
- Cost: Do the model's actual token usage and charges change? Don't assume savings from smaller client requests.
Use workloads that reflect your real traffic, not just one large synthetic prompt. A coding agent that makes many calls inside one session behaves differently from a customer-support assistant that answers in one or two turns. Test the patterns that drive your own latency and reliability needs.
Plan around the five-minute expiration window
Threads expire five minutes after the last request. That short window makes them good for keeping continuity during an active sequence, but not for long-term session storage. If a user steps away, a process runs long, or an external tool takes too long, the thread may expire before the agent can continue.
Your application should therefore persist the transcript and whatever state you need to reconstruct the interaction. Decide what happens after expiration: start a new thread from the stored conversation, summarize and restart, or ask the user to resume. The best choice depends on whether exact continuity matters and how expensive it is to rebuild context.
Check data-retention and compliance requirements
Anthropic says threads are not eligible for its zero data retention or HIPAA health-data setups. That's a major limitation if your compliance requirements depend on either configuration. Even though threads are encrypted and held in memory, that eligibility restriction still applies.
Before enabling threads for sensitive workflows, confirm that the feature's data handling fits your organization's policies and contractual obligations. Don't treat compliance as something you revisit only after you see performance numbers. For regulated workloads, compliance constraints may rule out threads even if the latency benefits look tempting. In that case, stick with an eligible configuration rather than trying to route around a product limitation.
A simple adoption rule
Threads are worth piloting when all three conditions are true: your agent makes repeated calls in a long session, request preparation or transmission is a meaningful source of delay, and your application can retain its own conversation state. If any one of those is missing, the upside may be smaller than you expect.
Treat the beta as an optimization you can validate, not a redesign of your agent architecture. Keep a conventional path where it makes sense, log when threads are created and resumed, and monitor expiration and recovery behavior. That way, you can get the benefit of faster long-session requests without asking threads to do the persistence and compliance work they weren't designed for.
Conclusion
Anthropic message threads target a specific source of friction in long-running agent sessions: repeatedly sending the same conversation history with every request. The agent provides the conversation once, then continues with new messages and Claude's previous reply ID. Anthropic reports a roughly 35% reduction in the typical time before Claude starts answering for requests between 500,000 and one million tokens.
The limitations matter just as much. Threads don't reduce Claude's context processing, model token prices, or rate limits. They expire after five minutes, require you to store your own conversation history, and aren't eligible for zero data retention or HIPAA setups.
If your agent makes many calls over a large conversation, test the beta against real workloads and track end-to-end outcomes. Use it when reduced request overhead fixes a demonstrated latency problem - and keep persistence, cost control, and compliance squarely in your own application's hands.