The Messages API is stateless: every request carries the system prompt plus the full list of user and assistant turns, and Claude sees only what you send. A "conversation" is therefore something your application constructs, request by request. Done naively — append every turn forever — you get three predictable problems: costs that grow with every exchange, context windows that eventually fill, and instructions that compete with an ever-larger pile of history. Done deliberately, multi-turn design is a set of decisions about state, and the same decisions apply on Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS.
The system prompt is your only fixed point — keep it stable and cached
Because everything else in the request grows and shifts, the system prompt is the one component you fully control on every turn. Two rules follow. First, put the durable behavior there — role, scope, format, refusal rules — so it is re-asserted on every single request rather than stated once in turn one and buried by turn thirty. Second, keep it byte-identical across requests and mark it with "cache_control": {"type": "ephemeral"}. Prompt caching bills cache reads at one-tenth of the base input price (writes cost 1.25x for the default five-minute lifetime, 2x for one hour), so a stable cached system prompt makes the fixed cost of every turn cheap. The classic mistake is a timestamp or per-session ID interpolated into the system prompt — caching is a strict prefix match, so a single changed byte invalidates everything after it.
Cache the history too. The cache hierarchy runs tools → system → messages, and changes only invalidate from the change point onward — which fits conversations perfectly, since each turn appends to the end. A single top-level cache_control can even place the breakpoint automatically on the last cacheable block and move it forward as the conversation grows.
Re-inject state; don't hope the model retrieves it
Facts established early in a long session — the customer's plan tier, the chosen configuration, the constraint from turn three — are technically "in context" but compete with everything else for attention. Production systems maintain a small, explicit state block instead: a structured summary of decisions and facts so far, re-injected near the end of the conversation each turn (for instance in a tagged section of the latest user message). Anthropic's long-context guidance points the same direction — placement matters, and material near the query carries more weight. Keep the state block append-only where possible; rewriting earlier message content breaks the cache prefix for everything after it.
When history outgrows the window, prune or summarize — deliberately
Three API-level mechanisms exist for long sessions, and they compose:
| Mechanism | What it does | Status |
|---|---|---|
| Context editing | Server-side clearing of old tool results (and thinking blocks) past a token trigger; your client keeps its full history unchanged | Beta (context-management-2025-06-27) |
| Compaction | Server-side summarization near the context limit; returns a compaction block that replaces older content on subsequent requests, with optional custom instructions | Beta (compact-2026-01-12) |
| Memory tool | Claude reads/writes files under /memories via your handler — state that survives across sessions, not just turns | GA on the Messages API |
Anthropic's docs note these pair naturally: context editing for pruning within a session, compaction for summarizing very long sessions, and the memory tool for persistence beyond one conversation. If you summarize client-side instead, apply the same caching care the compaction docs recommend — cache the system prompt separately, and put a cache breakpoint on the summary so a new summarization doesn't wipe your whole prefix. Since these mechanisms are beta or feature-gated, check availability on your specific platform before designing around them; plain client-side truncation-plus-summary works everywhere.
Watch for drift, and test at depth
Behavioral drift — the assistant slowly abandoning its format or tone deep into a session — usually traces to instructions stated once instead of structurally re-asserted, or to accumulated history teaching by bad example (every sloppy turn you replay is a demonstration). The fixes above address both, but only testing proves it: evaluate your assistant at turn 20 and turn 50, not just turn 2, and check the same criteria you used at the start. One mechanical detail for current models: thinking blocks in prior assistant turns must be passed back exactly as received — modifying or filtering them returns a 400 error — and should be stripped only when switching models mid-conversation.
Where to go next
The layering logic behind this article is covered in instruction hierarchy, the cost math in prompt caching costs, and the window itself in context windows explained.