The Kill Switch Arrived Blank

AWS later agreed to reduce the charge to $1,894, by the operator’s own account, and whether any of it was ever paid is not recorded publicly. The dollar figure is small, and it is not the point. This is: asked what went wrong, the operator wrote, “The mistake was not human but because of the agent, next time a better agent needed.”

One hobbyist on a volunteer network tells you nothing about how often this happens inside companies, and we are not going to pretend otherwise. We are using it for one thing: it is a clean case of spending authority handed over with nothing attached to stop it, and a ceiling would have bounded the bill regardless of how smart the agent was, which is what “next time a better agent needed” does not account for.

The cutoff exists now, barely

On October 3, Simon Willison argued that default hard budget caps now belong on pay-by-usage services generally: the ability to say “after $X/month, cut this thing off and return errors.” Soft caps, the warning-email kind, “will not cut it,” the post says, and it expects “most businesses and individuals would prefer errors to a surprise $10,000+ bill.” The Hacker News thread that followed is worth reading for the arrangements operators describe making on their own.

Three examples, not a survey. Google Cloud announced spend caps on Cloud Budgets on July 28, in preview, restricting further cost-incurring usage for a service in a project once the month’s cap is reached. AWS now documents spend limits in AWS Settings, a per-project monthly ceiling on pre-tax costs with notifications at 50, 75 and 90 percent, though the page warns the new experience is still releasing to a limited number of customers. On the model side, Anthropic’s API carries monthly spend caps by tier, you can set your own limit below the tier cap, and you can give a single workspace its own limit.

Go set those wherever a pause would not hurt you: sandboxes, side projects, the key an agent is holding. Setting them costs nothing and this article does not improve on it. For anything a customer touches, the answer is different, and the vendors say why themselves.

The box is blank on purpose

AWS’s documentation is unusually honest about what it is handing you. Spend limits “are designed for experimentation, learning, and sandbox workloads. They can be used for production environments when it is acceptable to have a brief pause of your resources in cases when your applications incur unexpected costs.” When the limit lands: “AWS pauses your project and stops all resources.” Data is preserved, some resources need manual restarting, and the page adds a clause worth a calendar entry: “If you take no action within 90 days of your project being paused, AWS permanently deletes your project data.” The optional earlier controls are graded by how much they hurt, and the strongest pauses your top cost drivers across EC2, RDS, Lambda, Bedrock and SageMaker, which the documentation itself calls “a disruptive experience.”

Google’s version is gentler and narrower. It calls itself non-destructive, and fixed commitment fees such as Committed Use Discounts or Provisioned Throughput “will continue to bill at their flat contractual rate” after the cap pauses usage, so the floor of your bill survives the cap. The preview covers four services: Gemini API, Agent Platform, Cloud Run and Cloud Run Functions. Everything else in the account bills the way it always did.

So should you put a hard cap on production on the strength of this? No. AWS is telling you the feature targets sandbox work and fits production only where a pause is acceptable, and a cap set without deciding that is a self-inflicted outage waiting for a quiet weekend. On the systems a customer touches, use the alert thresholds, put the hard ceiling around the pieces that can actually run away, and decide now who gets woken. The mechanism is real, the coverage is partial, and both vendors ask for a number that neither of them can know.

What the number is made of

Two numbers, and they live in different parts of your business. The first is what a normal month of this workload costs, which is in your last three invoices and nowhere else. The second is what an hour of this workload being stopped costs you, which is in no invoice at all. A cap set without the first trips on a busy Tuesday. A cap set without the second quietly decides that an outage is cheaper than an overage, on your behalf, at whatever hour the threshold happens to land.

AWS will show you its own arithmetic for the first one. It sets a floor at “the greater of $20 or a conservative estimate of your likely spend,” built from your month-to-date activity, the resources running now, and your prior month, because “hitting a spend limit is a disruptive experience.” The version we would run on your own records is not AWS’s formula but it borrows the shape: the highest of your last several invoices for that line, plus the largest month-over-month jump you have actually seen on it. Treat that as our rule of thumb rather than a tested one, because we have not run it against a catalogue of real incidents and neither has anyone else we can point you to. We will not hand you a multiplier, because the headroom you need depends entirely on the second number.

If neither number is at hand, look at where each one lives. The usage pattern sits with whoever watches the console. The cost of an hour sits with whoever answers for revenue. Nothing in a billing console puts those two in the same room, so if they are two people in your company, that introduction is the first step. If they are both you, the step is just deciding.

A monthly cap is the coarse control

Here is what the DN42 write-up actually records about timing. The agent ran for close to 24 hours before its operator noticed and killed it, and what finally got their attention was the charges landing on their credit card. A monthly project ceiling is a strange instrument against a burn that size. Monthly caps are built for the slow leak: the forgotten instance, the crawler, the job that grew. What bounds an agent told to hurry is the scope of what it was handed, so scope that too. Give it its own project, billing account or workspace, with its own limit, funded on purpose, rather than the key that reaches everything. Where a provider sells prepaid credit instead of billing you afterward, the balance you loaded is already a ceiling, and leaving auto-reload off keeps it one.

The part that is yours either way

Pull a list of every line in the business that bills by consumption and has a payment method attached. Cloud accounts, model APIs, anything metered inside a SaaS plan, and your telephony minutes.

For each line, write the normal month and the cost of an hour stopped. Set the vendor cap where one exists, at a level you chose for a reason you wrote down. Where no cap exists, build the ceiling structurally. The thread kept reaching for electricity to explain why that works, and a commenter posting as handoflixue named the reason: your wiring has “a hard physical limit on how much electricity you can use before you blow out the fuse box.” Software shipped without one, so you install it: a separate billing account, a dedicated card with its own limit, a key that can only reach a budget you funded.

Then settle, while nothing is on fire, who is allowed to raise a cap and what evidence they owe before they do.

If an engineer or an MSP already owns your cloud bill, this is their work and handing them this page is the whole engagement. The inventory and the caps are not worth paying anyone for. If they are also the ones in the room every month, the standing decision below is theirs too, and you should hold them to it rather than buy it twice. If nothing in your business bills by consumption, you do not have this problem, and the exercise is the science project you were right to refuse.

The defaults still point the other way, with caps opt-in and coverage partial, so nobody is going to fill in your number for you, and the number is a standing decision rather than a setup task. It gets revisited every time a workload grows, an agent gets a new key, or a threshold trips at an inconvenient hour. That is the part we are for, not the inventory above. Our own compute never reaches your invoice. Our claim about that, and it is a claim rather than a proof, is that it puts the incentive to spend less of it on our side of the table. The only way you can check it is the one we would tell you to use on any vendor: what shipped this month. Your vendors’ bills stay in your name either way. What the raise-it-or-let-it-stop call wants is a standing owner, and if that is nobody in your building yet, it is what we do.