I Measured 23,968 Agent Turns. The Prompt Was 309× the Output.

Across 166 real agent sessions I have run — 23,968 billed turns, $5,816 of actual spend — the agents wrote 27.2 million tokens and read 8.39 billion. That is a ratio of 309 to 1. For every token these agents produced, 309 went back into the model.

That number is the whole story of agent cost, and it is invisible in every pricing page, because pricing pages quote a rate per million tokens and leave you to assume the token count has something to do with the work being done. It mostly does not. It has to do with how many times the conversation gets resent.

I had been treating agent spend as a black box — a number on an invoice that went up when I used it more. This is what came out when I actually looked.

What is being measured here

Every turn an agent takes produces a usage block from the API: how many tokens were sent, how many were read from cache, how many were written to cache, how many the model generated. That is not an estimate. It is the billing record.

Those blocks are sitting in the session transcripts on disk. I parsed every session with 20 or more turns and priced each one at published rates — $5 per million input tokens, $25 per million output, cache writes at 1.25×, cache reads at 0.1×.

Two caveats worth stating up front. This is one engineer's workload — coding and infrastructure tasks, long sessions, heavy file reading — so the absolute numbers are mine; the shape of the curve is a property of how the API works, and that part generalises. And the sessions span four models, priced here at a single Opus-tier rate: 95% of the turns are Opus-tier already, with small tails of a more expensive model and a cheaper one that roughly cancel, so the blended error is on the order of a couple of percent. Nothing below turns on it.

Why does turn 40 cost more than turn 4?

Because the API is stateless. There is no conversation stored on the server that you append to. Every turn resends everything: the system prompt, the tool definitions, every file the agent read, every command output, every error message, all of it, every single time.

So when an agent writes 300 tokens on turn 40, those 300 tokens ride on top of a prompt containing all 39 previous turns. The work is 300 tokens. The bill is for a quarter of a million.

This makes turn cost an increasing sequence rather than a constant, and it makes total cost grow with roughly the square of the step count. Here is the measured growth in prompt size, taking the median across all 166 sessions at each turn index:

The context grows by a median of 1,368 tokens per turn — the mean is 2,071, and the spread is wide, from 411 at the tenth percentile to 4,089 at the ninetieth.

Turn 1 deserves a note, because it looks alarming and is not. It is the most expensive single turn in almost every session, six and a half times the cost of turn 3. That is not work; that is the cache being written. You pay a 25% premium once to store the prefix, then read it back at a tenth of the price for the rest of the session. It is the best money you spend all run.

What does turn position actually cost?

Growing prompts are intuitive. What surprised me was how much the same turn costs depending on where it lands.

To isolate this I took only turns where the model produced between 200 and 1,000 tokens — comparable units of work — and bucketed them by position:

Identical work. Nearly four times the price, purely for arriving late.

This reframes a question I had been asking wrong. I used to ask what a task costs. The real question is what a task costs at the point in the session where it happens — and the practical consequence is that the order you do things in has a price. Front-loading the expensive reads, or answering the cheap questions before the context has grown, is not premature optimisation. It is measurable.

What does a loop actually cost?

This is where I had to correct myself, because the obvious answer turned out to be wrong.

I flagged every session where the same tool call — same tool, same arguments — appeared three or more times. That is 79 of 166 sessions, 2,761 turns, $656 of spend. My assumption was that these turns would be individually expensive, and that the flagged spend would be disproportionate.

It is not. Repeated turns are 11.5% of all turns and 11.3% of all spend. Measured against the average turn in their own session, they cost 0.86× — a repeated tool call is slightly cheaper than the turns around it, because rerunning a command produces less output than reasoning does.

So loops are not expensive because their turns are expensive. Loops are expensive for two other reasons, and both are structural.

The first is position, which the table above already prices. Loops start in the middle or the end of a session, never at the beginning. Modelling a ten-turn loop against the measured growth curve:

The same ten wasted turns cost five times more at turn 200 than at turn 1.

The second reason is worse, because it outlives the loop. Every turn in a loop leaves its output in the context permanently. A failing test rerun six times does not just cost six turns — it raises the price of every turn after it, for the rest of the session. The context that grew does not shrink back.

Which is exactly why loops hide. Nothing in a per-turn view looks wrong. There is no expensive turn to find. The damage is distributed across every turn that follows, and the only cheap way to catch it is to count repeated calls rather than to look for a spike.

What is prompt caching actually doing?

Carrying almost the entire load, is what.

Ninety-eight percent of everything sent was served from cache at a tenth of the price. That single mechanism is the difference between $5,816 and $42,649 — a factor of 7.3.

