An alert at 84 percent of a $600 cap means $96 of headroom. What followed the email was roughly $1,396 more in spend, about fourteen times the amount the banner said was left. Moving the threshold to 70 percent changes the size of that ratio and nothing else, because the banner sat in a system that had no way to refuse a request.
The difference between the two code paths is not the arithmetic, it is where the arithmetic sits relative to the network call. In the version the post says almost everyone writes first, the usage ledger is written after the response returns [6], so the freshest number available is always missing exactly the calls that are in flight [c7a]. The reservation version inverts the order. It opens a transaction, takes a row lock on the user's budget, compares spent plus reserved plus the estimate against the cap, and raises a 402 before any network I/O happens [9].
`SELECT ... FOR UPDATE` is doing most of the work here. Twelve workers that would all have read 92 percent in the same second and all passed now serialize instead [10]. That serialization is also the bill. You have installed a per-user lock in front of every model call. If the calls take seconds and the lock is held for microseconds, it is free; if you run thousands of small completions per second against one shared budget row, it is your throughput ceiling, and sharding that row reintroduces the stale read you were trying to kill.
The place I would expect this to break in production is the settle path: commit on success, release in the exception handler [12]. Any exit that misses both leaks a reservation, and a leaked reservation is indistinguishable from spend, so the budget throttles itself until somebody reconciles. Holds need an expiry and a sweeper, and neither is in the sketch.
The behavioral claim deserves the treatment you would give a benchmark table. The post cites Worchel, Lee and Adewole, 1975, in the Journal of Personality and Social Psychology: 200 participants, the same cookie handed over from a jar of ten or a jar of two, with higher value and attractiveness ratings from the two-cookie jar [3], and the highest ratings of all from participants told the supply had shrunk because other people wanted them [4]. That is a rating, not a purchase. For it to transfer to your dashboard, the person reading "16% of your budget remaining" [5] has to be the one who decides whether the job runs, has to decide in that moment, and has to want tokens the way a hungry undergraduate wants a cookie. What actually spent the money in this incident was a retry loop making forty calls in ninety seconds against a one-minute rollup cron [c7c], with the context window growing on every pass [8]. The loop was never going to read the banner.
So the ordering I would defend in review: a hard call ceiling and a token budget per agent run first, because that is a counter and a raise with no ledger involved; the reservation table second, once spend is per-tenant and you need to answer who spent it anyway. The alert keeps its real job, which is telemetry. The post's own description of the soft check is the accurate one: it observes, then gets out of the way, which makes it a very expensive log line [13].
