要点
- Claude Platform announced Message Threads in public beta: agents need not resend full conversation history each turn—only what is new since the last turn—to cut time to first token (TTFT) on long sessions.
- On by default for most Claude Code users; for requests with 500k to 1M tokens, median TTFT drops about 35%. Usage: add a `thread` parameter; first request sends the full conversation to start a thread; later requests send new messages plus the prior response ID.
- Threads are held in memory between turns, encrypted and not written to disk; they expire 5 minutes after the last request, then the client resends the full conversation. Claude still reads the full conversation each turn, so token usage and standard rates/limits stay the same; available on native Claude Platform plus AWS, Microsoft Foundry, and Google Cloud (Anthropic managed).
Message Threads targets transport and queueing friction for long-running agents: a coding agent may run hundreds of turns, and resending hundreds of thousands of history tokens each time delays the moment the model starts responding. It is not context compression and not a price cut.
Falsifiable read: if independent measurements under 500k–1M context and comparable networks miss the ~35% median TTFT drop, or production gains are erased by frequent full resends after 5-minute expiry, treat 2 Nov 2026 mainly as a platform transport note—not a change in long-agent cost structure; if latency gains reproduce on the stated multi-cloud default paths, raise the weight of protocol-level slimming as agent infrastructure.
[1]Hard facts from the Claude article (published 2 Nov 2026): public beta; suited to long-running coding agents, computer-use agents (screenshots stay on the thread), and document/image-heavy workflows. The server holds thread state between turns; clients continue with the prior response ID.
Stated boundary: while each request is smaller, Claude still reads the full conversation every turn, so token usage stays the same; standard Claude token rates and existing rate limits apply.
[1]Evidence is vendor product copy plus one internal latency stat (~35% median TTFT on 500k–1M). No measurement harness, sample size, P95/P99, control baseline, or open reproduction script is attached.
Steelman: for tool-loop agents that accumulate context, TTFT is a real UX and throughput bottleneck; keeping history in an encrypted in-memory thread and uploading only deltas is a more direct systems fix than changing the model. Beyond the steelman, 5-minute expiry kicks long-pause workflows back to full resend; “still reads full” means the bill and context-window pressure remain—the win is the wire, not intelligence or price.
[1]Strongest steelman: if the ~35% TTFT cut reproduces on Claude Code’s default path, long-session agent interactivity steps up—especially screenshot-heavy computer use.
Steelman risk: beta scope and multi-cloud consistency details are thin; failure/migration semantics for in-memory threads are undeveloped; developers who misread this as “saves tokens” will break cost models.
[1]For agent builders, a latency tool—not a pricing tool; for platform competition, long-context products are starting to compete on protocol and session state, not only window size. For buyers, capacity planning should still assume full-token reads; book TTFT gains as an experience line item.
[1]Near term, test with external TTFT reruns and real pause/resume workflows: if 35% holds only on ideal links, or 5-minute expiry eats the gains, file it as a conditional transport optimization; if multi-cloud default paths deliver stably, Message Threads becomes one of the standard session primitives for long-running agents.
【No.2】
[1]