What is the best way to cap AI agent spending before it runs away?
Layer three caps, because each catches a different failure. Review the receipt and actual deliverable before accepting a handover.
Runaway agent spend has a shape: not malice, but a loop, a retry storm, or a task that quietly multiplies its own subtasks. A single cap set at the account level notices late, after the pattern has already spent. The layered design puts the fastest control closest to the behaviour: the endpoint cap sees every call, knows which agent is calling, and can refuse the call that crosses the line, in the moment, with the refusal written into the same record as the work.
Zambo's own surface implements that layer directly: spend_limit_set sets the cap, spend_limit_status reads it, and calls past the cap are refused on the record. The refusals matter twice. Operationally, they stop the loop. Evidentially, they prove the control was live, which is the record an insurer, a client, or your own incident review will ask for after any spend event. Provider limits remain the outer wall for the account as a whole, and wallet policies govern the separate question of money an agent can pay out to others.
Operate the layers like controls, not settings: caps sized from last month's real call records, refusals reviewed weekly, any cap raised by a named human with the reason recorded. A cap nobody reviews becomes either a nuisance that gets disabled or a wall the work routes around.
Checklist: the three-layer spend cap
Layer 1, provider: account-level limit set at the provider; alert at 80 percent. Layer 2, endpoint: per-agent cap set with spend_limit_set before unattended work; refusals reviewed weekly; raises by a named human, reason recorded. Layer 3, wallet: per-agent payment policy where agents pay out; smallest viable amounts; revocation tested. Sizing rule: start from last month's recorded calls per agent; set the cap at the honest ceiling of a heavy day, not at the average. Review: one page per month, caps against actuals, kept with the spend record.
Worked example
Sample: a research agent in a retry loop calls the same source forty times overnight. Layer 2 refuses call one past the cap and records the refusal; the morning review reads the refusal, finds the loop, and fixes the prompt, at a cost of one capped day instead of an account-level surprise. (Sample scenario; the limit tools named are live on the connection.)
Frequently asked questions
Will a cap break legitimate work mid-job?
A cap sized from real usage refuses only the abnormal call, and the refusal is visible immediately rather than at invoice time. Jobs that legitimately outgrow a cap get a recorded raise by a human, which is the control working as designed.
Is the provider limit alone enough for a small team?
It bounds the worst case for the account, which is worth having, but it cannot tell agents apart, cannot refuse at call granularity, and leaves no per-agent record. For unattended agents, the endpoint layer is the one that earns its keep.
Do caps apply to the free tier too?
Free usage is already bounded per tool per day by the tier itself. Caps matter where spend is real: paid calls, pass usage at volume, and any agent running while nobody watches.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai