A cost cap has two failure directions.
Everyone builds LLM cost caps against one failure: runaway spend. But a cap that checks a ledger before every call has a second failure direction, and it's the one that actually bit me — when the bookkeeping over-records, a healthy service throttles itself to death against a ceiling it never really reached. Under-billing loses money. Over-billing loses uptime.
The incident, briefly
A unit bug in cost recording booked roughly 100× the real spend — about $0.43 of actual daily usage written to the ledger as ~$45. Against a $50 daily ceiling, the cap did exactly what it was told: it tripped, and every AI surface degraded for users who had spent cents. The full writeup is on dev.to; this post is the design that came out of it.
Rule 1 — The cap is in the request path. Treat it like it.
A cap that consults a ledger before every paid call is a runtime dependency with the same blast radius as your database. It needs what your other dependencies get: tests on its arithmetic (including sub-cent rounding, where our bug class lives), alerts on trip, and a documented answer for "the ledger is unreachable" — in Klorn's case, fail closed: a call whose cost cannot be recorded must not happen. That rule is a comment in the guard's source and a test, not a wiki page.
Rule 2 — Record in billing's own units
The 100× bug was a currency-scale mismatch between what the provider charges and what the ledger stored. Record cost in the exact unit and rounding the invoice uses, convert at one boundary only, and property-test that boundary. Every unit conversion inside a money path is a place this incident happens again.
Rule 3 — Tripping must degrade, not amputate
What saved the incident from being a real outage is that the cap sits above a floor: with the LLM blocked, a deterministic keyword path still produces the same four features and mail keeps classifying — worse (82.1% on the committed set, urgent recall 46.2%), but visibly worse, with misses landing in the visible queue rather than vanishing. When the provider comes back, a bounded sweep re-judges what degraded. A cap you can hit without a degraded mode underneath is a self-inflicted denial of service with a billing UI.
Rule 4 — The user's ceiling is a promise; keep it boring
Klorn's pitch includes "it stops rather than overspends," which means the cap can never be quietly widened to paper over a bookkeeping bug. The ceiling stays fixed; the engineering burden lands where it belongs — on making the meter honest. If your product makes the same promise, budget for the meter being the hard part.
Numbers in this post re-run from the repo (pnpm eval:judge with no provider key measures the degraded floor). The guard, its ledger and the rounding tests are AGPL: github.com/k08200/klorn.