Every prior lesson in this course has treated a tool call as a discrete event with its own cost: a schema costs input tokens (lesson 2), a crowded catalogue costs selection accuracy (lesson 7), an oversized library costs a flat per-turn tax that tool search exists to shrink (lesson 19). What none of those lessons priced is the loop itself — the fact that a tool-using agent doesn't make one API call, it makes a sequence of them, and each call in that sequence is stateless. The API does not remember turn 3 when it processes turn 4; your code resends everything — system prompt, tool definitions, and the full message history accumulated so far — as input tokens on every single request.
That resending is where a tool-heavy loop's real cost hides. A task that takes ten tool calls to finish is not paying for ten tool calls' worth of new information; it is paying to re-transmit turns one through nine, in full, nine separate times, before turn ten ever adds anything new. The arithmetic of that compounds faster than most teams' mental model of "cost scales with turns" expects, and the same growing transcript that inflates the bill also inflates latency, because the model has to read through everything already resent before it can produce a single new token.
This lesson builds the actual arithmetic: why an N-turn loop pays close to quadratic input cost, why the schema tax from lesson 19 multiplies across every one of those turns, what prompt caching does and does not fix about that shape, how a turn's latency budget breaks into pieces that need separate diagnosis, and why the metric that should drive an agent's budget review is cost per completed task, not cost per token.