About
One person builds this. That is worth knowing before you put it in front of a production loop.
Why it exists
Provider spend caps are real and they fire. What they are bound to is a project, an organization over a calendar month, or one session on that vendor's own harness. An agent loop does its damage in an evening, across whichever providers the job happens to touch, and a boundary drawn around the month is not drawn around that run.
So the ceiling here is attached to a job rather than to a calendar. Every
call that carries the same task_ref draws down
one budget, whatever the provider, and the preflight for the call that would
break it comes back approved: false.
What it deliberately is not
It is not a proxy. Your traffic does not route through anything of ours and we never hold your provider keys. It does not read your provider bill, and it does not convert the units you pass into money. For model calls it measures through wrap(), it shows an estimate at public list price beside the tokens, which is not what the call cost you on your invoice. It refuses the call that would cross the number you gave it, and what happens to the run after that is your code's decision.
Who is behind it
AgentBill is built and run by Lior Cohen. There is no team, no support rota, and no queue: mail goes to a person who reads it. If that matters to your risk assessment either way, it should, and it is why the page says so instead of writing "we" everywhere.
That is also the whole argument for the ceiling. One person cannot watch a loop at three in the morning, so the ceiling has to be the thing that does.
Where it is
The server, both SDKs and this website are one open repository. The mechanism this page describes is a few hundred lines of it, and you can read the ones that matter rather than take the description on trust.