AI agent cost overruns: anatomy of a runaway bill

2026-10-20 — we sketched the problem once already: <a href="/en/blog/agent-spend-hard-limits/">your agent doesn’t know what it costs</a>. This is the anatomy — the specific shapes a runaway bill takes, what you can honestly measure while it is happening, and where a limit stops being a dashboard alert and starts being a mechanism.

Three shapes the overrun takes

• The retry loop. A failing test, a plausible fix, the same failure. Each round is reasonable; forty rounds is a bill. Nothing in the loop knows the counter is running.
• The spawn tree. Agents now fork helper sub-agents the way earlier processes forked shells. The provider sees six API clients; your laptop sees one “cheap” session. The lineage is the missing number.
• Context creep. Every retried turn drags a longer transcript; per-request cost grows quadratically-ish with patience. The model never mentions the rate card, because the model doesn’t have one.

Why the billing dashboard is the wrong vantage point

The money lives on your provider’s billing plane; the agent’s process only sees requests going out. Account-level budgets catch the month, not the runaway hour — by the time an alert fires, the work is done and the invoice already reflects it. And a gateway that meters traffic still cannot tell which of the six agents on your machine started the loop, or which spawned child inherited the session. Attribution, not aggregation, is what is missing.

What you can count locally, honestly

Count what the agent does, in units your machine can actually see: runtime, billable requests, tokens per call where the client reports them, CPU time, memory held — and record every crossing of a limit you set in those units. A number without a source stays “unknown” instead of quietly becoming zero. That is what 20131’s cost guard does today: a local, open-source, observation-only component. It records spend-shaped behavior and it does not stop anything yet — the honest version of “monitoring”, not the marketing version. The mechanics of the record are the same ones in <a href="/en/blog/agent-actions-audit-trail/">the audit trail</a>.

What a hard limit would actually take

Observation answers “what happened.” A team running several agents needs the next action held until a human says yes — one view across everyone’s machines, one budget surface per project. Whether that becomes a Team plan is an open decision on purpose: the reservation page says so, and it asks a single question — would you pay, or why not. The price is not invented for a landing page, and the enforcement verbs are not pre-spent: they live behind the same phase discipline as everything else here (<a href="/en/cost-guard/">cost guard &amp; Team reservation</a>). What the fallback semantics of “held, then judged locally” require is a separate post — <a href="/en/blog/deterministic-fallback-when-model-fails/">deterministic fallback when the model fails</a>.

If you sign the invoice

Cost overruns are a governance gap before they are a developer gap: procurement can demand a price-per-task estimate, but nobody can estimate what an unattributable process tree spends. Local lineage plus a crossing log turns “the API bill was weird in March” into a diff. The framing of what a record has to contain to mean that is in <a href="/en/blog/what-is-agent-observability/">agent observability</a>; the home view of the whole runtime is, well, <a href="/en/">home</a>.