Pay-by-usage services should ship with default hard budget caps - a real cut-off that returns errors after a set monthly amount, not an email nobody reads at 2am. That is the argument Simon Willison makes in an October 3 post, and it is the most practical piece of agent safety advice published this week: the failure mode he describes is not a compromised agent, it is a bill.
Key facts
| Fact | Detail |
|---|---|
| Question answered | Agents Need Default Hard Budget Caps, Not Warning Emails |
| Short answer | Simon Willison argues that pay-by-usage services need default hard budget caps - a real cut-off, not a warning email. |
| Reading time | ~3 min |
| Last updated | 2026-10-05 |
What the post argues
The core distinction is between two things that sound similar and behave nothing alike:
- A soft cap sends a warning email after you cross a threshold. The service keeps running.
- A hard cap stops the service and returns errors. Spending stops with it.
Willison’s framing is blunt: “These need to be hard limits.” The scenario he wants to prevent is the one where a service quietly consumes hundreds or thousands of dollars overnight, and the first signal is a midnight email explaining that a limit was reached.
He also names the objection and answers it directly. Products resist hard caps because customers do not want a hosted application to start failing because a budget line was crossed. His response: most businesses and individuals would rather see an error than a surprise bill of that size. The proposed default is caps on, with removal as an explicit opt-in — a prominent checkbox along the lines of “Remove the budget cap.”
Why agents change the arithmetic
Language models did not create metered billing, but they changed how quickly a person can arrive at it. Coding agents and the friendlier “personal agent” wrappers collapse the distance between an idea and running code. That code can call paid APIs, provision hosted infrastructure, or write to storage that bills per gigabyte.
Analysis, not fact from the post: the risk profile of that setup is unusual because it is asymmetric in time. A person experimenting at their desk notices a costly loop in minutes. An agent retrying a failing call in a loop at 3am does not. The expensive run is exactly the run nobody is watching, which is why the cap has to be enforced by the platform rather than by discipline.
How to approximate hard caps today
You cannot force every vendor to add the feature, but you can build most of the protection around a desktop agent now:
- Separate API keys per purpose. One key per agent or project means one budget to zero out, and a compromised or looping agent cannot drain the key you use for something else.
- Set the provider’s spending limit where it exists. Several providers offer per-project or per-account usage limits; a limit that returns errors when hit is the closest thing to a hard cap on the market.
- Cap the agent’s own loop. Maximum iterations, maximum tool calls per task, and a timeout are cheap to add and they bound cost even when the model misbehaves.
- Require confirmation for anything that provisions. Creating infrastructure, upgrading a plan or starting a paid job should be an explicit approval, not a silent side effect.
- Watch cost per run, not just the monthly total. A per-task budget surfaces a runaway loop on the day it happens.
- Prefer local execution for the wasteful parts. Work that would otherwise burn metered inference - reading folders, summarizing documents, retrying a transformation - costs nothing per token when the model runs on your own hardware.
That last point is the reason local-first matters beyond privacy. MOOGH runs the agent on your own machine, so the parts of a task that are expensive because they are repetitive can be done without a per-call bill attached. You can Download it and watch what a task actually consumes before putting it on a schedule.
The takeaway
“Add a hard cap” is a one-line feature request with an outsized payoff, and it will not be available everywhere on day one. Until it is: separate keys, provider limits, loop bounds, confirmations before provisioning, and local execution for the repetitive parts. Then email the tools you pay for and ask for the checkbox.
Related reading: