Use an atomic store operation or a durable ledger with idempotent reservation IDs. Do not pretend estimates are exact. Token counts can differ across providers, and final output length is unknown at admission time. Track estimated, reserved, actual, and billable usage as distinct values. Settle the difference after completion, then reconcile late provider usage reports. If the provider only exposes usage after a failure, keep the reservation until that event is accounted for. A quota system that rejects correctly but reports inaccurate consumption will eventually lose trust. Designed for bursts without allowing permanent hoarding. A simple fixed daily counter makes traffic at midnight and traffic at the end of the day behave strangely.

Make the ledger durable and idempotent. Each charge and reservation should have a stable operation ID, tenant, budget scope, amount, status, and source request. A retry of the usage callback must not create a second charge. Use an atomic balance or ledger transaction, and reconcile the ledger with provider usage records. The in-memory counter is fine for a fast hint, but it cannot be the financial authority after a process restart or during a multi-region race. Choose what happens at each threshold. At a warning level, show remaining budget in the dashboard and return headers or structured metadata to authorized clients. At a soft limit, route to a cheaper approved model, reduce the output cap, or require an explicit user confirmation.