Why a spend cap misses a runaway agent

How does the money actually disappear?

Not through heavy usage. Through a loop.

The published accounts share a structure. Two or more agents pass work between themselves. One asks for clarification, the other supplies it and asks a question back, and the exchange satisfies neither of them. There is no step cap, no per-conversation budget, and no component whose job is to decide the work is finished. The loop runs for days.

What makes it expensive rather than merely wasteful is that each turn carries the accumulated context, so cost per turn rises as the conversation lengthens. The bill accelerates while the system looks busy and healthy.

These accounts are practitioner write-ups rather than audited incident reports, so the dollar figures should be read as self-reported. The mechanism is consistent enough across them to design against.

Why the obvious control does not work

A monthly ceiling is the control most teams reach for, and it is the wrong instrument for this failure. It fires when a total is crossed, which happens after the spending is finished. The incident is already over; the alert is a receipt.

Provider dashboards have the same problem for a different reason. They report at provider granularity, on a delay, with no attribution to the team or agent that caused it. By the time the figure updates, the question has moved from “stop it” to “explain it”.

What catches it?

Deviation, measured against what this system normally does.

A loop does not look like slightly heavier usage. It looks like many times the trailing average, sustained. An alarm on spend rate relative to a recent baseline — evaluated continuously rather than on a billing period — fires within minutes of the pattern starting, while the action is still cheap.

Three other controls sit around it. Retry caps, so a failing step fails closed rather than spinning. Step or turn limits per conversation, so an unproductive exchange terminates. And a hard cap at the virtual key as the backstop, which is what stops the incident if nobody answers the alarm.

Four controls, in the order they act

PreventStep and turn limits per conversation. Retry caps so failures do not spin.

DetectSpend rate against a trailing baseline, evaluated continuously.

ContainHard budget at the virtual key. The loop stops even if nobody is awake.

AttributePer-team and per-agent keys, so the alert names the workload.

Why attribution is part of the control

An alert that says spending is high is a research project. An alert that says this agent, owned by this team, is running at fifty times its trailing average is an action.

That requires virtual keys issued per team and per agent rather than one organisational key shared across everything. It is the least glamorous part of an AI platform and the part that determines whether an incident takes ten minutes or a day.

The uncomfortable detail about cost

Tokens are returned with the response. Money is not. Every cost figure is a token count multiplied by a price table that someone has to keep current as providers change pricing. If that multiplication happens at capture time, the number exists when it is needed. If it happens in a monthly reconciliation, the number exists after it is useful.