It is worth being precise about what caching does and does not fix. It does not make the growth linear. Every turn still resends everything; the quadratic term is still there. Caching divides its coefficient by ten. That is an enormous win and it is not a structural fix.

The practical consequence is one most people learn the expensive way: caching is a prefix match. One changed byte anywhere in the prefix invalidates the cache for everything after it. Putting a timestamp at the top of a system prompt, or building the tool list in a non-deterministic order, quietly moves you from the $5,816 column to the $42,649 one. Nothing errors. The bill just stops looking the way it did.

What does compaction look like in the data?

There were 12 events where the context collapsed. The median peak was 996,345 tokens — essentially the 1M context window — dropping to 74,949, a 92% cut.

That is the sawtooth. Context climbs for hundreds of turns, hits the ceiling, gets summarised, and the cost curve resets almost to the floor.

It is the single largest cost event available, and it is not free. What gets summarised is gone. If the agent needs that detail later, it has to rediscover it — which means more turns, which means more context, which means climbing the same hill again. In the longest session I measured, 2,740 turns, this happened repeatedly: the prompt climbs from roughly 90K to nearly 1M, resets, and climbs again.

That session cost $881. Without caching the same work would have been $6,859.

What should you actually watch?

Total token count tells you almost nothing, because 98% of it is cache reads that cost a tenth of list price. A cost total tells you even less: it goes up when the agent works and up when the agent flails, and it cannot distinguish the two.

Three things are worth putting on a dashboard.

The prompt-to-output ratio. Mine is 309:1 in aggregate. Rising means the agent is carrying more history per unit of work — a session getting heavier rather than more productive. It is the closest thing to a single health number.

Repeated tool calls. The same command with the same arguments appearing a third time is the earliest reliable loop signal available, it costs nothing to compute, and it fires long before the invoice moves. This is the one I would build first.

Cache read share. It should sit near 98%. If it drops, something in your prefix is changing between calls, and you have quietly bought a 7× price increase.

All three live at trace level. None of them appears in a monthly total, which is precisely why the monthly total is the last place the problem shows up.

FAQ

Why does an AI agent cost more per turn as the conversation gets longer?

Because the model API is stateless — every turn resends the entire conversation history, not just the new message. On turn 40 the agent might write 300 tokens, but the prompt carrying them includes all 39 previous turns and is billed in full. Measured across 23,968 real turns, an identically-sized turn costs 3.8× more at position 190 than at position 5.

How much does prompt caching actually save on agent workloads?

In this measurement, 7.3×. Across 166 sessions the measured spend was $5,816 with caching against $42,649 for the same work without it, because 98% of all prompt tokens were served from cache at a tenth of list price. Caching does not change the shape of the growth — it divides the cost of that growth by roughly ten.

Are repeated tool calls expensive?

Not individually — that is the trap. Measured against the average turn in their own session, repeated tool calls cost 0.86×, slightly less than average, because rerunning a command produces less output than reasoning does. The cost is structural: the loop adds turns where the curve is already steep, and everything it leaves in the context inflates every turn that follows.

What is the prompt-to-output token ratio for coding agents?

309 to 1 across this dataset — 8.39 billion prompt tokens against 27.2 million output tokens. The ratio varies by workload, but the order of magnitude is a property of how agent loops work rather than of any particular tool. Watching it move is more useful than watching its absolute value.

Does context compaction reduce agent costs?

Dramatically, and not for free. In the measured sessions the context peaked at a median of 996,345 tokens before compaction dropped it to 74,949 — a 92% cut, and the cost curve resets with it. But summarised detail is gone, and if the agent needs it later it must rediscover it, which costs turns.

How do I detect an AI agent stuck in a loop?

Count repeated tool calls: the same tool with the same arguments appearing three or more times in a session. It is trivial to compute from the trace, and it fires far earlier than any cost alarm, because looping turns are individually cheap. Cost-based alerting finds loops only after they have already run long enough to matter.

The part that changed how I work

I went in expecting to find an expensive model, or an expensive tool, or one pathological session that ate the budget. There wasn't one. The spend was spread evenly across thousands of ordinary turns, each of them individually reasonable, each one carrying a slightly larger copy of everything that came before it.

The mental model I had — that a task costs what a task costs — was simply wrong. A task costs what it costs at the point in the conversation where you do it, and that price is still climbing while you decide.

If you want to watch that curve move under your own hands, I built an agent trace and cost simulator from these measurements: step through a trace turn by turn, add a retry loop, toggle caching off, and watch the bill separate from the number of steps.

And if the broader pattern is familiar — a system where the thing you assumed was being checked turns out not to be — it is the same shape as auditing agent guardrails that were never actually running. Both come down to the same habit: measure the mechanism instead of trusting the summary.