How to Estimate a Runaway Agent's Cost Before You Set a Cap

The fast estimate multiplies iterations by an assumed per-iteration token size:

naive_tokens = max_iterations * tokens_per_iteration

Take an agent that loops on a failed API call, capped at 100 iterations by a step counter. Each iteration sends a system prompt, the tool schema, the last error and the model's previous reply, which measures 2,000 tokens in and 500 out.

naive_total_tokens = 100 * (2,000 + 500) = 250,000 tokens

That number is a useful floor and it is what most teams implicitly assume when they set a cap. It is also wrong in one direction: too low. Many chat and completion APIs are stateless, so they receive and bill the entire conversation history on every call (Augment Code on agent loop token costs). An agent loop appends tool output, observations and reasoning to the history after each iteration, so the prompt grows and earlier steps are paid for again and again.

The formal version of that growth, from the same analysis:

Total_input_tokens = N*S + u*N*(N+1)/2 + r*N*(N-1)/2

Where:
  N = number of iterations
  S = static prefix tokens (system prompt + tool definitions)
  u = new input tokens per iteration (user message + tool result)
  r = output tokens per iteration

A writeup on multi-turn tool use puts the undercount bluntly: estimates that multiply expected tool calls by per-call cost are wrong by 5 to 30 times depending on agent complexity, and it reports 40 percent of agentic AI pilots cancelled before production with runaway inference costs the most common reason (tianpan.co on the token economy of multi-turn tool use). The same source documents a five-step run where per-call token consumption grew 888, 3,400, 8,900, 14,200, 18,900. That is the quadratic curve in the wild.

Use both numbers. The linear bound is the floor. The quadratic bound is what you budget against, and your cap must clear it.

The quadratic formula needs three measured quantities: static prefix S, new input per iteration u, and output per iteration r. None should be guessed, because tool definitions are larger than people assume.

A detailed production system prompt runs 2,000 to 5,000 tokens, and every available tool gets serialized into context on every call whether or not the model uses it (tianpan.co). The same source reports measured production setups with 55,000 to 134,000 tokens of tool-definition overhead in a single call, and one team cut that from 134,000 to 8,700 tokens by loading tools dynamically. Guess 2,000 when the real prefix is 30,000 and your estimate is off by an order of magnitude before a single retry.

To get the three numbers:

1. Log prompt tokens, completion tokens, total tokens, model, route, tenant, request status, retry count and estimated cost on every call. Yotta Labs' budgeting guide lists this field set and argues for measurement before enforcement, because hard limits set early block valuable workflows (Yotta Labs on token budgets).
2. Pull a real production run, not a demo. Read S off the first call, u off the input delta between consecutive iterations, and r off the completion delta.
3. Where the provider returns a usage object (usage.prompt_tokens, usage.completion_tokens, usage.total_tokens), read from that rather than converting character counts, since tokenizers differ by provider (Solvimon on token pricing).
4. Use your worst observed iteration, not the median. An error payload with a large stack trace can be several times a normal tool result.

Databricks frames the same problem as a cost ledger: cost per output token, cost per inference, cost per active user, then revenue per user against it to find margin (Databricks on modeling unit economics). Your worst-case number belongs in that ledger, so the cap and the margin model share inputs.

The retry rate is the least intuitive multiplier and the one most likely to be wrong.

Retries cost twice. A failed call still bills its input, and the error response then joins the context, so every later call in the run pays for it again. tianpan.co notes that a 10 percent failure rate per step compounded across 10 steps without a circuit breaker can multiply costs several times over, and that one team cut per-task tool calls from 14 to 2 by adding explicit SUCCESS and FAILED terminal states so the model stopped retrying ambiguous outcomes (tianpan.co).

Contaminated context makes retries more likely. A simulation study of retry costs found a 5x retry multiplier pushed cost per successful task from $5.73 to $28.65, and that contaminated context raised the per-step error rate by 7.1x over baseline (AI Security Guard retry cost analysis). That last figure matters: the retry rate you measure on a clean run is not the rate inside a runaway, because the runaway is already polluting its own context.

If you want one number rather than a simulation, inflate the iteration count:

effective_iterations = max_iterations * (1 + retry_rate)

With 100 iterations and a 20 percent retry rate that is 120. Use 120 as N in the quadratic formula. It is conservative and defensible, and it is the adjustment behind the common shorthand of 100 * 2,000 * 1.2 = 240,000 tokens. Note what that shorthand does not do: it applies the retry rate to a flat per-iteration size, so it ignores context accumulation. Keep it as the floor.

Here is the full calculation for the agent looping on a failed API call, with every input written down so it can be replaced.

