Should the system prompt remain identical across all turns of a conversation, or vary per turn?

Keep the system prompt stable across all turns of a conversation. It is the standing-orders block: who the model is, what behavior it should exhibit, what constraints it should respect. That information does not change from turn to turn. Per-turn dynamic data (the current user query, any retrieved context, transient state) belongs in the user message, not the system block. The user message is where the conversation actually changes; the system block is the stable scaffold around it. There are two reasons to keep the system prompt stable. The first is provider caching. Anthropic, OpenAI, and most modern API providers cache stable prompt prefixes. If you keep the system block identical across turns, the provider's cache hits and you pay a fraction of the normal input cost (often 50 to 90 percent savings). The second reason is behavior consistency. A stable system block gives the model consistent standing orders; a varying system block produces inconsistent behavior across turns. The only time to change the system prompt mid-conversation is on a fundamental mode shift, like pivoting from billing support to feature questions. That is a deliberate routing decision, not a per-turn habit.

**Stable system prompts** are the production default for multi-turn conversations. The system block carries standing orders (role, behavior, constraints); the user message carries per-turn dynamic data. Mixing those layers is a common but costly mistake. The first reason for stability is prompt caching. Anthropic's prompt caching, OpenAI's automatic prefix caching, and Gemini's context caching all key on the prefix of the request. If the system block stays identical across turns, the prefix matches and the cache hits. Cached tokens are billed at a fraction of normal input cost (Anthropic at roughly 10 percent of base; OpenAI at 50 percent). Varying the system block per turn invalidates the cache every turn and pays the full input cost on a part of the request that has not changed. The second reason is behavior consistency. The system block is the model's standing instruction set. Changing it every turn produces inconsistent behavior: the model might be terse on turn 3 and verbose on turn 4 because the system block subtly reframed its job. Production conversations rely on consistent behavior, and the cleanest path to that is keeping the system block stable. Per-turn dynamic content (retrieved documents, current user query, transient state, tool results) belongs in the user message. That is where the conversation changes; that is where the cache misses are expected. Putting dynamic content in user messages keeps the system prefix cacheable and keeps behavior consistent. The only valid reason to change the system prompt mid-conversation is a deliberate mode shift. The conversation pivots to a fundamentally different task and the model needs different standing orders. That is a routing decision, not a per-turn habit, and modern conversation designs handle it by starting a new session rather than mutating the existing one.