Keep each team's spend inside an agreed ceiling
Spend questions rarely arrive as questions about API keys. They arrive as questions about people and the parts of the business those people belong to. A finance partner wants to know that the data-science organisation cannot exceed the number agreed for the quarter, without anyone having to watch it. This guide turns that agreed ceiling into an enforced policy: baseline the existing spend, create the budget at the right scope, and decide deliberately what happens when the ceiling is crossed.
Persona: Platform operator working in the Admin Dashboard, implementing a ceiling agreed with finance or the relevant business owner.
Estimated time: 20--30 minutes for an initial setup with one or two teams; 5--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.
- The enforcement mode, warn or block, is chosen deliberately for the situation the budget serves.
Prerequisites
- Administrator access to the Admin Dashboard, 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 Dashboard and select Analytics | Usage.
- 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.
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 centre.
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 the budgets area of the Admin Dashboard 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 centre 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. 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.
Step 5: Choose warn or block at the ceiling
The single most consequential decision in a budget is what happens when it is exceeded.
| Mode | Behaviour at the ceiling | When it is appropriate |
|---|---|---|
| Soft enforcement | Spend is tracked against the ceiling and an alert is raised as the budget is approached or crossed, but requests continue to be served | Production workloads where cutting traffic off mid-month is a worse outcome than a temporary overspend; budgets that are forecasting and accountability tools rather than hard contractual caps |
| Hard enforcement | Requests are blocked once the ceiling is reached, until the period resets or the ceiling is raised | Capped evaluation or experimentation budgets; teams with a genuinely fixed allocation; any situation where overspend is unacceptable and a hard stop is preferable to an invoice surprise |
Soft enforcement is the safer default for anything serving real users. A budget overrun is rarely an emergency, whereas a sudden block on a production path looks like an outage to the business it serves. Hard enforcement is the right tool when the ceiling is a real boundary rather than a guideline; its cost is that legitimate work can be cut off at an inconvenient moment, so it pairs best with an alert raised well before the ceiling. Many deployments combine the two: production-facing teams run soft so that customer traffic is never cut, while evaluation and discretionary teams run hard so that a runaway is stopped automatically. The operator's role is to implement the business decision and to make sure the alerting behind a soft budget is actually wired to someone who will act on it.
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.
What to do next
- See budget exhaustion coming: read the burn against the ceiling created here, in time to intervene. See See budget exhaustion coming before it blocks a team.
- Bill AI spend back to the teams that incur it: turn the budgets into the statements finance consumes. See Bill AI spend back to the teams that incur it.
- Stop runaway workloads: the flow-control companion to the spend cap this guide configures. See Stop runaway workloads before they burn the budget.
Where to go next