A warning is not a cap: hard budget caps that actually stop agent spending in vibe projects

Drawing the boundary first: this is not "how to read the bill," it is "how to make the bill stop"

This site's cycle92 guide, on AI bills for vibe developers, covered reading pricing, accounting for costs, and choosing plans by volume. This guide covers a different layer: when costs are already out of control, what mechanism stops them before they cross a line you set, rather than revealing the damage in next month's invoice. Reading the bill is bookkeeping. A hard cap is a brake. Both are necessary and neither substitutes for the other: the clearest invoice cannot stop an agent stuck in a loop at 3 a.m., and a hard cap set without a cost baseline is a number chosen by feel. So this guide assumes you already know roughly what you spend each month and where the money goes — which model, which task. If you do not, go back to the cycle92 guide, get the books straight, and then come back to set limits.

The other neighbors to separate: cycle100's two guides covered data-access guardrails (what data an agent may touch) and poisoned-dependency containment (what to do in the 90 minutes after something bad ships). This guide covers what an agent may spend. All three are the same "give the agent rules" idea applied to different dimensions, and they do not overlap.

What a hard cap is: stop at the line, not warn at the line

Pin the definition down first, or everything after it stays fuzzy. A soft cap is: at $X spent, send an email or a notification, and the task keeps running. A hard cap is: at $X spent, the running task is paused or new calls are refused, a clear error is returned, and resuming requires a recorded human approval. Simon Willison's October 3, 2026 post, "We're going to need default hard budget caps on pretty much everything," uses exactly this definition, and argues hard caps should be the default, with customers explicitly opting out if they accept overages — not the other way around. His argument is simple: most people would rather have a service pause than receive a surprise bill above $10,000. The post was widely shared in October not because it was novel, but because it named a shared experience: warning emails are read in the morning, but the money was spent overnight.

Cloud vendors are moving in this direction, but none has reached "default" yet. Google Cloud launched Spend Caps in July 2026: a monthly monetary cap on specific services within a project, still in public preview and covering one project and service at a time. AWS launched spending limits around September 16, 2026: set a monthly spend limit for a project, and the project is paused for the month once usage reaches it, still in a limited rollout. Both features exist, but neither is on by default and neither covers everything. For an independent developer, waiting for vendors to cover you by default is unrealistic. Your own runner needs its own cap; the vendor-side cap is only the second layer.

Three layers of caps: per-task, per-day, per-month — miss one and you leak

Setting only a monthly total is the most common shortcut and the easiest to leak through: one task can burn the whole month's budget in a day, and a monthly cap only fires at month's end, which is to say it never fires in time. Setting only per-task caps leaks the other way: ten parallel tasks each stay under their own line while their sum blows past any sane total. Caps need three layers, each catching a different failure mode:

• Per-task cap: the maximum tokens or dollars one task may spend. This catches the single task stuck in a loop, retrying forever, or accumulating an ever-growing context. A starting point by reverse calculation: take your most expensive normal task from the last three months and multiply by 1.5 to 2. Below that, you will kill legitimate tasks. Above it, the cap means nothing.
• Per-session / per-day cap: the cumulative maximum within a day or a project. This catches "parallel tasks times N" and "opening new sessions all day," both invisible to per-task caps. Parallelism belongs in the formula: divide the daily cap by the number of tasks you usually run in parallel, then derive each task's daily allowance from that.
• Monthly / organization cap: the maximum for a whole account or project in a month. This catches slow, long-term overspend and the case where several people share one pool without knowing it. For teams, add one more split: separate pools per person, per project, and per client. A shared pool should cover only shared overhead, so one client's runaway task cannot eat everyone's budget.

The layers need a clear priority: a per-task trigger pauses that task, a daily trigger stops new tasks for the day, a monthly trigger stops all non-critical tasks for the month. The error returned on trigger must be legible to both agent and human: "Task budget exhausted (limit X, used Y). Task paused, awaiting human approval to resume." A vague "call failed" will be treated by the agent as an ordinary error and retried — and retries themselves cost money.

