Multi-turn design and context accumulation

Conversations grow, and how you let them grow determines both cost and coherence.

5 min read · Lesson 10 of 12 in this domain

Because the API is stateless, a multi-turn conversation is simply a message array you keep appending to and resending. That has a consequence people underestimate: every turn re-bills the entire history. A conversation is therefore not free to let sprawl — its cost grows roughly quadratically as it lengthens, since each new turn pays for everything before it. Two levers keep this manageable. Caching makes the repeated prefix cheap, which is why stable content belongs early and volatile content last. And the context-management mechanisms — editing, compaction, memory — control what remains in the array at all. Design the conversation shape deliberately rather than letting it accumulate by default.

• Every request resends the full history, so a long conversation re-bills everything before it on each turn.
• Append the full response.content, not just text — dropping tool_use blocks breaks pairing, and dropping compaction blocks loses compaction state.
• Consecutive same-role messages are allowed and combined; the first message must be user.
• Prompt caching is what makes multi-turn affordable: put stable framing early, the new turn last.
• When history stops being useful, prune it (context editing) rather than carrying it; when it must be kept but compressed, compact it.
• For anything that must survive the session, write it out to memory rather than hoping it stays in the window.

Source: Claude Docs — Prompt engineering · Independent study aid, not affiliated with or endorsed by Anthropic.