Why does turn 40 cost more than turn 4?
Because the API is stateless. The conversation is not stored on the server — every turn resends the entire history. Alongside the 300 tokens the agent writes on turn 40, all 39 previous turns go back into the prompt: the files it read, the command output, the error messages. All of it is billed again.
So turn cost is not a constant, it is an increasing sequence. Total cost grows roughly with the square of the step count rather than linearly with it. The dashed line on the chart shows what the bill would look like if every turn after the first cost what turn 2 cost; how fast the amber curve pulls away from it is the whole story.
Turn 1 is worth understanding separately, because it looks alarming and is not. It is the most expensive single turn in most sessions — in the runs behind this simulator its median cost was roughly six times turn 3's. That is the cache being written, not work being done. 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.
Why is a loop disproportionately expensive?
Two reasons. The first is position. Loops usually start in the middle or near the end of a session, so every looped turn has to resend all the context accumulated so far. The same work done on turn three would have been far cheaper.
The second is worse, because it outlives the loop. Every turn in the loop adds to the context permanently. That failing test on its sixth rerun does not just cost its own turn — it raises the price of every turn after it. Context that has grown does not shrink again, at least not until compaction fires. The comparison row under the trace splits the detour into exactly these two parts: what the extra turns cost themselves, and what they quietly added to everything downstream.
This is also why loops hide so well. Measured across real sessions, a repeated tool call is individually a little cheaper than the average turn around it — rerunning a command produces less output than reasoning does. Nothing in a per-turn view looks alarming. The damage is structural rather than local, which is why you catch it by counting repeated calls, not by looking for an expensive turn.
What does prompt caching change?
It reads the unchanged prefix at a tenth of the price instead of full price. That does not remove the quadratic growth — it divides its coefficient by ten. Turning caching off in the simulator and rerunning the same scenario shows the difference directly.
This is also why keeping the system prompt and the tool definitions byte-stable is a billing decision rather than a style preference. Caching is a prefix match: a single changed byte in the middle invalidates the cache for everything after it, and the next turn pays full price for the whole history.
What does compaction do?
When the context window fills, the history is summarised and the summary replaces it. That is the vertical drop in the blue line. The effect on cost is dramatic — the slope of the curve resets to near the floor. But it is not free: what gets summarised is gone, and if the agent needs that detail later it has to rediscover it. Rediscovery means more turns.
What is actually worth watching?
A total token count on its own tells you very little. Three things are worth tracking instead. Turn position, because the same work is more expensive later. The prompt-to-output ratio, because a rising ratio means the agent is carrying history rather than doing work. And repeated tool calls, because the same command appearing a third time is the earliest reliable signal of a loop. All three are visible at trace level. None of them is visible in the invoice total.