Enforcement must happen before the call: "don't spend too much" in a prompt is not a control

This is the guide's most important technical judgment: budget control must be enforced before the actual call (pre-flight), by the runner or gateway — not written into a prompt, a system instruction, or discovered in a post-hoc reconciliation. A prompt instruction like "be mindful of cost" is advice to the model. Under task pressure, the model will prioritize finishing the task and ignore it. Post-hoc reconciliation, however clear, cannot unspend money. There are three enforcement points worth ranking by reliability. First, vendor-side caps (AWS spending limits, Google Spend Caps, model vendors' own usage caps), enforced by the party billing you — hardest to bypass, but incomplete in coverage and sometimes too coarse. Second, your own call gateway or runner, checking remaining budget before every call and refusing with a structured error when it is gone — the layer most worth investing in, because it covers every model and every entry point. Third, agent-framework settings (maximum steps or tokens per task), useful as a supplement, never as the only defense.

A minimal pre-flight check looks like this, in pseudocode deliberately independent of any vendor SDK (copying one vendor's call pattern would be wrong for the others): before initiating a call, read the current task's spent cost, the day's spent cost, and the month's spent cost. If any of the three has reached its cap, refuse the call with a "budget exhausted" error and write an audit log entry carrying the task ID, the triggered layer, and the used-versus-limit figures. If no cap is reached but usage has crossed the 70% or 90% thresholds, let the call proceed but fire an alert, so a human sees it during the day rather than in the month-end invoice. The 70% and 90% thresholds serve different purposes and must stay separate: 70% means "pay attention," 90% means "prepare to stop," 100% means "already stopped." A single 100% threshold merges warning and braking into one event.

The circuit breaker's three states: how you come back matters more than how you stop

Borrow a mature model from electrical engineering: a circuit breaker has three states — closed, open, and half-open. Closed is normal passage. Open is refusing all new calls after the line is hit. Half-open is admitting exactly one probe task during recovery: if the probe passes, recovery proceeds gradually; if it fails, the breaker reopens and the wait extends. Many teams design only the first two states, and the result is predictable: a human clicks "resume," the runaway task comes back at full strength, hits the cap again within half an hour, and the cycle repeats. In half-open operation, an approved recovery first admits a single minimal probe task — a read-only, low-cost call — confirms that cost metering is sane and task behavior is sane, and only then releases queued tasks one at a time by priority. The task that triggered the cap stays suspended on its own: before it resumes, a human must first look at what it was looping on.

Recovery approval itself needs rules: who may approve, how much one approval releases, and how long it stays valid. The most common failure is a resume button with no approval at all, or approval by the same person who triggered the spend — a cap the spender can lift at will is no cap. For a solo developer, "the approver" is you, and the rule simplifies to one line: before resuming, read the triggering task's log and cost breakdown, confirm the cause of the runaway is fixed (the loop removed, the bad prompt replaced, the parallelism switched off), and only then click resume. A resume without reading the log is indistinguishable from having no cap.

Team versus solo: split the pools, do not share one

A solo developer can run on three cap layers plus pre-flight checks. Once multiple people or multiple clients are involved, add three more practices. First, split the books: separate pools per person, per project, and per client, with the shared pool covering only shared overhead. Otherwise one person's runaway task eats everyone's budget, and the victims find out at month's end. Second, reserve: carve a reserve out of the monthly budget first for tasks that cannot stop (deliveries already promised to clients), and let the breaker cut only the remainder. Otherwise a monthly trigger halts promised deliveries along with everything else. Third, a closing cadence: one fixed day per month to review costs against the month's per-task, per-day, and per-month trigger records, and adjust the numbers once. Caps are not set-and-forget constants. They should move with your task scale and model prices: when models get cheaper, caps can come down; when tasks get more complex, per-task caps must go up. A cap unchanged for six months will either kill legitimate work or stop meaning anything.

The six most common pitfalls

• Caps only in the UI, with the API wide open: a "max $X per month" label on a frontend button means nothing if scripts, CI jobs, and other people's calling code bypass that UI. The enforcement point must be the gateway or runner, not the interface.
• Retries and cache misses billed again: failed retries, cache misses, and context retransmission all generate extra calls. Budget metering must count calls actually made, not calls planned.
• Parallel tasks multiplied by N: a per-task cap times the parallelism count is the real daily exposure. Daily caps must be discounted by parallelism.
• Test and production sharing one pool: a runaway test task should not stop production work, or vice versa. Separate pools; the test pool's cap can be tighter.
• Resume buttons without approval: see the circuit-breaker section above. Recovery requires one human confirmation after reading the log.
• Counting model tokens only: sandboxes, vector stores, search APIs, browser automation, and CI minutes can all be side costs of an agent task. The budget's scope must cover all of a task's external calls, not just the model bill.

A one-week rollout plan: from inventory to drill

A schedule you can follow directly. Day one: inventory every spending entry point — editor plugins, CLIs, CI jobs, background services, other people's scripts — because enforcement must cover all of them, and one missed entry point means no cap at all. Day two: switch on vendor-side caps (AWS, Google Cloud, or model-vendor usage caps) as the second line of defense. Day three: add pre-flight checks to your own runner or gateway — three cap layers, 70%/90% alerts, 100% refusal, audit logs, all of them, not a subset. Day four: set alert channels — 70% to somewhere you will definitely see during the day (not an email folder nobody reads), 90% to somewhere your phone can reach. Day five: run a breaker drill — temporarily set a per-task cap very low, run a normal task, and verify that it actually stops at the line, that the error message is clear, and that the recovery flow works. The day the drill passes is the day your hard cap is really live. Before the drill, it is only a wish written in a document.

The budget-scope checklist: what else to count besides model tokens

One of the six pitfalls above — counting model tokens only — deserves expansion into a full scope checklist, because every cost category left out of the budget makes the cap that much more fictional. The first category is AI calls beyond the main model: vector-store queries, reranking, search APIs, image and speech models, and reviewer models (a second model checking the first model's output). Many of these do not appear on the main model's bill, but they all belong to the task's cost. The second category is execution-environment cost: sandbox and virtual-machine time, browser-automation session time, CI minutes, test-environment cloud resources. These usually bill by time rather than by token, and a runaway task burns them no slower than tokens. The third category is data and storage cost: intermediate files, snapshots, logs, and vector-index writes produced during a task. Some bill by volume, some by retention time; individually small, they add up over long runs. The fourth category is retries and waste: failed retries, cache misses causing duplicate calls, context retransmission. These are not "business costs," but they are the most common cost amplifiers in runaway tasks, and budget metering must count calls actually made, not calls planned.

Once the scope is set, two operational practices follow. First, a single metering ledger: every cost category rolls up into one budget book, instead of model bills, cloud bills, and search bills each keeping their own totals — separately kept books never reconcile. Second, a sentinel metric per category: for example, check weekly what share of total cost is non-model cost. If that share jumps suddenly from a tenth to three tenths, some task is spending heavily outside the model, and it deserves its own investigation rather than waiting for the monthly cap to trip. Many teams' budget blowouts trace back not to expensive models but to non-model costs that never entered the budget table at all. Put the scope checklist on the first page of the budget document, and every time a new external service is connected, ask first "which scope does its cost enter" — that habit saves more money than any post-mortem.

One line to close: a soft cap tells you the money is gone; a hard cap guarantees the money cannot all go. The more capable agents become, the more that distinction matters — because a capable agent goes out of control faster, and it keeps working while you sleep.

Caption: A real photograph of circuit-breaker switches in a distribution board, an analogy for the "trip at the line" hard-cap mechanism — a generic electrical photo, not a screenshot of any vendor's billing interface.