1. What changed on November 2
As of November 4, 2026, Anthropic’s November 2 release introduces Message Threads in beta. The first request supplies the conversation; later requests send new messages and the previous response identifier. This changes repeated upload and preprocessing, not the model’s context-window size. The separate November 3 text-watermark announcement is not a conversation-storage feature.
OpenAI applications can already chain Responses with previous_response_id or use a Conversations object. The useful comparison is who owns the record, what a continuation inherits, and how to recover after losing server state. The designs below are editorial engineering recommendations, not results from a production or provider benchmark.
Claude Platform release notes · Claude Message threads · OpenAI conversation state
2. Compare four state contracts
Represent the business conversation, provider continuation pointer and completed actions separately. Your application owns the conversation; a provider ID is an adapter optimization; an execution journal says which tools actually finished. Treating one response ID as all three makes process restarts and provider changes ambiguous.
The table compares state-management contracts, not intelligence or privacy rankings. Check organization controls, model availability and product surface separately. A Messages API message thread is also distinct from a session thread in Claude Managed Agents.
| Approach | Context owner | Continuation and recovery |
|---|---|---|
| Application history | Your full journal | Replay each turn; own trimming and deletion |
| Claude Message Threads | Short-lived server state plus your copy | Five-minute expiry; rebuild on thread_not_found |
| OpenAI previous_response_id | A Responses chain | Repeat instructions; check storage settings |
| OpenAI Conversations | Persistent conversation object | Manage project conversation state and its retention |
3. A minimal two-turn example
The following example uses a synthetic ticket and has no connection to a real order system. Install an official SDK exposing the documented helper, pin that dependency, and configure approved API projects and models. The code illustrates request structure only; it was not executed for this article and sending it incurs API charges.
The Claude helper creates its thread on the first send and adds the beta header. The second send transmits the new message. The OpenAI example repeats instructions because previous_response_id does not inherit the previous response’s top-level instructions. Make that difference explicit in your provider adapter.
# Documentation example only; not executed for this article.
# Use approved API projects and synthetic input. Requests incur API charges.
import os
import anthropic
from openai import OpenAI
rules = "Use only the synthetic fixture and cite its ticket ID."
a = anthropic.Anthropic()
thread = a.beta.messages.thread(
model=os.environ["CLAUDE_MODEL"], max_tokens=256, system=rules
)
thread.send({"role": "user", "content": "SYN-1: delivery is on Friday."})
reply_a = thread.send({"role": "user", "content": "Which day for SYN-1?"})
# Stored-state example: use only where the project's retention policy permits it.
o = OpenAI()
first = o.responses.create(
model=os.environ["OPENAI_MODEL"], instructions=rules,
input="SYN-1: delivery is on Friday.", store=True
)
reply_o = o.responses.create(
model=os.environ["OPENAI_MODEL"], instructions=rules,
previous_response_id=first.id, input="Which day for SYN-1?", store=True
)
Claude Message threads · Anthropic Python SDK thread helper · OpenAI Responses create: instructions
4. Separate transport savings from billing
A thread is not a prompt cache. Claude does not automatically cache a threaded prompt; cache controls still need configuration. OpenAI states that previous input in a response chain remains billable input. Fewer request bytes do not establish free history, a fixed latency improvement or a lower end-to-end bill.
Original arithmetic example: assume an initial upload of 8,000 text units, 700 new units per later turn and 20 turns. Full replay sends 20×8,000 + 700×190 = 293,000 units; incremental upload sends 8,000 + 19×700 = 21,300. This ignores replies and protocol overhead and measures neither billed tokens nor latency. Measure actual UTF-8 bytes, cache reads and writes, retries and cost per accepted task separately.
Claude Message threads · OpenAI conversation state · Claude prompt caching · OpenAI prompt caching
5. Make expiry a normal recovery path
Claude threads are best-effort state. They expire five minutes after the last request, while deletion may occur later, within one hour of last use. Keep a complete application-owned history. The helper’s in-memory transcript is insufficient when a conversation must survive its process.
A successful response does not confirm that the API retained that turn. A later continuation can return thread_not_found; create a new thread from the full history rather than retrying the expired ID. In the proposed recovery flow, reconcile completed business actions before rebuilding model context.
- Journal input and configuration revision
- Acquire one writer and read the latest pointer
- Send new messages with request correlation
- Success: commit the new ID and tool receipts
- Expired: rebuild state from the full journal
- Uncertain: reconcile execution before replay
6. Concurrency, timeouts and tool side effects
Each Claude response ID can be continued once. Parallel workers can encounter thread_already_continued or thread_continue_in_flight; changing a fixed field can cause thread_fingerprint_mismatch. The documented thread-validation errors occur before inference, but that does not establish the execution state of every timeout or arbitrary HTTP 400.
Use a single-writer queue per business conversation and compare-and-swap a database revision before updating its latest pointer. Give external actions their own business idempotency key and durable receipts. After a timeout, reconcile those receipts first: recovering inference does not make sending mail, charging a payment or creating a ticket exactly once.
7. Retention determines the architecture
Claude Message Threads are currently not ZDR eligible: contents remain in encrypted server memory under a server-managed key, are not written to durable storage, and are deleted within the documented bound. In-memory state must not be described as zero retention. OpenAI response state and Conversations require their own data-control review.
Choose an allowed retention model before choosing the state API. For application-managed replay, retain the complete supported response items and tool relationships, not just final text. Tenant authorization and deletion rules must also cover your own conversation journal. A provider’s deletion policy does not delete an application copy.
Claude Message threads · OpenAI API data controls · Claude API data retention
8. Design an evaluation that can fail
Fix a synthetic task set with known answers: short and long exchanges, a tool round, expiry, a worker restart and simultaneous sends. First compare full replay and threads on the same model; only then compare models or providers. Changing several variables at once makes a cheaper outcome hard to attribute.
Record acceptance, total requests, upload bytes, first-token and complete-task latency, token and cache usage, recovery attempts, duplicated actions and gross cost. Include failed tasks in cost accounting. Define acceptance before the pilot: evidence references survive recovery, history remains complete and tools produce no duplicate side effects.
9. Roll out a recoverable adapter
Start with a read-only workflow that actually has long conversations. Keep a full-replay adapter available, pin model and provider configuration per conversation and version that configuration. Create new state when system instructions or tools change instead of silently mutating a short-lived thread.
Review expiry rate, recovery rate, correctness and cost per accepted task together. Small transport gains, frequent recovery or an incompatible retention policy can justify staying with application-owned replay. A chat subscription, model permission and permission to retain API state are separate requirements.