an agent budget breaker for your ai tooling
a hook that hard-blocks subagent dispatches at 8 per day. installed after a 132-dispatch week burned 85% of a max plan, and what the cap actually taught me about routing.
one week in late may i burned 85% of a max 20x plan. the ledger said 132 agent dispatches in seven days. almost none of them shipped anything. each dispatch feels free in the moment because it is one tool call in a chat window. the bill disagreed. so i wrote a circuit breaker: a pre-tool-use hook that counts agent dispatches by timestamp and hard-blocks the agent tool at 8 per day, with an 80 per 7 days backstop. a second hook prepends live burn stats to every prompt, so the model reads something like 'agent dispatches: 6/8 today' before it decides to spawn another one. there is a bypass: touch a sentinel file and exactly one dispatch goes through, then the sentinel is consumed.
the cap looks like a cost control. what it actually enforces is routing discipline. a 30-day capture from before the cap showed 111 dispatches, and every single one went to the general-purpose agent. i had 64 specialist agents installed. none of them ever fired. one day logged 243 explore dispatches crawling the same directory tree over and over. nothing about the tooling was broken. the reflex was broken. when spawning is free, you never ask whether a shell command answers faster, or whether the code-reviewer agent fits better than the generic one. at 8 per day, every dispatch has to survive the question 'why this agent, and why an agent at all'.
the false-economy lesson came from the other direction. once dispatches felt scarce, the tempting move was to route work to whatever costs the least. i sent lead discovery to a free local model to save tokens. it invented company names with plausible-looking domains. 1 of 12 resolved to a real company. the same task through codex returned 44 of 46 real, verified companies. zero dollars for fiction is still pure waste. the metric that matters is real output divided by tokens spent. tokens alone tells you nothing, and a cheap run that produces garbage is more expensive than the run you were avoiding.
the breaker itself misfired once, and that failure taught as much as the install. headless cron jobs were being counted against the same pool as my interactive work. one legitimate 165-dispatch automation day locked the whole following week. the fix was to exempt headless entrypoints from the ledger, raise the weekly backstop from 50 to 80, and archive the polluted log. the general rule: when a circuit breaker fires, check what it is counting before you raise the limit. automated load polluting a human-discipline metric is a misconfiguration, and raising the cap to accommodate it just deletes the signal.
the whole thing is two shell scripts and a json ledger. no dashboard, no saas. if your ai tooling can spawn subagents, put a counter in front of it for one week and read the number before you decide whether you need the cap. mine said 132. i would have guessed 30. what would yours say?