Step fifty pays for everything in the first forty-nine, plus the new turn.
<p><b>Key facts.</b></p>
<ul>
<li>Cost grows with the history carried, not the work done: because the agent re-sends the whole conversation every step, total spend scales roughly with the number of tokens times the number of calls (Philip Zeyliger, <a href="https://blog.exe.dev/" target="_blank" rel="noopener">Expensively Quadratic</a>, 2026).</li>
<li>In one real coding-agent conversation totaling about $12.93, re-reading the cached context reached 87% of the total cost by the end, and was already half the cost at 27,500 tokens (Expensively Quadratic, 2026).</li>
<li>Caching helps but does not remove the curve: a cache read costs about a tenth of a fresh input token (for example $0.30 versus $3.00 per million on Claude Sonnet), yet on long runs those cheap re-reads still dominate the bill (Anthropic prompt-caching documentation, 2026).</li>
</ul>
<h2>Why does cost grow faster than the work?</h2><p>Because an LLM has no memory between calls, so the agent re-sends the entire conversation on every single step. Step one pays for a small context. Step fifty pays for everything in the first forty-nine, plus the new turn. Add a step and you pay to re-read the whole history again. Philip Zeyliger called this Expensively Quadratic: cost tracks the number of tokens times the number of calls, not the size of the task. In one real coding-agent conversation totaling about $12.93, re-reading the cached context reached 87% of the total cost by the end, and was already half the cost at 27,500 tokens.</p>
<p>Because an LLM has no memory between calls, so the agent re-sends the entire conversation on every single step. Step one pays for a small context. Step fifty pays for everything that happened in the first forty-nine, plus the new turn. Add a step and you do not pay for that step alone, you pay to re-read the whole history again. The result, as the Expensively Quadratic analysis puts it, is that cost tracks the number of tokens times the number of calls, not the size of the task. A ten-step task and a hundred-step task on the same problem are not ten times apart in cost. The longer run re-reads a bigger history more times, and the bill curves upward.</p>
<h2>Why does prompt caching change the math?</h2>
<p>Because re-reading the same prefix is the expensive part, and caching makes that part cheap. On Claude Sonnet a cached read costs about $0.30 per million tokens against $3.00 for fresh input, roughly a 90% saving, with a small premium to write the cache. That turns a punishing curve into a manageable one. It does not flatten it. The Expensively Quadratic data shows cache reads themselves becoming the dominant cost by around 50,000 tokens, reaching 87% of the total in one example. Caching changes the slope, not the shape.</p>
<div class="fig"><img src="/blog/article20-diagram.png" alt="A rising cost curve plotted against number of steps, climbing gently at first then steepening, with a lower flatter curve beneath it labelled as the same run with caching and pruning"/></div>
<h2>So what actually drives the bill on a long run?</h2>
<p>Two things, and which one wins shifts as the run grows. Early on, raw context size dominates: every step re-reads a growing history. Past a point, the number of calls takes over. For conversations over about 100,000 tokens, cost is driven more by how many times you call the model than by the raw token count. So the expensive agent is rarely the one with a clever prompt. It is the one that loops many times over a fat, ever-growing context, paying to re-read it on each pass.</p>
<h2>How do you keep a long agent affordable?</h2>
<table style="width:100%;border-collapse:collapse;margin:1.5rem 0;font-size:0.97rem;"><tr><th style="text-align:left;padding:10px 12px;border-bottom:2px solid #e5e7eb;color:#5E6AD2;font-weight:600;">Lever</th><th style="text-align:left;padding:10px 12px;border-bottom:2px solid #e5e7eb;color:#5E6AD2;font-weight:600;">What it does</th></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Cache the stable prefix</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Cuts re-read cost roughly 10x; the single biggest win on long runs</td></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Prune the context</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Drop old tool outputs and dead reasoning so the history stops growing</td></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Summarize and compact</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Replace a long transcript with a short running summary on a schedule</td></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Cut the number of calls</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Fewer, larger steps beat many tiny ones once context is large</td></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Cap the working window</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Keep the prompt under a budget so cost cannot run away</td></tr>
<tr><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Offload to external state</td><td style="padding:10px 12px;border-bottom:1px solid #eee;vertical-align:top;">Store facts outside the prompt and re-inject only what the step needs</td></tr>
</table>
<p>Cache the stable prefix first; that is the single biggest lever, cutting re-read cost roughly tenfold. Then prune: drop old tool outputs and dead reasoning so the history stops growing. Summarize and compact on a schedule, replacing a long transcript with a short running summary. Cut the number of calls; fewer, larger steps beat many tiny ones once context is large. Cap the working window so cost cannot run away. VibeModel builds the layer that controls what context the agent carries and how often it pays to re-read it, which is the Pattern Intelligence Layer.</p>
<h2>Frequently asked questions</h2>
Is the cost really quadratic?
Close enough to feel like it. It is not strictly the square of the tokens; it scales as tokens times calls, because each of the growing steps re-reads the growing history. On a long run that produces the same upward curve you would expect from quadratic growth.
Doesn't a bigger context window help?
No, it makes it worse. A bigger window lets the history grow larger before anything forces you to trim, so each step re-reads more tokens. The fix is to carry less context, not to have room to carry more.
Will prompt caching solve it on its own?
It is the biggest single lever, cutting re-read cost about tenfold, but cache reads still become the dominant cost on long runs. Pair caching with pruning and summarization so the cached prefix itself does not grow without bound.
Where do I look first to cut agent cost?
Cache the stable prefix, then measure how the context grows per step. If it keeps climbing, add pruning and periodic summarization. If you have many short calls over a large context, consolidate them into fewer larger steps.