Almost everyone budgets AI the same wrong way. They look at the price of one call - a few cents, maybe a fraction of one - multiply by how many times they expect to run it, and conclude the whole thing is cheap. Then the monthly bill arrives an order of magnitude higher than the estimate, and nobody can point to where it went. The math was not wrong. The model of how an agent spends money was wrong.
Here is the part that does not fit on a pricing page: a single agent task is not one call. An agent that uses tools - reading a file, calling an API, checking its own work - runs a loop. Think, act, read the result, think again. And the expensive, invisible detail is what happens to the context on every turn of that loop.
Why the loop multiplies, and the prompt does not
When an agent takes a step, the model does not remember the previous steps for free. In a full-history loop, the retained instructions, tool calls and results are sent again on the next step. Caching, compaction and different architectures change the billed amount; inspect actual provider usage. Step two re-pays for step one. Step three re-pays for steps one and two. The context grows, and you are billed for the whole accumulated pile, every single turn.
So a task you priced as "one call" can quietly become fifteen or twenty calls, each one larger than the last. The first prompt is the cheapest moment in the entire run. The cost lives in the tail - and the tail is exactly the part nobody estimated.
The contrarian version, stated plainly: optimizing your prompt to be shorter is the lowest-leverage cost move there is. The prompt is a one-time entry fee. The bill is set by how many times the agent loops and how much context it drags through each loop. You are tuning the cheap thing.
Where the real money actually leaks
- Retries on failure. A tool errors, the agent does not understand why, and it tries again - with the failed attempt now added to the context it re-pays for. A flaky integration is not a reliability problem with a cost footnote. It is a cost problem.
- The loop that does not know it is stuck. An agent that cannot make progress will often keep going anyway, re-reading the same growing context and producing slight variations of the same step. Nothing crashes. The meter just runs.
- Re-reading large outputs. One tool returns a big blob - a full file, a long API response - and that blob now rides along in the context for every remaining step of the task, paid for again and again.
The one control that actually changes the bill
The fix is not a better prompt and it is not a cheaper model. It is a ceiling on the run, set before the run starts. Three things, in order of impact:
1. Cap the loop. Decide the maximum number of steps a task is allowed to take, and stop it there. Reaching the step limit is a reason to pause and inspect progress. It does not prove that one more step would be useless. The cap converts a runaway into a bounded, knowable cost.
2. Estimate before you execute. The most useful number is the one you get before the money is spent, not after. Knowing the likely cost of a run lets you refuse the expensive ones up front, instead of discovering them on the invoice. Spend recorded after the fact is an autopsy. A pre-run estimate is a decision.
3. Stop re-paying for the same context. Trim what rides along between steps. Large tool outputs do not all need to stay in the context for the rest of the task - summarize or drop them once they are used, so step twelve is not still paying for the giant blob step three read.
The order matters. Most teams reach for the model price or the prompt length because those are the numbers printed on the page. The leverage is in the shape of the loop, which no pricing page shows you - and which is exactly why the bill keeps surprising people who only ever looked at the price of one call.