Users do not feel the size of your context window. They feel the chain of agent turns between the request and a useful answer. A fast model inside a twelve-turn loop still has to make twelve sequential trips through the model, tools, and checks. Later turns also tend to cost more, because they carry the accumulated conversation, tool outputs, and intermediate state back into inference.
That is why I would put turns per request beside latency and cost. Not as a curiosity in the trace, but as an early product signal.
Token totals can hide the difference. One run may finish in four steps while another wanders for eighteen with a similar aggregate token count. Step count, loop flags, and similar fields help separate solved work from flailing when token totals blur the problem.
Every turn is a wait
A turn is simple at the implementation level: one prompt-response cycle, often with tool use inside it. Hermes describes a turn that way: a user or system sends a request, the agent responds, and a tool call may happen as part of that response.
That definition matters because model speed does not remove serialized control flow. If an agent reads five files one after another, the user does not wait for one large answer. They wait through five cycles: model call, tool request, result, next step.
Continue’s note on parallel tool calling points at the same cost. Independent work should not be serialized through the model if it can be fetched at once. Otherwise five independent reads become five separate waits.
Product feel is not “we switched to a faster model.” Product feel is “the answer took seven waits.”A smaller model can feel slow when it keeps taking unnecessary intermediate steps. A larger model can feel acceptable when the loop is short and the tools return enough data in one call.The simple part is linear: more turns mean more waits. The worse part comes next: later turns often cost more.
Late turns cost more than early turns
Agent cost is not turns multiplied by a fixed price. Later turns usually carry more context than earlier ones.
ML Systems gives a useful example: by step 10, an agent may send 8k tokens to a model that started with 500, and prefill scales roughly linearly with context length. The tenth turn is not the first turn repeated. It is the first turn plus the decisions, tool outputs, observations, and mistakes that accumulated after it.
Billing has the same shape, but sharper. Augment Code explains that message history grows linearly by iteration, while total billed input tokens can grow quadratically because each call sends prior context again. That is why a turn chart often shows trouble before the invoice does.
Two public examples make the slope concrete. Galileo writes that a five-step ReAct loop uses roughly 10× the tokens of a direct answer. Stevens Institute describes a 10-cycle Reflexion loop that can consume 50× the tokens of a single linear pass.
The exact multiplier in your system will differ. The shape is the point: cost grows with both the number of turns and the context carried into each turn. Optimizing only one side is how teams get surprised.
Bigger context is not a cure
“Give it more context” is often a reasonable first instinct. Sometimes it works: a missing policy, schema, example, or document can remove a tool lookup.
But more context can also create the opposite problem. It can bury the relevant fact, increase prefill time, and make every later turn heavier. Anthropic’s context engineering guidance is blunt about the tradeoff: every new token spends part of the model’s attention budget, so context has to be curated.
Small context does not always win. The point is simpler: context affects turn count, but it does not replace measuring it.A better retrieval hierarchy may reduce turns. A dump of everything may increase them. Without a turns per request distribution from production, both stories sound plausible.
The anti-hype version is useful: a bigger window can make the agent stronger. It can also give it more room to stay confused for longer.
Put turns per request on the dashboard
Start with the production distribution, anonymized if needed. For every agent run, log request id, route, model, tool calls, turn index, input tokens, output tokens, latency, stop reason, error state, and final outcome.
Keep the raw sequence. Aggregates alone hide loops.Then split turns into productive and wasted.
A productive turn changes task state: it retrieves missing evidence, executes a required action, narrows the plan, asks a necessary clarification, or produces the final response.A wasted turn does not move the task forward. It repeats a query, reads the same source again without new value, fixes an avoidable formatting error, calls a tool that routing could have selected before the agent loop, or burns a reflection step that does not change the next action.
The dashboard should show p50, p90, and p99 turns per request by route, plus success rate by turn bucket. Put cost per request and latency per request beside it.The useful view is not “agents average 6.2 turns.”The useful view is: “invoice support tickets usually succeed by turn 4, but code migration jobs hit p90 at 17 and start failing after turn 12.”
That is where turn count becomes a leading indicator. The distribution moves before users complain that the system feels slow. The tail grows before finance notices the bill.
Cut wasted turns, not thought
The goal is not the minimum possible number of turns. The goal is zero wasted turns.
Routing should happen before the agent enters the loop, while the choice is still cheap. A classifier can decide whether to call the agent at all, which route to use, and which tools to make available. That keeps easy requests out of expensive general control flow.
Tool results should be richer. If the model needs five related facts, one tool should often return all five with provenance, confidence, and missing fields. Otherwise the agent spends separate turns collecting data the system could have gathered upfront.
Composite tools push the same idea further. Claude’s programmatic tool calling documentation describes code that calls tools inside an execution container instead of taking a model round-trip for each invocation. The point is not to turn a known process into a chain of unnecessary agent turns.Parallelism is the other direct lever. Independent reads should not pass through the model one by one. If three sources can be fetched at once, fetch them at once and give the next turn the combined result.
State matters too. Agents should not re-derive what the system already knows. Store durable state, intermediate decisions, retrieved source ids, and rejected branches in a compact form. Carry that state forward instead of asking the model to reconstruct it from a long transcript.
Finally, add a turn budget with graceful degradation. At turn 6, continue normally. At turn 10, return a partial answer with open questions. At turn 14, stop tool exploration and ask the human to choose a direction.A turn budget is a product contract, not just an infrastructure guardrail.
Optimize the product of turns and context
Turn count connects two decisions.
Before the loop, decide whether to call an agent at all. A cheap classifier or router can send direct answers, search, deterministic workflows, and human escalations down different paths.
After that, decide what context the chosen path needs: memory, retrieval, files, tool schemas, summaries, and saved state.Those decisions cannot be optimized separately. Too little context creates extra lookups. Too much context makes every lookup heavier and may still create extra clarification turns.
Turn count forces a simple equation: cost and latency are shaped by the number of sequential turns and the context carried into each one.
I would not chase one universal target. A two-turn billing answer and a twelve-turn code migration are different products. The dashboard should make that visible by route and outcome, using your real production distribution rather than a benchmark trace.
The practical target is narrower and harder to fake: every turn should have a job.If a turn does not change state, gather evidence, execute an action, or produce the answer, the product is making the user wait while the agent pays to reread itself.