Prompt caching is one of those cost-saving levers that gets mentioned in passing but rarely gets the attention it deserves, largely because people assume it mainly benefits repeated identical requests, like re-running the exact same prompt twice. In practice its biggest win comes from something subtler: caching the static, unchanging portion of a system prompt so that only the genuinely variable part of a request has to be reprocessed fresh every time. Most production system prompts are large by necessity. They carry tool definitions, formatting rules, safety instructions, style guidelines, and long-form context that rarely changes between one user request and the next. If that entire block sits at the top of every single API call unchanged, and the API supports prompt caching, the provider only needs to process it once and can reuse the cached representation for a long stretch of follow-up requests, cutting both latency and token cost substantially. The catch is that caching is order-sensitive: anything that appears before the first point of variation in the prompt breaks the cache the moment it changes. A common mistake is interleaving static instructions with small per-request variables, like a user's name or today's date, near the top of the prompt. Even a single-character difference there invalidates the entire cached block that follows it. The fix is a straightforward reordering discipline: put every static, reusable instruction first, keep it byte-for-byte identical across calls, and push all per-request variables, like specific user input or dynamic context, to the very end of the prompt. Done consistently, this turns a large system prompt from a recurring cost center into something you effectively pay for once per session rather than once per call.