Your agent bill isn't decided by the model price. It's decided by your repeat rate.

Your agent bill is not determined by the model price alone. It is determined by the rate at which you repeat tasks, and how long the gaps are between repeats. The price you see listed, which is per million tokens, is just a small part of the total bill. The true cost is influenced by how often the same goal repeats, the time gaps between repeats, and the end-to-end cost of each finished task.

An example of this can be seen in a 20-step task on Sonnet 5.5, where re-sending the input resulted in a cost of $2.14 per task without caching, compared to $0.97 per task with an 80% cache rate. For 1,000 tasks a day over 30 days, this translates to $64,200 versus $29,088. The key factor here is not just the number of repeats, but the gaps between them.

A loop that repeats for 12 hours can cost around $318, while ten agents working in such a loop could cost up to $3,180. The structure of the bill is essentially steps multiplied by the re-sent context multiplied by the number of repeats. However, the most significant factor that is often overlooked in budgeting is the loop, or the repeat rate.

A study by Gartner 2026 indicates that agentic AI consumes 5-30 times more tokens per task than a traditional chatbot exchange. Additionally, a Stanford Digital Economy Lab finding shows that identical SWE-bench runs can vary up to 30 times in token cost, due to the stochastic nature of trajectories. The solution to this problem lies in reducing the re-sent context, and this is the focus of the article.

There are three key numbers to consider: the repeat rate, the gap distribution, and the cost per finished task. The repeat rate should be measured on goals, not just prompts, as the same goal can be phrased differently throughout the day. By clustering completed runs by goal and counting clusters with more than one member, you can determine your ceiling for caching.

If goal repeats across sessions are negligible, a trajectory cache may not be necessary. The gap distribution is crucial because a repeat after data changes results in a stale hit, not a saved run. By bucketing requests based on gap length and pricing each bucket separately, you can determine the optimal time dimension for caching.

The cost per finished task is the most accurate measure of cost, as it includes all runs, whether they were successful or not. Prefix caching and trajectory caching both aim to reduce costs, but they target different terms in the bill. Prefix caching reuses the re-sent context and makes each completion cheaper, while trajectory caching replays the recorded plan instead of re-deriving it, leading to faster responses without additional LLM invocations.

The safety of cached writes is also crucial, as a wrong hit can result in incorrect answers, duplicated charges, and unintended state changes. The gating mechanism ensures that only exact repeats trigger a cache write, preventing potential errors.