Direct answer
How to get an alert before your AI agent overspends, while there is still time to act.
Set two different tools and stop expecting one to do the job of the other. The cap is a wall: at the limit, the run stops. The alert is a doorbell: at 50 and 80 percent of budget, it tells you a run is spending, while the run is still alive and you can still judge whether to let it finish, raise the budget, or stop it yourself. You need both, in that order.
Updated October 24, 2026.
A wall and a doorbell are not the same tool
A spending cap answers one question: what is the most this can cost me? That is a real protection and you should set it. But a cap gives you no warning, no context, and no choice. The first time you hear about the run is when it dies at the wall, halfway through a job that might have needed ten percent more to finish and deliver.
An alert answers a different question: is this run spending the way I expected, right now? It fires early, while judgment is still useful. Most overspend damage is not a single huge call. It is a loop, a retry storm, or a plan that quietly expanded, burning budget in small steps for hours. A doorbell at the halfway mark catches that pattern when it is still cheap to stop.
The alert ladder: 50, 80, 100
Set three rungs against the per run budget, not the monthly bill. A monthly total is a blur that hides the one bad run inside thirty good ones.
50 percent of budget: worth a glance. No action needed by default. You are checking one thing: is the spend so far plausible for a job this far along? A research run at half its budget with most sources gathered is fine. A run at half its budget in four minutes, repeating the same step, is not. This rung exists to catch the loop early, while stopping it is painless.
80 percent of budget: check the run now. Open the run, look at what it has produced and what it says it still has to do. Decide on purpose: let it finish inside the budget, raise the budget because the output justifies it, or stop it because it is circling. Any of those is a good outcome. The bad outcome is never having looked.
100 percent of budget: the cap fires. The wall does its job and the run stops. The alert at this rung has a different role: it tells you the cap fired, which run it fired on, and what the last step was, so the stop is an event you learn about now, not a silence you discover tomorrow when the output is missing.
Where alerts can live today
You do not need a new platform to build the ladder. You need three ordinary pieces, set deliberately:
1. The provider usage notifications and limits. On the provider rail, set a soft limit or usage notification at your alert rungs where the provider offers them, and a hard limit at the cap. Names differ by provider, and the settings usually sit in the billing or usage dashboard. This layer covers spend on that provider, whichever agent caused it, as long as the agent uses its own key (see the setup order below).
2. Your own check of the per run spend record. On Zambo, the verifiable work layer for AI, every call leaves a verifiable receipt, and each receipt carries its place in the run. A mid run check therefore shows spend so far against this job, step by step, not a monthly blur. A receipt proves the saved result was not changed since it was saved, so the record you are judging from is the record that was made when each call ran. HANDOVER, the flagship Zambo product, packages that chain so the state of a long job can be handed over or reviewed without starting from scratch.
3. Scheduled self checks for unattended runs. For a run nobody is watching, set a simple recurring check, on a timer you control, that reads the spend so far and sends the same alert fields the ladder uses. It is plumbing, not magic: read the current total, compare it to the rungs, notify if a rung was crossed. The value is that it runs at 3 a.m. when you do not.
The setup order, step by step
Step 1: One key per agent. Give each agent its own provider key. Shared keys make every alert useless, because the spend cannot be attributed to the run that caused it. Separate keys turn a vague bill warning into a named run you can stop.
Step 2: Set the provider hard limit as the backstop. Do this before any alert work. The cap is the floor of the whole system: whatever else fails, the wall holds.
Step 3: Set the alert thresholds. 50 percent and 80 percent of the per run budget, delivered to an inbox or channel you actually see during the hours the agent runs.
Step 4: Turn per call records on. Run the work where each call leaves a record you can inspect mid run. Without per call records, an alert tells you money is leaving and nothing about where it went.
Step 5: Run one test that trips the doorbell on purpose. Set a tiny test budget and run a job that deliberately crosses the 50 percent alert. Confirm the alert arrives, contains the run id, the spend so far, and the last step, and reaches the device you expected. An alert you have never seen fire is a hope, not a system. Reset the budget when the test passes.
Honest limits
An alert you sleep through changes nothing. It creates a record that a warning was sent, and that record has value in the morning, but it does not slow a looping agent down by one call. Pair every alert with the cap for anything unattended, no exceptions. Coverage is also split, and pretending otherwise sets you up for a blind spot: Zambo side records cover Zambo calls, provider side alerts cover the provider rail. An agent that spends on both needs both layers set. Finally, thresholds are judgments, not facts: a 50 percent alert on a bursty job will sometimes fire on healthy work. That is the price of an early doorbell, and it is far cheaper than the silence it replaces.
Run agents on a record instead
Work run through the Zambo MCP endpoint at zambo.dev/mcp (153 tools) saves a verifiable receipt for every call, rejected calls included, so a mid run spend check reads real steps, not estimates. Start free: 20 free calls per day, then they upgrade. The Day Pass is $0.99 for 24 hours. The Zambo Pass is $29 for 30 days, one payment. Checking any receipt is always free at zambo.dev/verify.
Questions, answered
Why not just use a cap and skip the alerts?
Because a cap alone tells you nothing until the run is already dead. The cap stops the spend, but you find out hours later, with no output, no explanation, and no chance to make the judgment call only you can make: raise the budget because the run is nearly done and working, or kill it because it is looping. Alerts give you that decision point while the run is still alive. The cap protects your wallet. The alert protects the work.
What threshold should I pick for the first alert?
Start with 50 percent of the per run budget for the first alert, 80 percent for the second, and let the cap sit at 100 percent. Fifty percent is early enough that a normal run tripping it is just information, and a runaway run tripping it in the first few minutes is a clear warning. If your runs are short and cheap, raise the first alert to 60 or 70 percent to avoid noise. If a single run can spend real money, keep 50 percent and add an alert on time as well, for example any run still going after twice its usual duration.
My agent runs overnight. Will alerts help?
Only if they are paired with the cap, and this page is blunt about it: an alert you sleep through changes nothing. For unattended runs, set the provider hard limit first so the worst case is bounded while you sleep, set the alerts second so the record of what happened is waiting for you in the morning, and add scheduled self checks during the run so a looping agent is caught by the ladder logic, not just by the final cap. Wake up to a capped, recorded run, not an open ended bill.
Can the alerts go to my phone?
In most setups, yes, through channels you already have. Provider usage notifications usually arrive by email, and email on your phone is a phone alert if notifications are on for your mail app. Some providers and billing tools also offer their own notification settings inside the usage or billing dashboard. Set the alert address to an inbox you actually see, test it once with a deliberate small run, and confirm the message lands where you expect before you rely on it for an overnight job.
What does the alert need to contain to be useful?
Three things, minimum: the run id, so you can find the exact job; the spend so far against its budget, as a number and a percent, so you can judge urgency at a glance; and the last step the agent took, so you can tell a healthy long run from a loop repeating one call. An alert that only says usage is high forces you to go digging while the meter runs. An alert with those three fields lets you decide in seconds: let it finish, raise the budget, or stop it now.