Part 3 of 6 · 2 min read
A budget guard
Stop a run before a call that would pass the cap, using a safe upper-bound estimate.
guard = BudgetGuard(led, "run-7", max_dollars=0.05, max_steps=50)
for step in range(1, 100):
guard.check(step, estimated_next=estimate_call("large", input_tokens, max_output_tokens=150))
...call the model, then led.add(...)
The guard checks spent + estimate > limit before the call, so the run stops at or under the limit instead of finding out afterwards. The step limit is a second, independent brake that catches a loop even when each call is cheap.
The estimate is where the safety comes from. The input size is known before the call, and max_tokens (module 1) bounds the output, so estimate_call can give an upper bound: all input at the highest input rate, and the full output cap used. In the demo the run stops at step 4, with $0.0410 spent and a next call that could cost up to $0.0232. Stopped runs return their result so far with a clear message.
For the curious Two weaknesses of the first version
A guessed estimate. The first demo passed a fixed 0.01 as the next cost, but step 4 really costs about $0.019. A guess that is too low lets the run pass the cap. estimate_call removes the guessing, and a test checks that its value is never below the real cost for plain, cached and cache-write usage.
Parallel calls. The guard reads the ledger, so if five calls run at the same time, each can pass the check before any is recorded. The example is for one call at a time. For parallel work, reserve the estimated cost when the call starts and settle it when the call ends.
Interview angle
"How would you stop an agent from running up a huge bill?" A strong answer has layers: a per-run dollar and step cap checked before each call using an upper-bound estimate, per-user daily limits, alerts on the ledger, and a smaller model for easy steps. Mention that caps should fail safely: return what you have with a clear message, not a crash.