For most of July, the spending limit in our chat box did nothing. You could type 15 cents into it and nothing on our side would read the number. We found out by checking our own published examples. On 30 July, five of them had run with the field set to $0.15. Four receipts came back between $0.50 and $0.62 on Auto, bunched just above a 50-cent ceiling nobody had been shown. The fifth finished early, at $0.08 on Auto. We repaired the limit in August, and on 3 October a $5 limit stopped one of our runs for real; more on that below.
On 3 October Simon Willison argued that pay-as-you-go services need default hard budget caps on pretty much everything. "These need to be hard limits," he wrote. "Soft caps, 'after $X/month, send me a warning email', will not cut it." He was mostly writing about cloud services that agents set up. The point lands harder on a product where the agent is the meter, and every step it takes is a charge on your balance.
A contractor you hire for a job does three things without being asked. You get a quote with a figure they won't go past, a phone call before they go past it, and an invoice with lines on it. We think software that spends money for you owes you the same.
So here is the rule we try to build to, and fail in places we will name: an agent that spends your money should state the most it will spend before it starts, stop and ask when it gets there, and give you an itemised bill for every step, including the steps that failed.
A ceiling catches disasters; only a receipt catches waste
The two halves of that rule are different tools. Two runs on the same morning showed us why.
The first is the one we wrote about in our essay on pricing by the job. On 3 October a re-run of one of our own examples, a six-slide deck, finished the deck and then failed to hand the file back, over and over, 21 times. It ran until a $5 limit stopped it, with a bill of $5.08 on Max. Without the ceiling, the next thing to stop it would have been a 30-minute clock or an empty balance. The ceiling did its job. You can watch the replay.
The second run is the one that changed how we think. Two hours later we re-ran a small research job whose request began "Short, tight research job — keep it cheap." It read two pages, wrote a comparison table on renting versus buying a home broadband router, and saved the file. Then it hit the same kind of hand-back fault and kept retrying. The receipt was $0.67 on Fast. When we lined up the billed steps against the moment the file was written, about three-quarters of that, roughly $0.50 on Fast, came after the work was already done: 16 of its 23 model calls.
No sensible ceiling catches that; this run never came near one. The waste was visible only in the itemised record, a time on each line. A total alone, $0.67 on Fast, looks like a normal price for a normal job. That run is still on our examples page, with a note that the file was written but never handed over.
So the ceiling is for the night something goes badly wrong. The receipt is for every other day.
A hard stop is the wrong tool when it is set too low
The strongest case against all this goes something like: a stop at the worst moment leaves me with half a spreadsheet. I would rather pay forty cents more than start again. And a bill with twenty lines on it is homework I didn't ask for. Willison states the business version himself: companies don't want their applications "to start throwing errors because some budget was exceeded."
The first half of that is right, and we learned it the expensive way. In July the chat limit opened at $0.15. We raised the opening value to $1 on 7 August and to $5 on 10 August, because ordinary multi-step work kept running into it. Our own note on the change says the first number people met was "one they had to fight rather than one they could work with." The field now refuses any stated limit under $1, whichever engine runs.
AWS reached the same place from the other direction. Its new monthly spend limit has a floor: "the greater of $20 or a conservative estimate of your likely spend," because, in its own words, "Hitting a spend limit is a disruptive experience." A ceiling set where normal work lands is a tax on normal work.
We also concede some of the homework point. Most people should not have to read twenty lines. On our chat receipts the visible line carries three facts, the amount, the time and the engine, and the per-attempt lines sit behind a hover until you want them.
What we don't concede is that the stop or the lines should therefore go. A stop that keeps what was made, says why it stopped, and offers to carry on is a pause, not a loss. And the lines are where the two loops above were found. The answer to a bad ceiling is a better default, not no ceiling.
The stop lands one step late, and should say so
There is a limit to how hard any of these caps can be. We can't know what a step costs until it has run, so a ceiling can only be checked after a step has been paid for. A run ends at your number plus the step that crossed it. In the deck run that crossing step was $0.08 on Max, the gap between $5.08 and $5.
A chat run that hits its limit keeps what it made, says why it stopped, and ends: "Ask me to continue and I'll pick up from what's already done." Work you hand off has a running total against its own limit, $5 unless you set a lower one first; at the limit the job asks, "Raise it to keep going?" The decision to spend more stays with you.
That check has a hole we would rather state than have you find. It only looks at work that is still going. A handed-off job that finishes in one long push is never checked at all.
Alerts arrive after the money has gone
Troy Hunt's account of being burned by his own cloud bill shows what a soft cap means in practice. After a change to one of his services, large downloads stopped being served from his cache and came straight out of paid storage instead. It ran at "about AU$350 a day for a month" and cost him "over AU$11k". The invoice arrived on 10 January, and with his household ill, "it was another 10 days before I looked at the bill." His fix afterwards was an alert. He runs a well-known security service for a living, and he still wrote: "I should have picked up on it earlier and had safeguards in place."
A monthly bill tells you about a mistake weeks after it started. A receipt per run tells you the same day, and a ceiling stops it in the run. An agent makes the gap worse, because it can repeat a mistake 21 times in a few minutes while you are making coffee.
Even a per-run figure can lag: on one 3 October run the total on screen trailed the final receipt by about a tenth of a cent on Smart, because some charges post minutes after the model's. The live number is a guide; the receipt is the record.
Repetition needs a brake of its own
Both loops share a cause a money limit can't see: the same failing step, retried. On 3 October we bounded it separately. After two failed attempts to hand back the same file, the run stops and says it could not deliver. Later that day the broadband run showed we had missed a case, and we extended the bound to every way the hand-back can fail.
We can't yet tell you it works for anyone but us. We have seen it fire once, on our own account. We only began recording how each chat run ends on 3 October, and that record holds ten runs, all ours, none of which reached a limit. That is no basis for a hit rate, and we won't quote one until strangers' runs give us one.
Where we still break our own rule
Willison's test for a default cap is that removing it should be an opt-in, ideally a checkbox saying you will be "responsible for subsequent charges." We don't meet it. Clear the chat limit field and the run has no money ceiling at all, only the 30-minute clock and your balance, and nothing on screen tells you. The field's own hint offers the blank as an equal choice: "or leave this blank for no limit." A handed-off job's receipt also shows its total without the engine tier beside it, which breaks a rule we hold for every other price we print.
Update, 10 October 2026: a cleared field is no longer silent. The line under the composer now reads "no spend limit" in the warning colour, and clicking it lets you set one. That is a visible warning, not yet the opt-in Willison asks for, so the rule below still counts as one we only half meet.
We have not fixed either yet. Both are in this essay because a rule you only state when you already meet it is not a rule.
Five rules for software that spends your money
- Say the ceiling before the first paid step, in money, and have one on by default. Set it where normal work fits, not where it chokes.
- At the ceiling, stop, keep the work, say why, and ask. Never decide on the person's behalf to spend more.
- Itemise every paid attempt, including the failed ones. A total alone hides loops.
- Bound repetition separately from money. A ceiling catches catastrophe; it does not catch waste.
- Make removing the ceiling a deliberate act with a warning. We failed this one when this was published; since 10 October the warning exists, the deliberate act does not yet.
None of this is exotic. Trades have worked this way for a century, and AWS began offering a hard monthly spend limit to some new accounts last month. By the end of 2027, we expect software that spends money for you without a stated ceiling and an itemised bill to look the way a builder who won't give a quote looks now.
Method note. All runs described are on our own accounts. The five July runs are our published examples as of 30 July 2026, each with the chat limit set to $0.15; exact receipts $0.6169, $0.5102, $0.6027, $0.502 and $0.0819, all on Auto. The deck run on 3 October 2026 billed $5.0796 on Max, of which $4.60 on Max (90.6%) was spent on 21 hand-back attempts; it stopped $0.0796 on Max past a $5 limit. The broadband run on 3 October 2026 billed $0.667180 on Fast across 36 billed lines (23 model calls), which sum exactly to the receipt; 74.6% of the amount, and 16 of the 23 model calls, were billed after the step in which the file was written. The on-screen lag was $0.357870 against a final $0.359005 on Smart. The record of how chat runs end started on 3 October 2026; read on 5 October 2026 it held ten runs, from one account (ours), all ending "answered", none "limit reached". Limit history comes from our change log (opening value $0.15 in July, $1 from 7 August, $5 from 10 August 2026). The behaviour of each limit was checked against our current code and the live app on 5 October 2026. External sources were read on 5 October 2026 from the linked pages.