About Cost and Quota Management
Enterprise Tier
AI spend is brought under control in three stages, in order: understand what is being spent, monitor that spend against a limit agreed with finance, then enforce that limit with a policy that stops calls once it is reached. A budget only ever measures, so a cap set without a baseline is a guess, a baseline nobody watches is a report, and a limit without a policy behind it stops nothing.
Persona: Platform operator working in the Admin Console, usually with the finance owner who sets the number and the engineering manager who owns the workload behind it.
Estimated time: 5 minutes to read. Each stage links to guides that carry their own estimates.
The three stages
Understand
Read what is being spent, by team, by model, by key, and over time. Nothing is limited at this stage. The output is a baseline and a set of owners.
Monitor
Set a budget: a monthly limit on a team or a person, with a live meter and an alert as the limit is approached. A budget measures and reports; it never stops a request, whatever the meter reads.
Enforce
Attach a policy that acts at the limit rather than reporting on it. A rate limit rejects traffic over a throughput ceiling today. A budget policy, which stops a caller once its budget is exhausted, is planned for 2026 Q3.
A budget never stops a call. It tracks spend against its limit and reports on it, and that is the whole of what it does, in this release and in every release after it. Crossing the limit raises an alert and changes nothing about what the caller can do next.
Enforcement is a separate object. A budget policy takes the budget's threshold as its trigger and acts on the request path: once the budget is exhausted, the user or client is refused and cannot call again until the period resets or the limit is raised. Budget policies are planned for the 2026 Q3 release.
Where an inline hard stop is needed today, that job belongs to a rate limit, which is enforced at the gateway and rejects requests over its ceiling.
Stage 1: understand what is being spent
Spend cannot be governed before it is attributable. The unit of attribution is the API key, so the per-purpose key convention in Onboard developers and issue keys is what keeps every later stage precise.
| Question | Where it is answered |
|---|---|
| What is the organization spending, and is it trending up | See where AI spend is going |
| Which team, person, or key is driving it | See where AI spend is going |
| How do two teams or two people compare side by side | Compare user and team spend in Analytics |
| What does each app or project cost, when neither maps to a team | Know what every app and project costs |
| What does each cost center owe for a closed period | Split the AI bill across teams |
Stage 2: monitor spend against a limit
A budget turns a number agreed with finance into a live meter. It has a scope (a whole team, each teammate, or one person), a monthly spend limit in US dollars, and a reset at the start of each calendar month in UTC.
What a budget does:
- Tracks cumulative spend against the limit and shows burn, headroom, and days remaining.
- Raises an alert as the limit is approached and as it is crossed.
- Records who created it and when, so the number has an owner.
What a budget never does:
- Reject a request. Measuring is the whole of its job. Spend is evaluated on the management plane against aggregated request logs, not inline at the gateway, and an exhausted budget leaves the caller free to keep calling. Stopping calls is Stage 3, and it takes a policy.
- Cover tokens or request counts. A budget is money. Throughput is a rate limit.
| Question | Where it is answered |
|---|---|
| How is a limit created, and what scopes can it take | Set a budget and track spend against it |
| How much headroom is left this month, and which members are consuming it | See budget exhaustion coming in time to act |
| How is a limit raised, paused, or retired once it no longer fits | Raise a spend ceiling without interrupting delivery |
| What catches drift that stays under every limit | Catch spend drift before the invoice does |
| How is spend alerted on without anyone watching a dashboard | Get alerted to cost spikes as they happen |
Stage 3: enforce a cap
Enforcement divides by what is capped. Throughput is capped today: a rate limit rejects requests over its ceiling, inline at the gateway, and is covered in Stop runaway workloads before they burn the budget. Spend is not capped yet.
Spend is capped by a policy, never by the budget itself. A budget policy takes the budget's threshold as its trigger and acts on the request path when it is crossed: the caller is refused and cannot call again until the period resets or the limit is raised. A policy on a single API key can instead degrade to a cheaper model, in which case calls continue at lower cost rather than stopping.
Budget policies are scheduled for the 2026 Q3 release. They are documented ahead of it so that the design can be reviewed and planned against. The scenarios, the interactions between overlapping budgets, and what a blocked caller sees are worked through in Enforce budget caps with policies.
Budgets and rate limits are not the same control
A budget measures money over a calendar month and reports on it. A rate limit measures throughput over a short window and rejects what exceeds it. Setting one where the other belongs is the usual reason a cost control never fires.
Most workloads warrant both: the rate limit walls off the fast runaway, and the budget flags the slow accumulation. The full comparison, and a per-workload decision between them, is in Choose the right cost control for each workload.
Start here
See where AI spend is going
Stage 1. The organization trend, the cut by team, and the cut by model.
Set a budget and track spend against it
Stage 2. Create a budget, read the meter, change the number later.
Enforce a budget cap
Stage 3, coming soon. Block or fall back when the limit is reached.