# Claude's API can now hold the conversation for five minutes, cutting long-context latency

> Message threads, in public beta, let agents send only the new turn instead of the whole history. The token bill doesn't change; time to first token does.

- URL: https://devisdead.ai/news/claude-api-message-threads-cut-long-context-latency
- Published: 2026-11-02T19:51:09Z
- Author: DevIsDead Newsroom
- Section: Dev
- Tags: anthropic, claude-api, agents, latency
- Originally reported by Unite.AI (https://www.unite.ai/anthropic-launches-message-threads-beta-for-long-running-agents/).

Long-running agents resend their whole conversation to the model on every turn. Anthropic's message threads, in public beta since November 2, let Messages API clients skip that after the first request, [Unite.AI](https://www.unite.ai/anthropic-launches-message-threads-beta-for-long-running-agents/) reported, in a piece bylined to one of its AI-generated research agents that the outlet says its editors review.

## How it works

The first request, a create, sends everything: the messages, the system prompt, the tools and a thread parameter. The API keeps the conversation and Claude's answer, keyed to the response ID. After that, each continue request carries only the new messages plus the previous response ID, with no system prompt or tools, and every reply hands back a fresh ID for the next turn.

Claude still reads the entire conversation each time, so token usage, pricing and rate limits stay the same. What goes away is re-uploading, validating and tokenizing the history. Anthropic's number comes from Claude Code, where most users already have threads switched on: on requests between 500,000 and 1 million tokens, the median wait for the first token dropped roughly 35%.

## The fine print

- Threads are best-effort, and each one lapses five minutes after its most recent request. Your app remains the source of truth and has to keep every message, so it can replay the full conversation in a new create request.
- Contents sit in encrypted memory, never on disk, and are deleted within an hour of last use. There's no API to list, read or delete them, and threads don't qualify for zero data retention or HIPAA use.
- Prompt caching isn't automatic. You still place breakpoints, up to four per threaded request.
- Each response ID can be continued only once. Changing the system prompt, the tools or other fixed fields means a new thread.
- When streaming, wait for `message_stop` before continuing, or you can get a 404. Turns produced by fallback models aren't stored, so they need a full resend.
- Not supported: Message Batches, token counting, on-demand compaction and most context editing.

The SDK helper takes care of creates, continues and the beta header, and replays the full conversation once on certain continuation errors, though not after a dropped stream.

## Should you use it

If you run agents with huge contexts and latency matters, probably yes, but treat it as an optimization, not as storage. Keep the full-replay path tested, because threads will expire and your code has to cope without anyone noticing. The advice from our piece on [agents that lose a response](/news/your-agent-lost-the-response-do-not-let-it-retry-the-refund) applies here as well: a continue that fails halfway is an unknown outcome and deserves the same care.

**[Scoreboard](/scoreboard) update:** AI +1. Agents get a faster path through million-token conversations.

Stay undead.