In a multi-turn conversation, when should you reset history, carry full state, or summarize?

Three options sit on the table when you design a multi-turn chat: keep everything, keep nothing past a reset point, or compress old turns into a summary. Each one trades off differently. Keeping everything is the simplest. It works well when the next turn genuinely depends on earlier ones, like a code edit thread or a step by step plan. The cost is tokens, which grow every turn, and attention, which gets diluted across noise. Resetting clears the slate. It works best when the user changes topic, because old turns become noise that competes with the new question. Summarizing compresses old turns into a short paragraph and keeps that paragraph in context, which is what you reach for when the chat has run for a long time but the gist still matters. The practical rule: pick based on what the next turn actually needs, not on turn count.

Multi-turn chat needs an explicit strategy for history, not a default. The three real strategies are reset, carry full, and summarize, and each one is right for a different regime. Reset when the topic shifts substantively. Old turns are now noise: they compete for attention and burn tokens without contributing to the answer. A good heuristic is to detect topic change with a lightweight classifier or a salience score and flush before the next prompt. Carry full when each turn genuinely depends on prior ones. Code editing sessions, multi-step reasoning over a shared artifact, and back and forth debugging all fall here. The cost is real but the value is real too. Summarize when history is long but the gist matters. Long support sessions, multi-day project threads, ongoing onboarding flows. Practical thresholds people use: more than around 20 turns, more than around 8k tokens, or whenever the conversation is about to bump the context window. The summary itself is a prompt-engineering artifact, with its own template and quality bar.