Unit 02.03: A spend ceiling your code enforces

A spend ceiling your code enforces stops the run. A provider alert tells you afterwards.

Checked before each call

A budget object that refuses a call which would exceed the daily limit.

The code runs seven calls against a small ceiling.

class Budget:
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def charge(self, amount):
        if self.spent + amount > self.limit:
            return False, (f"daily ceiling ${self.limit:.2f} would be exceeded "
                           f"(spent ${self.spent:.2f})")
        self.spent += amount
        return True, ""


budget = Budget(daily_usd=0.05)
for call in range(1, 8):
    ok, reason = budget.charge(0.009)
    print(f"call {call}: spent ${budget.spent:.3f} "
          f"{'ok' if ok else 'REFUSED -- ' + reason}")
    if not ok:
        break

# A ceiling your code enforces, checked before each call. A provider-side spend
# alert tells you afterwards; this stops the run. Give it a clear user-facing
# message -- "temporarily unavailable" is better than a silent failure.

The seventh call is refused with a reason. Checking before the call rather than after is the whole point - a ceiling evaluated at the end of the day is a report.

The refusal needs a user-facing message. "Temporarily unavailable, try again tomorrow" is honest and actionable; a silent failure or a stack trace is neither.

The mistake this prevents

The mistake is relying on the provider's spend alert. It fires after the money is spent, often hours later, and it does not stop the next thousand calls. It is a monitor, not a control.

Takeaway

Enforce the spend ceiling in your own code, checked before each call, with a clear user-facing message when it fires. Provider alerts are monitors, not controls.

Mark complete