Gera Tools

Agent Loop Cost Simulator

Simulate how costs spiral in a ReAct / tool-use agent loop

Free agent loop cost simulator. See how token cost accumulates across think-act-observe iterations in a ReAct or tool-use agent, compare a typical run against the max_iterations cap, and pick a safe cost ceiling. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why do agent loops spiral in cost?

Each iteration re-sends the growing scratchpad of prior thoughts, actions, and observations as input. Without a cap, a confused agent can loop dozens of times, each iteration more expensive than the last.

Agent loop cost simulator

A ReAct-style agent runs a loop: think, act, observe, repeat. Each pass appends to a growing scratchpad that gets re-sent on the next call, so cost climbs with every iteration. A task that usually finishes in three loops can quietly run to twenty when the agent gets stuck. This simulator shows the typical cost, the worst-case cost at your max_iterations cap, and helps you set a safe ceiling.

How it works

The simulator models cost as accumulating across iterations, where each iteration’s input grows as the scratchpad lengthens. To keep it transparent it uses a per-iteration token figure that already reflects the average growing context:

typical_cost  = avg_iterations × tokens_per_iteration / 1M × price
worst_cost    = max_iterations × tokens_per_iteration / 1M × price

The gap between the two is your cost exposure — the maximum a single runaway task can cost beyond what you expect.

Why the scratchpad compounds cost

Most developers think of an agent loop as several fixed-size calls. In practice each call re-sends everything the agent has thought and observed so far. An iteration that costs 2,000 tokens on pass 1 might cost 4,000 on pass 3 and 8,000 on pass 6 as the scratchpad accumulates tool outputs and prior reasoning. When an agent loops to its cap because a tool keeps erroring, the final iterations are also the most expensive ones. This is why the simulator uses a per-iteration token estimate rather than a flat count — the compounding effect is where the surprise bills come from.

Worked example

Suppose you use a model priced at $3 per million tokens, your agent typically takes 4 iterations each consuming roughly 3,000 tokens, and you have set max_iterations = 20.

  • For illustrative purposes: typical cost ≈ 4 × 3,000 / 1,000,000 × $3 = $0.036 per task
  • Worst-case cost ≈ 20 × 3,000 / 1,000,000 × $3 = $0.18 per task

At 10,000 tasks per day the typical bill is around $360 and the worst-case bill is around $1,800. The difference is your exposure if a significant fraction of tasks go runaway. Adjusting max_iterations from 20 to 8 cuts worst-case cost by 60% while still giving normal tasks room to finish.

Setting a safe cap

A useful approach is to look at your actual iteration distribution — median, 90th percentile, and maximum observed — then set the cap at roughly the 95th percentile of your observed runs. Tasks that genuinely need more iterations are unusual and should be investigated rather than accommodated with a higher cap.

Tips and notes

  • Always set max_iterations. An uncapped loop is an uncapped bill. Treat the cap as a non-negotiable safety control.
  • Fail loud, fail cheap. Configure the agent to return a clear error when it hits the cap rather than silently retrying the whole task.
  • Log iteration counts. If your average creeps toward the cap over time, your prompts or tools are getting harder to follow — investigate before the bill grows.
  • Separate cost control from quality. A low cap that cuts normal tasks short is a quality problem, not a saving. Size the cap from observed behaviour, not from a cost target alone.