A single model call is cheap. You can watch one happen and feel reassured about the bill. Then you let an agent loop on a real task, look at the invoice a week later, and the number is nothing like "cheap call times a few." The instinct is to blame the model, or assume something is broken. Usually nothing is broken. The cost grew the way agent loops always grow, and the shape of that growth is worth understanding before you try to control it.
The short version: agent token cost loops are not linear in the number of turns, they are closer to quadratic. A ten-turn session does not cost ten times a one-turn call. It costs much more, and the reason is structural, not a bug.
Every turn re-sends the past
An agent works in a loop. It thinks, calls a tool, reads the result, thinks again, calls another tool. To reason on any given turn, the model needs to see what has happened so far, so the runtime re-sends the whole conversation up to that point: the system prompt, the task, every prior step, every tool result, every partial conclusion.
That re-sending is the whole story. Turn one sends a little. Turn two sends turn one again, plus the new step. Turn ten sends turns one through nine again, plus turn ten. The input to each turn grows with the number of turns that came before it.
Add those inputs across the session and you are summing 1 + 2 + 3 and so on. For ten turns that is 55 units of input, not 10. The multi-turn token growth tracks the square of the turn count rather than the count itself. Public analyses put a ten-turn agent session on the order of fifty times the cost of a single call. Treat that as an order-of-magnitude figure and verify current rates against your own provider, but the shape holds regardless of the exact number.
Why this bites coding agents hardest
Coding agents are long-loop by nature. Read the files, run the tests, read the failures, edit, run again, read again. Twenty or thirty turns for one non-trivial change is ordinary, not pathological. So the turn count that gets squared is already high.
Then the agent conversation history is heavy. The things a coding agent re-sends are not short chat messages, they are file contents, full test output, stack traces, diffs. Each of those rides along on every subsequent turn until something trims it. Many turns, and a fat history on each turn, are two multipliers that stack.
There is a third multiplier hiding underneath. Output tokens are the expensive half of the bill, usually several times the price of input per token, and every turn produces fresh output. The loop length and the reason output tokens dominate your bill compound each other.
What it looks like on the invoice
This is why a change that looks small can cost more than you expected. The diff was three lines, but the agent took twelve turns to arrive at those three lines, and it re-read the same files on most of them. When you see a task described as roughly 200k input and 30k output tokens, that is not one call. It is a total, spread across a loop, and most of that input is history re-sent rather than anything new. The token math and the loop are the same phenomenon viewed from two angles.
Curbing it without starving the agent
Three levers, roughly in order of leverage.
Cache the stable prefix. The system prompt, the conventions, and the parts of the context that do not change repeat on every single turn. Prompt caching charges those repeated tokens at a steep discount, often around a tenth of the normal input rate. For a loop that re-sends the same prefix a dozen times, this is the single largest saving available, and it costs you nothing in quality. The full case is in prompt caching for repo-grounded agents.
Trim the history. Not every past turn needs to travel forward word for word. Stale tool output, superseded attempts, and long results the model has already digested can be summarized or dropped. The skill is cutting what the model no longer needs while keeping what it does, and getting that wrong is its own cost, covered below.
Take fewer turns. Loop count is the term that gets squared, so reducing it is the highest-order fix. A better plan up front, the right context before the first turn, and clear stopping conditions all shrink the number of round trips. This is where grounding pays off twice: an agent that starts with the right slice of the codebase guesses less and loops less.
The honest limitation
You cannot cache or trim your way out of a genuinely hard task. Some changes legitimately need many turns, and the goal is never to starve the agent of context it actually requires. That trade buys a smaller bill and a wrong answer, which is the most expensive outcome of all. Caching only helps when the prefix is genuinely stable, so a context that reshuffles every turn defeats it. Trimming only helps until you cut something load-bearing, at which point the agent loops more to recover what you removed, and you are back where you started with extra steps.
So treat these as ways to stop paying for waste, not as a way to make a long task short. The durable fix is fewer, better-grounded turns, and that is a design decision made before the loop starts, not a dial you turn during it.
Where this leaves you
Agent economics are dominated by a single fact: the loop re-sends its past, so cost grows faster than turn count. Once you see that, the optimizations stop feeling like a grab bag and start to line up, cache the repeated prefix, trim the dead weight, and above all take fewer turns.
This is one reason grounding matters so much to us at Loopsfinity. An agent that begins a task with the right context tends to reach the answer in fewer turns, and fewer turns is the cheapest optimization there is. How we keep each session scoped is our own work, but the underlying economics are not proprietary, and they apply to anything you build on a loop. For the full picture, start with what an AI coding agent actually costs per feature and the broader economics of AI coding agents.