A budget guard with limits, an alert and a kill switch
Spend is counted in micro-dollars (whole numbers). The clock is a counter in milliseconds, so the day changes when you decide.
Guards stop one bug or one heavy user from emptying the budget: a cap on tokens per request, a daily limit per user, a global spend ceiling with an alert, and a kill switch you can flip without a deploy.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write Quota(limit) with allow(user) that returns True and counts the call while the user has used fewer than limit calls, otherwise False. Test it with a limit of 2 and one user making 3 calls.
Add reset() to the quota that clears all counts, and show that a user who was refused is allowed after the reset.
Explain it without notes
Name four guards that protect an LLM feature's spend and what each one stops.
Why must the budget check happen before the call, using the worst case?
How does this site's AI tutor limit usage?
Why should a kill switch be a runtime flag and not a code change?
Expected output
t=0 ana: ok (spent 2500)
t=1000 ana: ok (spent 5000)
t=2000 ana: ok (spent 7500)
t=3000 ana: refused (daily limit for this user) (spent 7500)
t=4000 bob: ok ALERT: 80 percent of today's budget is spent (spent 10000)
t=5000 bob: refused (global budget used up) (spent 10000)
t=6000 cy: refused (global budget used up) (spent 10000)
t=86400010 ana: ok (spent 2500)
t=86400020 ana: refused (kill switch is on) (spent 2500)