Stop shortening your prompts. Six agents, 97-99% cache hit rate - and why the standard advice is backwards.

Everyone here has read the same advice. Trim the system prompt. Cut the examples. Every token costs money, so use fewer of them. I followed it for months. Then I turned on prompt caching, and the advice inverted overnight. Here is the thing nobody says out loud: once caching works, a long prompt is cheaper than a short one that keeps changing. Not metaphorically. Arithmetically. The setup I run a publication with six agents and no employees. A CEO agent that assigns work, a TrendScout, a Researcher, a Writer, an SEO agent, a PublishingAgent. They run on heartbeats, around the clock, on a machine in my study. Total API spend last month: about $115 across all six. That number is the point of this post, because it did not start there. My Researcher agent once consumed 5.9 million input tokens across nine API calls. Nine. That is roughly 650,000 tokens per call, and almost all of it was the same text every single time - the instruction manual, the tool definitions, the editorial standards, the anti-fabrication rules. The agent re-read its entire constitution before answering every question, and I paid full price for the reading, every time. The instinct is to shorten the constitution. That instinct is - wrong. What caching actually changes Prompt caching means the provider stores the processed form of a prefix of your prompt. On the next call, if the prefix is byte-identical, you are charged a fraction of the input price for that portion. So the cost of a call splits into two parts that behave completely differently: The stable prefix - instructions, tool definitions, style guides, rules. Cached. Nearly free after the first read. The volatile suffix - the actual task, the current context, today's question. Full price. The moment that split exists, the optimization target stops being length and becomes stability. A 40,000-token prompt that never changes costs less to run than a 4,000-token prompt that gets edited every day, because the second one throws away its cache on every edit and pays full freight on the next call. My hit rate sits between 97 and 99 percent. It cut more cost than every round of prompt-trimming I ever did, combined. And prompt-trimming had a side effect that caching does not: shorter prompts made the agents dumber. Every rule I deleted to save tokens was a rule that had been there for a reason, and I usually rediscovered the reason within a week. Three consequences that surprised me 1. Editing a prompt now has a price. This is the strange one. Before caching, changing a system prompt was free - you edited a file, you saved it, done. After caching, every edit invalidates the cached prefix and the next call pays full price to rebuild it. That is not a reason to avoid editing. It is a reason to batch your edits. I now change agent instructions deliberately, in sessions, rather than tinkering with one line whenever something annoys me. Prompt churn became a visible line item, and seeing it changed my behaviour more than any discipline ever did. 2. Ordering matters more than content. Cache hits require a byte-identical prefix. Which means the single highest-leverage refactor is not deleting text, it is moving it: everything stable goes to the top, everything volatile goes to the bottom, and the boundary between them is where the cache breakpoint lives. If you have a timestamp near the top of your system prompt - and a shocking number of agent frameworks inject one - you are invalidating your entire cache on every call. One line in the wrong position can take your hit rate to zero while everything looks perfectly fine. You are allowed multiple breakpoints. Tool definitions and instructions can be separate cached blocks. Use them. 3. You get throughput, not just money. Cached reads do not count against rate limits the way fresh input tokens do. For an autonomous system that runs on heartbeats, this is arguably worth more than the cost saving. My agents stopped queueing behind each other. The bill went down and the system got faster - which almost never happens in the same change. The part where I ruin my own argument Caching makes bad architecture cheaper to run. It does not make it good. My most expensive night was about fifty dollars, burned by a single agent between midnight and morning. It was not a model failure and it was not a token-efficiency problem. Two lines in that agent's own instructions could never both be true: one told it to verify state before acting, another implied it should act first. The agent did exactly as it was told - both things, alternately, politely, forever. Caching would have made that loop cheaper. It would not have made it stop. And here is the other thing caching does not fix. My agents went six days without publishing anything this month. The bill barely moved. Most of it is: agents waking up, checking state and finding nothing to do - the writing itself is the cheap part. An idle autonomous company costs almost as much as a working one, and it does not complain, so nobody notices. I found out by accident, scrolling past an inbox I had not opened in a week. So here is the order of operations I would give anyone running agents unattended: Hard iteration caps, enforced in code. Not in the prompt. An agent cannot be trusted to count its own turns, because counting turns is a task and the task is what is looping. Read your instructions hunting specifically for contradictions. Not for clarity, not for tone - for pairs of rules that cannot both be satisfied. In my experience most expensive loops are rule conflicts wearing the costume of a reasoning failure. Then cache. Once the thing terminates reliably, make it cheap. Doing this in the reverse order gets you an efficiently priced infinite loop. The one number that matters Go and look at your cache hit rate right now. Not your token count, not your monthly bill - the hit rate. If it is above 95 percent, stop reading advice about shortening prompts; it no longer applies to you. If it is near zero, you almost certainly have something volatile sitting at the top of an otherwise stable prompt, and finding it will take you twenty minutes and save you more than a month of careful editing. The most boring optimization in this field is also the largest one available to most people running agents. It requires no cleverness, no new model, no architectural rewrite. It requires putting the unchanging things first and then leaving them alone. Put the good part first. Then keep your hands off it.