How to set an AI budget by team, and what to do when it is exceeded

Company-wide AI budgets do not change anyone's behavior, because nobody owns them. Team budgets do, if they are set at the right level, count the right things, and reach the right person when they are crossed. This is a working method for all three, plus the part most guides skip: what the owner actually does when the notice arrives.

Set it at the level where someone can act

A budget needs an owner who can see the people behind the number and change what they do. That is a team lead or a department head, not the CFO and not the platform team. Sales operations can budget the sales floor. An engineering manager can budget their group. A head of AI can budget the pilot program.

Below the team, per-person budgets are useful for the outliers: the one agent builder, the one shared key, the contractor. They are not useful as a default. Forty per-person budgets is forty things nobody looks at.

Pick the number from what happened

Do not start from a target. Start from the last quarter's actual spend for the team, all shapes included: API usage attributed to its people, their enterprise seat usage, and any plans expensed to them, spread by day. Take the monthly figure, add the growth you expect from workflows you know are coming, and set the threshold there.

Set the period to a month. It matches the invoice, it is short enough that a change in behavior shows up within the period, and it lines up with how the owner already thinks.

Then write down what the team produced in the same quarter, so that the budget has a denominator from day one. A budget set without its output beside it turns into a cost-cutting exercise the first time it is exceeded.

Count everything, especially shared keys

A team budget has to include spend on shared keys attributed to the team. If it does not, the budget is trivially avoided: usage moves from personal keys to the shared one and the team total drops without anything changing.

This has a consequence worth stating on the page: a team's spend is not the sum of its people's spend. It is the sum of its people plus its shared keys. Show both, and say so.

It also has to include the enterprise seat usage and the licenses, or the budget covers the shape of spend that is easiest to see and misses the ones that move.

The notice: where, when, what

Check every night, after the day's usage has landed from the providers, against the month so far. When the figure crosses the threshold, tell the owner once, in the place they already work. For most teams that is a Slack channel.

The notice should say the team, the budget, the figure, the date, and where to look. It should not say "breached" or "violated". A budget is exceeded. This is a threshold that started a conversation, not a rule that was broken, and the language sets the tone of the conversation that follows.

One notice per period per budget. A daily repeat is noise, and noise gets muted.

The three decisions

When the notice arrives, the owner looks at the team's people sorted by spend, and one of three things is true.

The budget was wrong. The spend is spread across the team, it tracks the work, and the output is there. The team found something that works and the number in the plan did not anticipate it. Raise the budget, record why, and carry the new figure into next quarter's plan. This is the good outcome and it is more common than people expect.

One person or one key. Most of the excess is one row. Either a person is running something heavy, in which case the question is what and whether it is producing, or a shared key has become the path of least resistance and needs splitting into personal keys so the usage can be seen. Talk to the person. Do not throttle the key first.

Something is broken. An agent in a loop, a test suite calling a frontier model on every run, a service account counted as a person. This is the case where speed matters and the owner should be able to find it in the usage pattern: the same key, the same model, every hour, flat. Fix the thing, not the budget.

None of these is "block it". A hard cap at the provider stops the work of everyone on the team to stop the spend of one, and the cost of the stopped work never appears on any invoice.

Record it

Every exceeded budget should leave a record: the date, the figure, the notice, and what the owner decided. That record is the annual plan's raw material. A year of "exceeded, raised, because the SDR team's meetings booked went up with it" is an argument for more AI budget that a finance committee can accept. A year of "exceeded, ignored" is an argument for something else.

When to introduce enforcement

Later, and narrowly. Once the budgets have run for a few months and the decisions have a pattern, there may be a case for a hard limit on a specific thing: the sandbox project, the contractor key, the service that should never exceed a known run rate. Apply it there. A company-wide cap is a company-wide decision not to know what the work was worth.

Arbitir sets budgets at the organization, team or person level for a calendar month, counts API spend, enterprise seat usage and licenses with shared keys included in the team's figure, checks nightly, posts one notice to the connected Slack channel when a budget is exceeded, and records the event. It does not block spend.