Hard caps, not alerts: how budget enforcement works

Every spend-management tool promises 'budgets'. Almost all of them mean the same thing: a dashboard number and an email when you cross it. The money is already gone — the tool just told you faster.

TokenRouter budgets are enforcement, not reporting. When a request arrives, the gateway checks every budget that applies to it — the key's, the member's, the team's, the org's — before a single token is sent to a provider. If any hard cap is exhausted, the request is rejected with a clear error your code can handle.

The naive version of this is a database query per request, which would add tens of milliseconds to every call and fall over under concurrency: two simultaneous requests could both pass the check and blow through the cap together.

TokenRouter does the whole check in a single atomic Redis operation — all applicable limits are checked together, and spend is reserved before the provider call, then settled to the real amount after. Either every check passes and the reservation commits, or the request never leaves the gateway. There's no window where two requests can double-spend a budget.

A hard stop with no warning is its own kind of incident, so every budget also fires alerts at 50, 80, and 100% of its cap. Owners hear about trajectory long before anything blocks — the cap is the backstop, not the first line of communication.

That combination — early alerts plus a real backstop — is what lets teams hand out AI access broadly without anyone watching a dashboard all day.