Your agent can spend. Give it a cap it cannot cross.

Stop an AI agent from overspending: the short answer

Set the cap on the connection, before the agent pays for anything. An agent connected to Zambo spends through one work connection. Two free tools govern it: spend_limit_set sets a daily dollar cap (and an optional monthly cap) on that connection, and spend_limit_status reads back what the connection spent today, what is pending, every charge so far, and what remains. The cap is set before further Day Pass payments on the connection, which is the thing an autonomous agent actually buys: its own $0.99 Day Pass, in USDC on Base through x402, when its free limits run out. No cap, and the only limit is the balance in the agent's wallet. A cap, and the connection itself refuses to be spent past it.

Scope, stated once and applied everywhere on this page: the cap governs payments on that Zambo work connection. It does not govern the agent's wallet as a whole, other services the agent might pay, or free calls, which cost nothing and are governed by per-tool free limits instead. A verifiable receipt shows the saved record of a charge has not changed since it was recorded; it does not show the purchase was a good idea.

Why agent spending runs away

People overspend in decisions. Agents overspend in loops. A retry that never gives up, a planner that re-buys the same data every cycle, a tool call that quietly bills per use: each charge is small, none of them feels like a decision, and the first time a human sees the total is the invoice. Per-call pricing makes it worse, because the agent cannot see a budget in a price list. What it can respect is a boundary: a number, set in advance by you, that the connection checks before money moves. That is the whole idea here. Not an alert after the spend, not a dashboard you have to remember to open, but a cap in the path of the payment itself, plus a ledger that shows every charge the moment it exists.

How the cap works

1. Connect once. Add https://zambo.dev/mcp to the AI your agent runs in (Claude, ChatGPT, Grok, Cursor, Gemini, VS Code, Windsurf, or any MCP client). No key, no signup. The agent's work, and its spending, now run through one work connection.
2. Set the cap before the agent spends. spend_limit_set with a daily amount, and a monthly amount if you want a second fence. In the worked example above, the daily cap was set to $0 on a test connection, and the setting itself returned a verifiable receipt (bed31e84, verified).
3. Let the agent work. Free calls cost nothing and do not touch the cap. When the agent buys access, the payment it makes is a Day Pass purchase on that connection, $0.99 in USDC on Base through x402, checked against the cap you set. People top up the same pass with a card through PayPal; the agent rail and the human rail buy the same 24 hours.
4. Read the ledger, not the invoice. spend_limit_status returns spent today, pending, the charges list, the cap, and the remainder, whenever you ask, and the status call itself is receipted (f8e168cc, verified, showing limit $0, remaining $0, charges empty). The same day's work sits in the connection's Today view, one record for money and work together.

Setting a real budget is the same motion with a real number: cap the connection at $5 a day and the agent can buy at most five Day Pass activations a day on it, with every one of them receipted. Raise or lower the cap whenever you like; each change is itself a recorded call.

What the cap does not do

It does not watch the agent's whole wallet. If the agent pays some other service directly, that spend never passes this connection and this cap never sees it; the x402 challenge itself tells the agent that its own wallet policy still applies, and both fences are worth having. It does not judge purchases: a capped agent can still buy the wrong thing under the cap, and the receipts will faithfully show that it did. And it does not replace the free tier's per-tool limits, which bound how much an agent can do for free in a day. What the cap adds is the one thing none of those give you: a dollar boundary, set by you in advance, on the connection the agent actually spends through, with an itemized, checkable record of every charge against it.

The pricing side of the same problem, what a day of agent work should cost at all, is worked through in how much it costs to run an AI agent for a day. The emergency version, proving an agent actually stopped when you killed it, is in kill switch proof.

Questions, answered