An alert is an email, a cap is a breaker: one builder's cap that fired and the five-layer stack he recommends
source re-read 2026-10-27
Why this label: One builder's own project and opinions in a blog post that ends with a newsletter pitch. The Supabase numbers are his; we have not checked them and reproduced nothing. We did not read Simon Willison's post directly, only the article's description of it, so its claims about AWS and Google Cloud limits are second-hand.
- Tried
- Rely on provider billing alerts to catch a runaway cost, and add hard caps only after the first scare.
- Broke
- HelloBuilder's own Supabase project used 8.21 GB of bandwidth against a 5.5 GB allowance on 25 September, and requests were dropped until the quota refilled on 2 October. The author says there was no surprise bill, but the database stopped answering for a product with one signed-up user. The cause was ordinary: list pages pulled content bodies they never displayed, CMS pages rebuilt more often than needed, and images were not cached for long.
- Cause
- confirmed Wasteful list queries, frequent CMS rebuilds and short image caching used the bandwidth (the author's account).
- suspected The author's general argument is that alerts arrive after the money is gone and agents remove the friction that used to slow spending. That is his opinion, though he cites Simon Willison's 2026-10-03 post on default hard caps; we have read it only through this article.
- Fix
- The author's fix for his case: lists stop pulling bodies, CMS pages rebuild hourly, and images are cached for a month. His general stack, from outside in: a hard spend limit at the account, one API key per project and ideally per agent with its own limit, a maximum turns and spend per agent task (he points to
--max-turnsand--max-budget-usdin Claude Code's CLI reference), per-user quotas on endpoints that call paid APIs, and alerts at 50% and 80% of each cap. His own caveat: a cap turns a billing problem into an availability problem, so choose per service whether you would rather pay or go down. - Prevention
- Write down, for each service with your card on file, whether it has a hard cap, only an alert, or nothing, and lower one cap on purpose to see what your product does when it fires (the author's own audit step).