Hard Budget Caps: The Off Switch for Agent Operations

There is one kind of email nobody wants to read: sent at midnight because a service kept running, and the numbers kept growing while everybody slept. On October 3, 2026, Simon Willison packed this exact spot into a clear argument, and his demand reads like an operating manual: pay-by-usage services above all need default hard budget caps. Once the limit is crossed, they should return errors instead of results, no exceptions. I have been running agents whose scarcest resource is not dollars but requests, and that is why I read his post not as a cloud column but as an instruction for my own operation. The good news: the movement is underway. At AWS and Google Cloud, spend limits and spend caps stand in this year's official announcements, not on wish lists.

Some context: I run the HUNTER cyberdeck on a used Google Pixel 6a, bought for 45 euros, carrying a gateway with agents, cron jobs and the Telegram bridge. Codex, pi and other agents of my small agent family sit next to it on separate machines; I orchestrate between them instead of typing code. In this setup I do not pay by the dollar but by the request: model access through the cloud comes as a five-hour window with a weekly cap. Whoever works this way sees costs differently: every request an agent fires on its own is one missing from the window.

Willison separates two kinds of limits. A soft cap sends a warning mail after the threshold and keeps running merrily. A hard cap cuts the connection: after X dollars per month, the project's services return errors instead of results. For the risk-hungry he proposes a visible checkbox, roughly worded like this: remove the budget cap, I take responsibility for the charges that follow. The usual counterargument, that businesses would hate services throwing errors mid-month, he answers soberly: most people and companies prefer errors to a surprise amount, because an error is restartable and a bill is not. Willison also names the fear that keeps people away from AWS: they avoid private projects entirely, because a runaway service can ruin them, and he counters that people have really been caught by this, not only in their imagination.

Agents sharpen this spot more than any classic software, because they widen the distance between starting something and checking on it. A script runs until it is done, and its author roughly knows what it does. An agent loop decides while it runs: it creates services, uses credentials, fires off further jobs, and asks nobody in between, because that is the whole idea of an agent. If such a loop lands in a project that may bill without limit, the real question is not whether something goes wrong but only whether it happens on one evening or one weekend. My agent family knows this logic from its own building work: two verified projects came out of it, 36 of 36 tests passed, and not one line of code came from my hand, it came from agents while I orchestrated. Had the operation of those projects billed in an uncapped environment, the interesting part would not have been the achievement. It would have been the question of why the bill had grown beyond every expectation. Keeping that question from being asked at all is exactly what a cap is for: the risk stays possible, but it must be signed for consciously.

At AWS this is now in black and white. The announcement of September 16, 2026 describes the new builder experience, and one paragraph carries the essence: once you upgrade to a paid plan, you can set a monthly spend limit for your project based on your usage patterns, so that you stay within budget. When usage reaches the limit, the project pauses for the rest of the month. Alongside comes the option to create additional projects with one click, each with its own limit and its own team members. Honesty belongs in here, because the story has one big but attached: the documentation page for the spend limit warns that the new experience is currently rolling out to a limited number of customers. That makes the trend the news, not the fleet-wide overhaul. And the trend did not start at AWS but a few weeks earlier.

Google Cloud moved first. On July 28, 2026 the cost management team announced two pieces inside the billing console: early anomaly detection for AI services and spend caps on budgets. The early-warning half builds a baseline of historical daily costs per service without manual configuration, watches early signals before full billing shows them, and delivers a root cause analysis that names the three driving stock-keeping units when a deviation appears. The cap half sets a monthly limit per service inside a project. The sentence describing the root of the problem stands in the same post: a single five-word prompt can trigger complex operations and real costs, and classic metrics like requests per second no longer help you estimate the bill. Exactly that sentence applies unchanged to my request-based world, only in my case the currency is called request rather than dollar.

My own watchdog trail is accounted in requests instead of dollars, but the structure of the limit is the same, and it is measurable. Since moving mechanics into scripts, the numbers live on a page: fetching the transcript of a 54-minute video, 72 kilobytes of text, 12,917 words, ran on September 5 at zero requests, because a Python script does that work. Reading and summarizing the same material in a model dialog cost about four requests, a tiny fraction of the five-hour window. Derived from my dashboard, one window holds roughly 800 requests and the weekly limit about 2,900. The lesson is uncomfortably concrete: an agent that processes mechanical steps across dialog rounds burns the only currency my operation is truly short of. Scripts are therefore not a style feature here, they are the hard edge of my accounting.

What a cap cannot do belongs on the table as well. First limit: the cap protects against overflow, not against what I hand over voluntarily. When I grant an agent permission for expensive services, the spend until the limit remains part of my plan, and the cap has nothing to object to. Second limit: a cap acts on the billing state, not inside the running minute. An agent loop that runs through an evening collects charges until something checks them, and that is exactly what the second half of Google's set exists for: the anomaly early warning that reports deviating daily costs before full billing arrives. Third limit: limits are an agreement with the platform, no substitute for your own list of the services the agent has left in the project.

Willison's wish remains standing as a rule of behavior: agents should themselves start recommending providers with hard caps, and warn newcomers against uncapped accounts. In my operation this rule is already standard equipment, because the accounts are limited anyway: the five-hour window, the weekly cap. Translated for people building their first projects with agents, it reads: set the limit together with the first paid plan, not after the first surprise, and really read the sentence next to the checkbox. An off switch nobody can find is not an off switch.

What I take from this for the coming months stays unspectacular. The big platforms have started shipping hard limits, a blogger with an audience demands them as the default, and my own operation has shown for months that a limited window is not a deficit but the normal shape of agent work. An agent without a stop button is not progress, it is a bill without a due date. The stop button that this October became a checkbox at AWS and a cap at Google belongs in the standard dialog the moment project number one is created.

About the author: I am Marcel and I run the HUNTER cyberdeck on a used Google Pixel 6a, plus an agent family of Codex, pi and other agents on separate machines. For this post I checked the AWS and Google Cloud announcements at the original sources and used my own measurements from the operation of September 5, 2026. Last reviewed on October 4, 2026.

Sources: Simon Willison, We're going to need default hard budget caps on pretty much everything, October 3, 2026, retrieved October 4, 2026. AWS, New AWS experience helps builders get started and ship faster (What's New, September 16, 2026), retrieved October 4, 2026. AWS documentation, Create a spend limit in AWS Settings, retrieved October 4, 2026. Google Cloud blog, New early anomalies and spend caps on Google Cloud Budgets (July 28, 2026), retrieved October 4, 2026. Own measurements: Pixel cyberdeck operation, dashboard accounting of September 5, 2026, tests of the verified projects.