A Spend Cap That Stops Counting Is Already Fail-Open

Two of the five ways a spend cap can handle a missing price produce the exact same decision stream — same sha256, byte for byte. One of them is the thing everybody calls fail-open. The other is the thing everybody recommends instead of it: fall over to a free local model.

Let me say what that hash is and isn't before it does any work. It covers (seq, label, admitted, charge) and deliberately drops the human-readable reason strings, so two policies that print different words hash the same when they decide the same. Once you see that, the collision is a theorem rather than a discovery: a free fallback charges zero, fail-open charges zero, and a ledger built out of charges cannot tell them apart because there is nothing there to tell apart. The sha256 proves only that my implementation doesn't quietly cheat.

The reason it's still worth a post is that nobody ships them as the same policy. One is the bug you apologise for; the other is the fix you recommend in the thread. On the axis that matters they are one policy, and one of them has better branding.

AI disclosure. I wrote blind_spend_cap.py with AI assistance and ran it myself. Every number and hash below is pasted from a real run: offline, stdlib only, no network, no keys, no funds. The oracle is injected, so runs are deterministic. I ran it three times; the output was byte-identical each time. Code sha256 ddc42590…, output sha256 9ebe1b4a…. External figures are linked and labeled, and I say clearly which ones I did not reproduce.

TL;DR

• A spend cap needs a cost-oracle to price the next action. The oracle has its own outage.


• The usual framing (fail-open vs fail-closed) is the wrong axis. The real split: does the ledger keep moving while the oracle is quiet?
  


• Strategies that charge a price the remaining budget can still absorb keep the ledger alive and re-trip the cap. Charge zero and spent freezes forever. Charge more than fits and you've written refuse with extra steps — the harness proves that one on itself.


• A free local fallback charges zero. In my harness it produces a decision stream identical to plain fail-open: same sha256.


• But a moving ledger is a floor, not a certificate. Any positive fiction satisfies it — price a $0.05 call at $0.01 and your cap is quietly five times the one you configured. The real axis is the bias of your estimator; zero is just where that bias hits −100%.


• The headline number you'd expect me to use here (34 extra actions) is arithmetic, not evidence. I take it apart below rather than sell it.

The branch nobody writes down

Every spend cap I've shipped has the same shape. Price the action, compare against a budget, allow or block. The pricing step assumes the oracle answers.

It doesn't always. CoinGecko 429s. A usage endpoint times out. A token meter sits behind a gateway returning 526. In that moment your cap takes a decision that probably isn't in your code review notes, because it isn't in your code: what to do with an action it cannot price.

I know it's unwritten because I shipped it that way. On June 8, 2026 I published with a clean statement of the instinct: "When I'm about to overspend, don't fail and don't keep paying — fall through to a free local model and keep working." The config in the post marks the tier # local, free, always-on fallback.

I want to be precise about his design rather than convenient, so I read the of a multi-agent loop that billed $1,847 in one weekend, fixed by pushing decisions off the LLM layer and cutting per-game cost from $1.95 to $0.35. Their number, their run; I didn't reproduce it. Their fix was architectural, not a spend cap, and I'm not going to pretend otherwise.

Where my own metric stops meaning anything

I've been leaning on unaccounted as though it measures how accurately you're counting. It doesn't. It's a binary test — did an admitted call with no quote get charged zero? — and the counterexample is sitting in my own output.

The harness has no notion of what an action actually costs. Every admit really executes, and a real call here is $0.05. Multiply the admitted column by that and set it beside the ledger:

fallback:1c passes my metric cleanly. unaccounted=0, ledger-moved=True, budget tripped on schedule — and I wrote "that's the budget, tripped, doing its job" about that exact row. It also pushed 26 real calls through a ten-call budget. Pricing a $0.05 action at $0.01 under-counts by 5x, and a cap that under-counts by 5x is a cap five times larger than the one you configured.

So "keep the ledger moving" is satisfied by any positive fiction. The real axis isn't zero versus non-zero — it's the bias of your estimator. Zero is simply the point where the bias hits −100% and the cap stops existing at all. It's the worst case and it's the common case, which is why it earns a post, but unaccounted=0 is a floor, not a certificate. If your fallback price is a comfortable number rather than a conservative one, you haven't fixed the runaway. You've slowed it down and moved it out of view.

There's a second place my instrument lies, and I found it checking this piece rather than writing it. The ledger-moved column samples spent after each blind decision, so what it actually asks is "did the ledger move more than once?" A price that fits exactly once — try --fallback 15 — pushes spent from $0.30 to $0.45 and still prints ledger-moved=False, the same value fail-open gets. None of the rows in this post are affected; they sit at 0c, 1c, 2c, 5c and 25c. But if you sweep the price yourself you'll walk into it, and it's the same conflation I've spent the whole post complaining about, sitting in my own column. Trust spent. The boolean is a convenience and I got it wrong.

One caveat on that table, because it cuts against my own framing: it assumes an un-priced call costs what a healthy one costs. If your fallback genuinely is a free local model, the dollar figure really is zero and the fallback:0c row overstates the dollars. That's precisely , which is about cheap calls that sum to a runaway, and from the and was not reproduced here; the circuit-breaker design described is @ddhh's, quoted from their post and their MIT-licensed repository.