Step one, apply the retry rate: 100 * 1.2 = 120 effective iterations.

Step two, input tokens with the triangular term:

input_tokens = 120*6,000 + 1,200*120*121/2
             = 720,000 + 8,712,000 = 9,432,000

Step three, output tokens:

output_tokens = 500*120*119/2 = 3,570,000

Step four, price it:

cost = 9.432 * $1.00 + 3.570 * $5.00
     = $9.43 + $17.85 = $27.28

The linear estimate on the same inputs is 120 * 7,700 = 924,000 tokens, which lands near a dollar or two. The quadratic bound is more than ten times higher. That gap is the whole reason to do this before setting a cap rather than after the invoice.

Two things stand out. Output is the bigger line item even though input volume is nearly three times larger, because output tokens typically cost three to five times the input price (Solvimon). And the triangular term dominates: 8.7 million of 9.4 million input tokens are re-billed history, not new work.

A token-only estimate is a floor for a second reason: the token line is the visible part of AI spend, not all of it. Finout's breakdown of AI unit economics lists orchestration (agent frameworks, routing logic, workflow coordination), retrieval (vector queries and embeddings), evaluations, governance and labor as costs outside the API bill (Finout on AI unit economics). A runaway that fans out across sub-agents pays all of those per step.

Fan-out is the multiplier that breaks the cleanest estimate. tianpan.co reports roughly 7x cost per additional agent in a pipeline, so a four-agent research pipeline running 20 steps costs closer to 28x a single-agent system, before retries (tianpan.co). Unblocked, citing an arXiv study it flags as directional rather than a production benchmark, reports input tokens averaging 53.9 percent of agentic spend and the review-and-refinement stage eating 59.4 percent of all tokens (Unblocked on why agents burn tokens). Read those as reasons to instrument your own runs, not as your estimate.

If your agent can spawn sub-agents, apply the fan-out factor to the iteration count before the quadratic term, not after.

You have a worst-case number per run. A cap is a policy on that number. Three defensible rules:

The direction of the comparison matters most. A cap should cover the worst case but not much more, which means it is set from the worst case you computed, not the average run. Set it from the median and every third customer trips it. Set it at ten times the worst case and it is decoration.

The enforcement mechanism is a separate constraint. Most teams have a dashboard, Slack alerts at several thresholds and an account-level provider cap. Cycles calls that stack visibility rather than enforcement: dashboards are retrospective, an alert at $100 does not stop the $101 call, provider caps are scoped to an account rather than a run, and rate limits control velocity rather than total spend (Cycles). Ravoid makes the same point harder, describing enforcement as the layer that refuses to forward the next request once a rule is broken, and reconstructs a representative incident where four agents ran for eleven days and produced a $47,000 bill with all three layers in place (Ravoid on AI agent budget enforcement).

The requirement is a check before execution, atomic with the deduction, cumulative across retries and concurrent workers, which Cycles describes as reserve, execute, commit (Cycles). Budget dimensions belong per request, per user, per tenant, per feature and per environment, so a single monthly cap does not fail to stop a loop inside one agent or a dev script using a production key (Yotta Labs).

Then decide how the cap shows up in pricing. Charge per token and the customer absorbs the runaway, so the cap is a safety rail. Charge per seat or a flat fee and you absorb it, so the cap protects margin, which is why selling unlimited AI usage on a fixed seat price puts the supplier on the wrong side of heavy users (Willingness to Pay on AI pricing). The cap number is the same either way. Who pays is a pricing decision, not an engineering one.

If you would rather price the outcome than the token, the same worst-case figure is the ceiling on what one delivered result can cost you. That is the argument for tying spend to defined outcomes once a use case is locked, while keeping token-level controls underneath (Willingness to Pay on AI pricing).

Do the calculation once per agent, not once per company, because the inputs differ wildly between a support triage agent and a whole-repo coding agent. Write N, S, u, r and the retry rate into a comment next to the cap constant. When someone changes the system prompt or adds a tool, the constant is stale, and that comment is what tells the next engineer why.

Then reconcile. Compare the computed worst case to the largest actual run cost over a few weeks. If real runs exceed the bound, an input is stale, usually S after a tool was added or the retry rate after a new failure mode appeared. If real runs never exceed half the bound, tighten the cap.

For teams running several model families behind one app, the price input changes per route, so keep a rate per route next to the route budget. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key with prepaid dollar pricing, which makes the rate side one table to maintain instead of several (Quanta Inference). The loop-count side deserves a second pair of eyes, and Quanta Consulting runs a free 30-minute discovery call to review your goals and give a tailored recommendation, a reasonable place to pressure-test whether your agent's step ceiling is realistic (Quanta Consulting).