An agent that costs three pounds a day is an agent nobody thinks about. The same agent in a retry loop costs three pounds an hour and nobody thinks about that either, until the invoice. This page covers how agent spend actually goes wrong, why alerting is the wrong instrument, and what a cap has to do to be worth having.
Use a prepaid balance with a hard stop rather than a postpaid account with an alert. An alert tells you money has already been spent; a hard stop ends execution when the balance runs out, so the worst case is a paused agent rather than an invoice. Then watch cost per run, not just the monthly total.
Main cause
Retry loops, not high per-call prices
Second cause
Context that grows every run
Why alerts fail
They report spending, they do not stop it
Right instrument
A prepaid balance that halts at zero
Spend failure modes
Failure
What it looks like
What catches it
Retry loop
Run duration and cost spike together
Per-run cost, a hard cap
Growing context
Cost creeps up run over run
Per-run cost trend
Oversized payloads
One agent dominates the bill
Per-agent breakdown
Fan-out
Cost tracks an input list size
Per-run cost, a hard cap
Forgotten agent
Steady spend, nobody reads output
A quarterly prune
Where agent spend actually goes wrong
Rarely in the place people budget for. Per-call model prices are published and easy to estimate. The overruns come from behaviours that multiply the number of calls, and none of them are visible in a pricing table.
Retry loops. A tool fails, the agent retries, the failure is permanent, and the loop is not. Every retry is a paid call.
Growing context. An agent that appends to its own history spends more on every run than the run before, on the same work.
Oversized tool payloads. One integration that returns a whole document instead of an excerpt can dominate the token bill.
Fan-out. An agent that spawns sub-tasks per item quietly multiplies cost by the size of a list you did not check.
Why alerts arrive too late
A spend alert is a report about the past. By the time it fires, the money is gone, and the mechanism that spent it is still running. That is acceptable when a person is watching and can intervene within minutes. It is not acceptable for an agent that runs unattended overnight or across a weekend.
Provider billing is usually delayed, so the alert lags the spend.
An alert at 3am is read at 9am, and the loop ran for six hours.
The useful property is not notification, it is termination.
What a real cap does
Three things, and most spend controls only do the first. It has to be enforced at execution rather than reporting, it has to stop rather than warn, and it has to fail in a way that does not destroy anything.
Enforced before the call, so a run that would exceed the balance does not happen.
Stops execution outright, rather than continuing with a notification sent.
Fails safe: the agent pauses and its environment survives, so nothing is deleted and topping up resumes normal service.
Prepaid versus postpaid, and why it matters here
The billing model is the control. With postpaid, the ceiling is whatever your card allows, and a limit is a promise to bill you differently rather than a mechanism that stops work. With prepaid, the balance is the ceiling and zero is a real floor.
Watch cost per run, not the monthly total
A monthly total hides a step change until the month is nearly over. Cost per run surfaces it immediately: an agent that cost 4p a run all month and costs 60p today has changed behaviour, and you can look at why while it is still a small number.
How Qoren handles spend
Every plan includes a monthly credit grant, and credits cover model usage, web searches, environment hours, and mailboxes from one balance. When credits run out, agents pause rather than continuing to bill: model calls, searches, and further charges stop, while environments and mailboxes stay provisioned so nothing is deleted. Purchased credits never expire, and bring-your-own-key is available on every plan if you would rather pay the provider directly.
Almost always because something multiplied the number of calls rather than because a call was expensive. Retries against a permanently failing tool, a context window that grows every run, or a task that fanned out over a longer list than you expected. Per-call pricing is easy to predict; call volume under failure is not.
Run OpenClaw or Hermes without managing infrastructure.
Deploy a managed agent environment, configure the runtime, and keep the agent online without Docker, VPS setup, or server maintenance.
