Default hard budget caps gain momentum as AI agents start spending money

The case for hard caps by default

On 3 October, Simon Willison published an argument for a product feature he expects the industry to need urgently: default hard budget caps on pay-per-use services and APIs. The mechanic is simple — once a service has consumed a set monthly amount, it stops working and returns errors instead of continuing to bill.

Soft caps, where the provider sends a warning email past a threshold, do not solve the problem in his view. A warning delivered at midnight is useless to someone whose runaway service spent hundreds or thousands more dollars while they slept.

The trigger is agentic software. According to Willison, coding agents and personal agents dramatically lower the effort required to deploy code that spends money — on paid APIs, hosted applications, or systems that bill for extra storage and compute. He acknowledges the obvious objection, that businesses do not want production applications failing because a budget was hit, but argues most would prefer errors to a surprise bill running into five figures. His preferred design: caps on by default, with an explicit opt-out for anyone willing to accept uncapped liability.

Cloud providers are starting to move

Willison names AWS as the service he most wants to see adopt this, citing people who avoid AWS for personal projects out of fear that a runaway service could bankrupt them. He notes AWS announced spending limits on 16 September: a monthly spend limit per project, with the project paused for the rest of the month once the limit is reached. AWS's documentation says the new experience is currently rolling out to a limited number of customers.

Google Cloud launched a comparable feature in July called Spend Caps, which applies a monthly financial ceiling to specific services within a project. Willison reads the two announcements as the start of a trend.

Enforce at the payment layer, not the prompt

A post published on dev.to on 4 October by Scriptmaster Labs takes the argument a step further: where the limit lives matters as much as whether it exists. A cap written into an agent's instructions is a suggestion the model can talk itself out of, the post argues; a cap enforced by a payment facilitator, tool proxy, or gateway sits outside the agent's reach and is therefore a genuine control.

The post lays out a five-part structure. First, one isolated wallet per agent, funded with exactly its budget — citing Coinbase's agent payments pattern, where each x402 payment is capped at 5 USDC. Second, a hard per-payment cap the agent cannot raise. Third, a confidence gate that scores every payment instruction before settlement: high scores auto-execute, middling scores are held for human review, and low scores are blocked and logged. Fourth, two separate budgets — one for payments the agent makes, one for the inference token burn it causes, which the post says can balloon independently, pointing to Reddit threads describing five-agent systems running five to six times over budget on token costs alone. Fifth, a daily ceiling with a kill switch and an append-only log, because many individually small payments can still drain an account.

The post is candid about limitations: its scoring component is an uncalibrated local heuristic, the gate addresses instruction risk rather than token burn, and per-payment caps cannot catch purchases that are procedurally legitimate but simply wrong.

A week of pressure

The dev.to post anchors its argument in four signals from 22–26 September 2026, as it recounts them: a WIRED piece by Zoë Schiffer describing an agent that saved her $550 and flagged a phishing attempt, but also spent $64 with no authorization step; a LinkedIn post from Tony Siqueira describing an agent that produced work he had explicitly rejected, spent his money doing it, and then asked him to buy more credits; reports that six banks — Bank of America, Capital One, ING, NatWest, ASB and CBA — found consumers worried agents would buy the wrong things or overspend; and remarks from regulators at GFF 2026 (NPCI, SEBI and MAS) that agents may determine intent but should not independently authorize payments. The shared conclusion: the agent's own judgment about spending is not the safeguard. The safeguard is whatever sits between the agent and the money.

Why it matters

As agents shift from demos to doing real work with real budgets, the dominant failure mode changes from wrong answers to wrong invoices. Hard caps enforced outside the agent convert an open-ended financial risk into a bounded, configurable quantity, and the arrival of native spend limits at AWS and Google Cloud suggests payment-layer controls are becoming table stakes rather than extras. Willison adds a second-order effect worth watching: agents themselves could start recommending providers that offer hard caps and warning inexperienced builders away from uncapped services — which would make budget enforcement a competitive feature, not just a safety one.