Claude's Messages API is stateless: each request must include the full message history, and the response is one new assistant turn that you append and store. There is no server-side conversation object to leak, expire unexpectedly, or drift out of sync with your database. Your application owns the state — which means you need a deliberate design for storing it, budgeting it, and retiring it.
Own the conversation store
Keep one append-only record per conversation in your own database: every user turn, every assistant turn, and — this part trips teams up — assistant turns stored exactly as received, including thinking blocks. Modifying, reordering, or filtering thinking blocks in the latest assistant message before resending returns a 400 error, so the store must be byte-faithful, not a cleaned-up transcript. (If you later switch models mid-conversation, strip thinking blocks from prior turns at that point — other models ignore them but they still cost input tokens.) An append-only store also gives you replay for debugging and a natural audit trail for free.
Track the token budget, don't guess it
Every turn grows the input. Two tools keep this observable. First, each response's usage block reports exactly what you were billed. Second, the free count_tokens endpoint accepts the same payload as message creation and returns an estimated input count before you send — with its own generous rate limits (2,000–8,000 requests per minute depending on usage tier), so calling it per turn is realistic. Counts are model-specific — Opus 4.7+, Fable 5, and Sonnet 5 use a newer tokenizer that produces roughly 30% more tokens than earlier models for the same text — so recount when you change models rather than reusing cached numbers. Set a per-conversation input threshold in your app and act (trim or compact) when a count crosses it, instead of discovering the limit as a failed request.
Compaction: shrinking history without losing the thread
When conversations run long, two server-side mechanisms manage context. Compaction (beta header compact-2026-01-12) summarizes older content once input crosses a trigger you set (default 150,000 tokens, minimum 50,000); the response includes a compaction block, and on the next request the API automatically drops everything before it — your stored history stays complete, only the prompt shrinks. Context editing (beta header context-management-2025-06-27) instead clears old tool results server-side before the prompt reaches the model. Both are beta on all five platforms, so this pattern ports everywhere; for cache economics, put a cache_control marker on compaction blocks and cache the system prompt separately so a new compaction does not invalidate the whole prefix.
Caching the growing prefix
A multi-turn conversation is the textbook prompt-caching case: every request repeats the previous request as its prefix. The simplest correct setup is automatic caching — a single top-level cache_control that auto-places the breakpoint on the last cacheable block and moves it forward as the conversation grows, with cache reads billed at one-tenth the input price. The default TTL is 5 minutes (a 1-hour TTL costs a 2x write instead of 1.25x), which conveniently matches typical chat pacing. One availability note: automatic caching is not supported on Bedrock or Vertex AI — there you place explicit breakpoints yourself and advance them as turns accumulate.
Session expiry is your policy
Since nothing expires server-side, expiry is a product decision you implement: a conversation idle past your threshold gets summarized into a compact "previous context" note (a good judgment task for a small model), archived per your retention policy, and resumed as a fresh conversation seeded with that summary. Tie retention to your governance rules — see retention and deletion — and remember that "delete the conversation" is entirely within your power precisely because the API never held it.
Where to go next
Multi-turn conversation basics covers message anatomy; context compaction and conversational memory go deeper on long-conversation strategy. The quickstart gets you to a first call.