Someone on r/ClaudeAI summed the whole launch up in five words: "5 minutes ttl is such BS."
That was one of the top comments under Anthropic's message threads announcement, posted hours after it went live.
The feature itself is clean. You send the conversation once. Every turn after that sends only the new message plus a previous_message_id.
Anthropic says median time to first token drops about 35% on requests between 500k and 1M tokens.
And the API throws your thread away 5 minutes after the last request.
I read that comment and thought, yeah, that is the story. Not the latency win. The timer.
Because the numbers are real. This shipped on by default for most Claude Code users, so it is already running under thousands of them right now.
Payloads in long sessions drop from around 800 KB to under 2 KB. That is not marketing math.
But the expiry window is where the excitement hits the pavement. And almost nobody writing about this led with it.
Here's what i mean.
The headline everyone repeats is the 35% faster first token. The number almost nobody repeats is that your bill does not move.
Straight from the docs:
Claude still reads the full conversation on every turn, so token usage stays the same.
So message threads are a latency feature. Not a cost feature. If you want a cheaper bill, you still need prompt caching with breakpoints placed by hand.
That is fine. But the framing matters.
Half the posts i read treated this as a way to cut long context spend. It isn't. It just stops you from up 800 KB of JSON every few seconds.
Here's a question people always ask. What happens if my tool call takes longer than the thread lives?
You replay the whole thing. Full conversation, new create request, new thread id.
One developer in that Reddit thread ran this on a 600k context loop and saw about 30% better TTFT, close to Anthropic's claim.
But their tool calls sometimes stalled 3 to 4 minutes waiting on slow endpoints. Add a human approval click and the window is gone.
Another developer called the idle TTL the edge case to watch. Their words, more or less.
A multi repo test suite or a database migration will blow through 5 minutes and you silently pay the full re upload again.
One commenter pointed out the 5 minute window lines up with the default prompt cache TTL. Slow tool calls were already paying for a cold read. Nothing changed there.
That is a fair defense.
But a fair defense is not a feature.
| Claude threads | OpenAI Responses | |
|---|---|---|
| Resume by | previous_message_id |
previous_response_id |
| Stored for | 5 min idle | 30 days default |
| Written to disk | No | Yes |
| Works with ZDR | Unclear | Forced off |
Two commenters asked the obvious thing. Isn't this just OpenAI's Responses API a year later?
Partly. The shape is the same. The retention is not.
OpenAI keeps response objects 30 days by default and lets you turn storage off. Anthropic keeps your thread encrypted in memory, writes nothing to disk, and deletes it 5 minutes after the last request.
That is a real difference in how the two companies think about holding your data. Make of it what you will.
And if your team requires zero data retention, one commenter said this whole feature means very little to you.
Most tutorials tell you to add the thread param and go. Then you hit thread_fingerprint_mismatch and lose an afternoon.
Threads split fields into three buckets:
system and tools. Send either on a continue request, even as null, and you get a 400.
Want to change the system prompt mid conversation? Start a new thread. There is no edit.
A thread is append only, and each response id can be continued exactly once.
I like this constraint. It is honest about what a thread is. But it will surprise anyone who treats it like a chat object they can mutate.
The first time i read "your application stays the source of truth," i skimmed past it. Then i thought about what it means at 3am.
It means no response, create or continue, tells you whether the API stored that turn.
You find out on the next request, when you get a 404 with thread_not_found. And the error does not say why.
Expired. Not stored. Written by a fallback model.
Different workspace. Different service account.
So you keep every message yourself and you build the replay path on day one. Not later.
The SDK helper handles it, but only while the helper object is alive. It holds the conversation in memory and saves it nowhere else.
Restart your process and that history is gone.
Now the part that has nothing to do with any of this.
I spent two hours in Anthropic's docs one evening trying to work out why my cache breakpoints kept failing. Read the whole page. Took notes.
Felt smart. Then found a single line in a table saying a threaded request can carry at most 4 breakpoints. The top level one counts as one of them.
Four. That was it. That was the bug.
I have done this maybe a dozen times now. The answer is always in a table I scrolled past.
My coworker keeps a folder of screenshots of docs he almost missed. He calls it his graveyard. It is 300 images deep and every one of them saved him a day.
There is something humbling about paying for speed with a footnote.
Most people don't need this.
If your agent runs 5 turns and then stops, the thread never expires and never saves you anything worth measuring.
If you are under 100k tokens of context, the upload was not your bottleneck. Your model choice was.
And if a human has to approve steps, the 5 minute window is working against you. You will replay constantly and feel like the feature is broken.
It isn't. It was built for tight machine loops, not for people thinking.
The honest read is that this is infrastructure for coding agents and computer use loops. Screenshots stay on the server instead of getting re uploaded every turn.
That is the real win, and it is a good one.
For everyone else, plain prompt caching still does the job. I keep coming back to that Reddit commenter who said they would not be surprised if the cache actually lives longer than 5 minutes and Anthropic just doesn't hand it to you.
I don't think that's true. But i understand the instinct.
When a feature saves you time and costs you nothing, you start asking where the catch is. Here the catch is written in the docs in plain text, and it is a clock.
Five minutes is enough for a machine. It is not enough for a person who stepped away to get coffee.
Maybe that is the point. Maybe the API is telling us who it was built for.