Parallel Agents Quietly Burn Through Your Quota — A Self-Defense Circuit Breaker When Limits Are Invisible

Halt agent dispatch at a threshold

Once the ledger fills, check before dispatching a new agent whether "today's total exceeds the daily budget." If it does, do not run that job — defer it to tomorrow. This is the body of the breaker.

#!/usr/bin/env bash
# quota_breaker.sh <weight-of-this-run>
# Do not start this agent if the daily budget is exceeded
set -euo pipefail
 
DAY="$(TZ=Asia/Tokyo date +%F)"
LEDGER="$HOME/.agent_quota/${DAY}.tally"
DAILY_BUDGET=60000          # daily approximate budget (tune with measurement)
SOFT_RATIO=80               # above this ratio, stop heavy jobs only (%)
 
WEIGHT="${1:-3000}"
TOTAL="$(awk '{s+=$1} END{print s+0}' "$LEDGER" 2>/dev/null || echo 0)"
PROJECTED=$(( TOTAL + WEIGHT ))
 
if [ "$PROJECTED" -ge "$DAILY_BUDGET" ]; then
  echo "⛔ Breaker tripped: projected $PROJECTED ≥ budget $DAILY_BUDGET. Deferring to tomorrow."
  exit 75   # EX_TEMPFAIL: temporary failure (safe to retry later)
fi
 
SOFT_LINE=$(( DAILY_BUDGET * SOFT_RATIO / 100 ))
if [ "$TOTAL" -ge "$SOFT_LINE" ] && [ "$WEIGHT" -ge 5000 ]; then
  echo "⚠️ Soft-limit zone ($TOTAL ≥ $SOFT_LINE). Defer heavy jobs, allow light ones only."
  exit 75
fi
 
echo "✅ Dispatch allowed (projected $PROJECTED / budget $DAILY_BUDGET)"

The two-stage design is the point. Set a "soft-limit zone" before fully exceeding the budget, and once you enter that zone, stop only the heavy jobs (generation with a browser subagent and the like) first. Light triage and small fixes still pass. This avoids the worst pattern, where a heavy job devours the allowance right before exhaustion and drags down the lighter work that follows.

I return exit code 75 (EX_TEMPFAIL) because this is not a permanent failure but a temporary "busy now, later" signal. The scheduler can read it and naturally re-dispatch on the next cycle.

Split heavy and light jobs to decide dispatch order

With the breaker in place, one more lever helps: dispatch-order design. The daily budget is the same, but the order in which you throw jobs changes how exhaustion plays out.

I stopped front-loading heavy generation in the early morning and switched to interleaving heavy and light jobs. By letting light jobs through before heavy ones build the budget peak, even after you enter the soft-limit zone the light work still runs to completion.

In my setup, where light periodic jobs like AdMob report aggregation share the same allowance as heavy generation of articles and App Store assets, capping heavy jobs at three per day and spacing each about four hours apart made the thin late-day output all but disappear. With the same number of runs, simply spreading dispatch over time stretched the margin before exhaustion by roughly 1.5x in my experience.

Moving from observe-only to production

Deploying straight into a stop-everything configuration risks halting work you actually need when your budget estimate is off. The rollout I follow has three stages:

1. First run the breaker in observe-only mode — record but never stop — for one to two weeks, and measure the running total at which later agents start going thin.
2. Set DAILY_BUDGET to about 80% of that measured value and enable the soft-limit zone (which stops heavy jobs only) first. Only heavy jobs stop here, so light work is never dragged down.
3. After a week of confirming that needed work is not unfairly blocked, enable the hard limit (stop all jobs).

Widening in this order avoids the pitfall of an over-eager breaker killing work you should be doing. I recommend treating the budget not as a fixed value but as something you revisit monthly against measurements.

How to draw a daily token budget

You do not need to nail the budget value (DAILY_BUDGET) on the first try. Run the breaker in an observe-only mode — record but do not stop — for a week or two, and measure the running total at which later agents start going thin. Set the budget a little below that value and the brake engages before you reach exhaustion.

In my experience, concentrating heavy generation in the morning hastened exhaustion, while spreading it on roughly four-hour intervals made the same number of runs less prone to it. That tells me the ledger total bites on the daily aggregate, not an hourly ceiling. Which is exactly why capping the daily total with a budget works better than throttling the instantaneous rate.

In an environment with invisible limits, the more you wait for an external signal, the more your response lags. Count your own consumption, and stop yourself before exhaustion. Inserting this one self-defense mechanism shrinks the "later agents quietly going thin" phenomenon dramatically. Start with the observe-only ledger.