Why the bill is always a surprise
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 arrives with a moment where anyone could have said no, and an alert, if one exists at all, fires after the money moved. The first human signal is the invoice.
A line in the prompt, "spend at most $5", does not fix this, because it is a request, not a boundary. The model can lose it in a long session, misread it, or be talked past it by content it reads along the way. Anything that has to hold at 3 a.m. has to be enforced outside the model, in the path of the payment itself.
This morning, step one: reconstruct the night
Before arguing about the bill, read it. Every call an agent makes through Zambo leaves a verifiable receipt at the moment it runs: the tool, the time, the saved result. The connection's Today view lines the night up in order, and spend_limit_status returns what the connection spent, what is pending, and the full charges list. From the record you can answer the questions the invoice cannot: which call repeated, when the loop started, and what each charge actually bought.
Scope, stated once: the record covers work that ran through this connection. Spend that never passed through it, a model provider's own token bill, another service the agent paid directly, lives on those providers' records. No tool can reconstruct a night it was not part of, and this page does not pretend to.
Step two: put the cap in the path of the payment
spend_limit_set sets a daily dollar cap on the agent's work connection, with an optional monthly cap as a second fence; spend_limit_status reads the ledger back at any time. Both are free tools with no quota. The cap is checked before a payment on the connection is taken: once the connection reaches its cap, a Day Pass purchase attempt returns spend_limit_reached and no payment is taken. Setting a real budget is the same motion with a real number: a $5 daily cap means at most five Day Pass activations a day on that connection, each one receipted, and the cap can be raised or lowered whenever you like, with each change itself a recorded call.
Worked example: a $0 cap, and the refusal, both on record
On October 16, 2026, a fresh test connection ran the whole sequence on the free tier. Step one: spend_limit_status reported no cap in place and $0 spent, receipt c24cabfc. Step two: spend_limit_set set the daily cap to $0, receipt bed31e84. Step three: spend_limit_status again: limit $0, remaining $0, charges empty, receipt f8e168cc. Step four, the refusal: a Day Pass activation attempt on the capped connection returned the error spend_limit_reached with limit_usd 0, and nothing was charged. That refusal is not a claim on this page. It is preserved as verifiable receipt 2f8bd3d1, saved at 2026-10-16T20:11:16Z, and it still reads verified today. Open it and check it the way you would check any receipt here.
The preventive version of this page, setting the cap before the agent ever spends, is how to stop your AI agent from overspending. This page is what you do when that advice arrives one night too late.
What the cap does not do
- It does not refund last night. The record settles what happened; getting money back is a conversation with whoever holds it.
- It does not govern the agent's whole wallet. Spend on other services never passes this connection and this cap never sees it. An agent that holds its own wallet also answers to its own wallet policy, 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.
- It does not make the spend wise retroactively. A verifiable receipt shows the saved record of a charge has not changed since it was recorded. Whether the charge should have happened at all is your judgment to make, now with the record in front of you.
The setup that ends the pattern
Three habits, all cheap. Cap before the run, at a number you choose while awake. Read Today before the summary: the day's calls and charges in one record, checked in the morning the way you would check a bank feed. And for actions that should never happen unreviewed at any price, add a human sign-off gate: a cap stops the spend, a gate stops the act. If the sequel ever starts anyway, kill switch proof is the record that shows the agent actually stopped when you stopped it.
Questions, answered
My AI agent spent too much money overnight. How do I stop a runaway agent from spending more?
In two moves. First, read the night back: every call the agent made through Zambo left a verifiable receipt when it ran, and spend_limit_status returns what the connection spent, what is pending, and every charge, so the bill stops being a rumor. Second, set the cap before the next run: spend_limit_set takes a daily dollar amount on the work connection, and once the connection reaches it, a payment attempt returns spend_limit_reached and no payment is taken. In the live test on this page, a connection capped at $0 refused a Day Pass activation with exactly that result, and the refusal is itself a verifiable receipt (2f8bd3d1). Both spend tools are free.
I told the agent to spend at most $5. Why did that not stop it?
Because an instruction is text the model interprets, and interpretation drifts: a long session can bury it, a loop never re-reads it, and content the agent reads can argue with it. Anything that has to hold while you sleep has to be enforced outside the model, by the server, in the path of the payment, before money moves. That is the difference between a request and a boundary. The cap is the boundary: it is a property of the connection, not of the agent's intentions, so it holds whichever AI is using the connection that night.
What exactly does the spending cap cover?
Payments on the Zambo work connection, which in practice means the Day Pass purchases the agent makes for itself when its free allowances run out. For $0.99, the agent buys itself 24 more hours of work inside the cap you set, paid by the agent in USDC on Base through x402, or by a person with a card through PayPal: get the Day Pass. The cap does not cover the agent's wallet as a whole, other services it pays directly, or a model provider's token bill; those need their own fences. Free calls cost nothing and are bounded by per-tool free allowances instead.
How do I see what it spent, itemized?
Call spend_limit_status on the connection. It returns what was spent today, pending charges, the cap, the remaining budget, and the list of charges, and the call itself returns a verifiable receipt. Every tool response also carries a link to the connection's Today view, where the day's calls and their receipts sit next to the spending, so the money and the work read as one record: the loop that caused the bill is visible in the same place as the bill.
Does the cap cost anything, and does it work on the free tier?
No, and yes. spend_limit_set and spend_limit_status are free tools with no quota, and the $0-cap example on this page ran entirely on the free tier. The cap matters once the agent starts paying for Day Passes. For ongoing use the Zambo Pass is $29 a month or $290 a year, $19 a month for $ZAMBO holders.