Why does prompt caching change the right ordering of slots in a context layout?

**Prompt caching is prefix matching.** Both Anthropic and OpenAI offer it in 2026, and the contract is the same: the provider hashes the first N tokens of your prompt and reuses already computed key value tensors for any subsequent call that sends the exact same prefix. The practical rule that falls out: order matters more than length. If your prompt is `[system][persona][examples][retrieved chunks][history][user turn]`, then everything up to the first byte that changes is cacheable. Once a single character drifts, no tokens after that point can be reused. So you put the most static slots earliest and the most variable slots latest. What is static? The system prompt, the persona block, the tool schema, stable few shot examples. What is variable? The retrieved chunks for this turn, the running conversation, the user's current question. **The trap** is hiding a per call value inside a slot you thought was static. A timestamp in the system prompt (`"Current time: 2026-06-08T14:23:01Z"`), a request id, today's date, a feature flag that flips per user, a few shot example list that you randomize order on each call. Any of these silently disables the cache from that byte forward. When the design is right, long mostly static prompts get a 5 to 10x reduction in input token cost because cached prefix tokens bill at roughly 10 percent of the normal input rate.

**Prompt caching reshapes context engineering into a layout problem.** The contract, prefix matching against a byte identical key, means the right ordering of slots is no longer just about attention quality (recency, position bias), it is also about whether the cache hits. The ordering principle is **monotone in volatility**. Walk through your slots and rank them by how often each one's contents change across calls. System prompt and tool schema change on deploy. Persona changes per user. Few shot examples change per task variant. Retrieved chunks change per turn. Conversation history changes per turn. The user message changes every call. Lay them out in that order, oldest to newest, lowest volatility first: $$[\text{system}][\text{persona}][\text{schema}][\text{few shot}][\text{retrieved}][\text{history}][\text{user}]$$ The cache hits up to the first byte that differs across calls. If the system through few shot block is identical across users in a session bucket, you cache that whole prefix and pay a small fraction of the normal input rate for those tokens. The trap is subtle because the offending fields look harmless. A `Current date: {today}` line in the system prompt. A `User ID: {uid}` header above the persona. A randomized few shot order chosen freshly each call. Any of these silently moves the cache boundary to byte zero. The cost difference between a 90 percent cache hit rate and a 0 percent cache hit rate on a 30K token prompt is real money and real latency at scale. The operational discipline is to treat the prefix as an immutable contract: per call values live below the cache boundary, in a dedicated developer or user message, never sprinkled into the system block for convenience.