AI agent runaway cost calculator: price the loop before it runs

The calculator

Prices are yours to enter, from your bill or your provider's current price page. Everything is computed in this page; nothing is sent anywhere.

The same calculator ships in the free zambo-ai package, so the estimate and the policy can be generated inside your own tooling: pip install zambo-ai, then costcalc policy with the same inputs. In code: from zambo_ai.costcalc import estimate_run, generate_policy. The JS twin ships in the npm package: require('zambo-ai/costcalc').

The worked example: a one-dollar loop with a $60-an-hour failure mode

The defaults above are a realistic small loop: 4,000 input tokens and 800 output tokens per turn at $3 and $15 per million, three paid calls per iteration at two cents each. One iteration costs $0.084. A normal run of 12 iterations costs $1.01. Nothing about that loop looks dangerous.

Now the other numbers. At the 50-iteration limit, one run costs $4.20. Twenty worst-case runs in a day cost $84.00, and a month of worst-case days is $2,520.00. And if the limit is missing or the loop retries around it, the same iteration at a five-second pace burns $60.48 per hour, $1,451.52 per day, until a human notices. The gap between the expected dollar and the runaway day is not a different product or a pricing trick. It is the same loop, multiplied by time nobody budgeted for.

The policy the calculator generates for this loop: a per-call cap of $0.11, a daily cap of $105.00, a monthly cap of $3,150.00 server-side. Those numbers look high next to the $1.01 expected run, and that is the point. A cap is not a budget. A cap is the line where the loop is declared broken, and it has to sit above every legitimate bad day or the first busy week will train everyone to remove it.

Budget on the expected case, cap on the worst case

Two different numbers do two different jobs. The expected case is for planning: it tells you what the work should cost and what a healthy day looks like, so a day at three times expected is visible in a report. The worst case is for enforcement: it is the most the loop is allowed to cost before something refuses the next spend.

Setting the cap at the expected case is the common failure. Normal variance (a long document, a retry, a verbose model day) crosses it, the refusal interrupts real work, and the cap gets raised informally or deleted. Setting it at the worst case times a modest headroom means the cap fires only when the loop's shape has actually changed: stuck, retrying, or calling something far more expensive than designed. That is the only firing worth paging a human for.

Enforcement then has to exist in the two places the money moves. Locally, a guard in front of the payment call refuses over-cap spends and records the refusal, so "the agent tried to spend $900 at 3am" is a fact in a log, not a rumor. Server-side, the same daily cap set on the work connection survives session restarts and follows the job instead of one machine. The generated policy gives you both forms: the spendguard init command for the local guard in zambo-ai, and the spend_limit_set arguments for the Zambo connection.

Questions, answered