Set a budget and track spend against it
Enterprise Tier
Finance sets limits in money, not tokens. This guide turns that ceiling into a budget that tracks currency spend and complements rate limiting.
Persona: Platform operator working in the Admin Console, implementing a ceiling agreed with finance or the relevant business owner.
Estimated time: 20 to 30 minutes for an initial setup with one or two teams; 5 to 10 minutes per budget thereafter.
Outcomes
By the end of this guide:
- Usage and cost, in both tokens and money, can be read per user and per team over a chosen period.
- A monthly spend ceiling exists for a chosen team or person, at a scope that matches how the cost is owned.
- Spend is tracked against that ceiling and an alert is raised as the budget is approached or crossed, so the operator and business owner can act in time.
A budget never stops a call. It is an observability control: spend is evaluated on the management plane against aggregated request logs, so a budget shows burn against the ceiling and raises alerts, but an exhausted budget leaves the caller free to keep calling. That is the whole of what a budget does, in this release and in every release after it.
Enforcement is a separate object. A budget policy takes this budget's threshold as its trigger and refuses the caller once it is exhausted, until the period resets or the limit is raised. Budget policies are planned for the 2026 Q3 release. To cut traffic off inline today, use a rate limit.
Prerequisites
- Administrator access to the Admin Console, typically the
super_adminorbilling_adminrole. - API keys that follow the per-purpose convention, so that usage attributed to a user or team is precise rather than blurred across shared credentials. The convention is established in Onboard developers and issue keys.
- Group identity flowing in from the identity provider. Team budgets are only as meaningful as the team membership behind them; the mapping is covered in Map Entra ID groups to business functions.
- Agreement with finance or the relevant business owner on the ceiling itself and on what should happen when it is reached. A budget is a policy decision before it is a configuration; the operator implements the decision rather than originating it.
Step 1: read the baseline before setting the number
Before a budget can be set sensibly, the existing consumption has to be visible at the same dimension the budget will use.
- Sign in to the Admin Console and open Usage → Analytics.
- Select tab Cost.
- Apply a time range that matches the budgeting cadence: last 30 days or the last billing cycle is the usual choice for a monthly budget.
- Select the Group by User breakdown and review the ranked list. Each row carries the request count, token totals, and estimated cost for that user across all of their keys.
- Select a user row to drill into the specific keys, models, and costs behind it. To compare several people or teams side by side before the number is set, see Compare user and team spend in Analytics.
The team dimension is the aggregate of its members. Where the deployment surfaces a team breakdown directly, it is read the same way; where it does not, team spend is derived by summing the cost of the users mapped to that team, which is exactly why the group-to-team mapping has to be correct before team budgets carry any weight. A user counted in the wrong team is spend charged to the wrong cost center.
Size the ceiling from this baseline rather than guesswork: comfortably above normal consumption but well below any level that would be a problem. A budget for a team with no history is tightened rather than left loose; real traffic surfaces the true shape quickly, and relaxing a tight ceiling is a low-risk adjustment.
Step 2: choose the budget scope
Open the New budget dialog from Usage → Budgets in the Admin Console and select one of the three scopes.
| Scope | What the limit covers | When it fits |
|---|---|---|
| Whole team | One shared limit pooled across all members of the team | A cost center with a single ceiling over everyone charged to it, where one member's heavy month can be offset by another's light one |
| Each teammate | The same limit applied to every member individually | A per-person allowance that should hold for each member regardless of what the rest of the team spends |
| One person | A limit that applies to a single user | An individual whose consumption is bounded on its own, independent of any team |
A pooled limit bounds the team as a unit and tolerates uneven consumption between members; a per-member limit holds each person to the same allowance and flags any single member who exceeds it. The two layers coexist: a team can carry an overall ceiling while individual members carry their own, tighter ceilings underneath it, and the most restrictive applicable limit governs.
Step 3: select the team or person
The selection list below the scope reflects the scope chosen in Step 2: a team scope lists teams, and the single-user scope lists individual users.
- Use the search box to filter the list by name when the list is long. The match count is shown alongside the field.
- Select the target team or person from the list. Each team row carries its member count, so that the reach of a pooled or per-member limit is visible before the budget is created.
Step 4: set the monthly spend limit
The spend limit is the ceiling itself, expressed in US dollars per month, because the conversation behind it was conducted in money.
- Enter the amount in the Spend limit field, or select one of the preset amounts ($100, $500, $1,000, $5,000, or $10,000) as a starting point.
- Confirm the reset cadence before saving. The budget resets at the start of every calendar month in UTC, so a limit set mid-month still governs the remainder of that month against spend already recorded. The period is fixed when the budget is created and cannot be changed afterward, so a budget on the wrong cadence has to be replaced rather than corrected.
Step 5: understand what happens at the ceiling
A budget tracks cumulative spend against the ceiling and raises an alert as the limit is approached or crossed. It does not stop traffic, and it is not going to. Requests continue to be served after the ceiling is reached, because a budget measures rather than enforces: spend is evaluated on the management plane against aggregated request logs rather than inline at the gateway. A budget is a forecasting and accountability tool that gives the operator and business owner time to act, not a cap that cuts requests off.
Making the ceiling hold takes a second object, a budget policy, which reads this budget's threshold and refuses the caller once it is exhausted. Until one is attached, the alerting behind the ceiling has to be wired to someone who will act on it. When the budget is approached, the legitimate responses are to investigate the spend, raise the ceiling if the growth is agreed and funded, or accept the overspend for the remainder of the period. See See budget exhaustion coming for reading the burn in time to intervene.
Where a genuine hard stop is needed, that job belongs to a rate limit rather than a budget: a rate limit is enforced inline at the gateway and rejects requests over the ceiling as they arrive. Pair a budget with aggressive rate limits on dedicated keys for evaluation or experimentation workloads where a runaway must be cut off automatically.
Step 6: name the budget and create it
- Enter a descriptive name in the Name field, for example
Engineering monthly cap. The name identifies the budget in the admin list where every budget is reviewed together, so it should describe what the budget covers rather than restate the amount. - Review the policy summary, which confirms the scope, target, and limit about to be applied.
- Select Create budget to save the policy.
Once the budget exists, the reasoning behind the ceiling belongs somewhere durable alongside it. The audit trail in Audit Agent Router activity records that the budget was created and who created it; the business justification for the number belongs next to that record.
Where to go next