AI spend governance: how to budget for seats, tokens and metered agent runs

Before anyone can set a budget, finance needs to know which meter each line of the bill runs on. There are four, and one vendor can charge on several of them at once. Claude Enterprise, for example, is priced as a seat plus usage at API rates [2], so a company that thinks it has bought seats has also bought a metered service.

Seats are the only meter a finance team can forecast from a headcount plan. The other three are consumption, and consumption follows behaviour: which model a team picked as its default, how long a session runs before anyone clears it, and whether a scheduled agent is still running for a project that ended last quarter.

A token price looks small, which is exactly why it misleads. The bill is that price multiplied by a quantity nobody decided, and several settings change the price itself. These are the ones I would check first, all read from OpenAI's and Anthropic's pricing pages [3, 4].

I have watched context drive a bill at scale. On an AI platform at a large international marketing agency, every user's client fetched the skills library from its source, so consumption grew with users times sessions times fetches. Replacing that with one sync every ten minutes carries a forecast saving of £2 million to £4 million a year, modelled on token consumption and reviewed by the client's finance team. A later rebuild, splitting the skills so each session loads only what its task needs, cut the average cost per session by 60%, by our own measurement. The engagement file for that platform sets out both changes.

Seat prices are the easy part of the budget, with two catches. Seat tiers differ in size: a premium Claude Team seat costs five times a standard seat and carries five times the usage [2]. OpenAI's help centre likewise separates Business Standard seats from Business Premium seats, and among Business seats only Premium can spend its full allowance on GPT-6 Astra [11]. And the allowance is shared. On Claude Team and Enterprise, Claude Code draws on the same per-seat allowance as chat and Cowork [8]. On ChatGPT, Codex and ChatGPT Work share one allowance, and on credit-based agreements everyone's eligible use draws on one workspace pool [1, 5].

Coding agents are the heaviest seats. Claude Code and Codex are vendor-built versions of what we call an AI harness, and each turn carries file contents, tool calls and multi-step reasoning, which is why Anthropic tells admins to budget more for a coding seat than a chat seat [8]. OpenAI's seat, allowance and credit rules for Codex are set out in our guide to Codex pricing and credits.

Past the allowance, a seat plan becomes a metered plan. Anthropic's usage credits and OpenAI's workspace credits both let work continue, and both can be limited per person, per group or across the organisation [5, 8]. If nobody has set those limits, the seat price was never the ceiling.

Both vendors publish usage figures, and both show the same shape. Anthropic says that across enterprise deployments Claude Code averages about US$13 per developer per active day and US$150 to US$250 per developer per month, with 90% of users below US$30 per active day [8]. OpenAI's planning example for first-time enterprise ChatGPT Work adopters in Marketing puts annualised credit use at about US$53 per employee at the median, US$309 on average and US$1,154 at the 90th percentile, and calls the figures directional [5]. The average sits well above the typical user because a minority use far more. Budget for the heavy users by name, and treat any published average as a check on your own pilot, never as the plan.

Every vendor offers alerts, and the documentation is explicit that they notify without stopping anything. The controls that do stop spending behave differently from one vendor to the next, and the engineering team needs to know what its application will see when one trips. The table sets out what each vendor's documentation says happens at the limit [5, 6, 7, 8].

Two things in that table catch organisations out. The first is that one word means different things: OpenAI's API spend limit only alerts unless someone turns on the hard limit, while a Claude API spend limit stops requests once it is reached. The second is that a hard limit on a customer-facing application is an outage you scheduled yourself. I would put hard limits on experiments, internal tools and agents. On a production application I would pair a higher hard limit with alerts early enough to act on, as OpenAI suggests [6], and decide in advance what the product does when the limit trips.

Whether you call it AI FinOps or AI spend management, the FinOps Foundation's framing is the right place to start because it is so plain: cost is price multiplied by quantity, so you manage it by lowering the rate or lowering the amount used [9]. Everything else is deciding who owns each quantity.

Give every meter one owner. Seats belong to the team the person sits in. API usage belongs to the product or use case that makes the calls, which only works if each one runs under its own OpenAI project or Anthropic workspace from the first day [6, 7]. An agent belongs to the owner of the workflow it runs, because they are the person who can say whether a run was worth what it cost.

Then decide how far to take the reporting. The FinOps Foundation separates showback, which shows each group what its scope costs, from chargeback, which posts those costs to budgets in the accounting system. It says showback is always needed, that chargeback depends on the organisation's accounting policy, and that neither is more mature than the other [10]. For most AI spend I would start with showback by owner and move to chargeback once the numbers have held steady for a few months. How the costs are booked is a question for your finance team and auditors; this is not accounting or tax advice.

Keep build money apart from run money. The Foundation's crawl, walk, run model sets cost and time limits in advance for experiments, and splits production budgets into running the system and releasing changes to it [9]. A pilot that becomes a production service without its budget moving with it is how AI spend ends up in a discretionary line with no owner at all.

Here is the method on a made-up company. The headcounts, volumes and token counts are fictional and labelled as such; the prices are the list prices on the vendors' pages on the day we checked, so you can see how real rates behave. Replace every fictional number with one from your own pilot before a budget holder sees it.

Seats are 74% of this fictional bill and the part nobody needs to watch. The metered 26% is where the variance lives, and two ordinary changes show why (our arithmetic on the list prices above). If a prompt change stopped the support assistant hitting its cache, that line would rise from US$1,244 to US$2,000 with no change in volume. If someone switched the same assistant to GPT-6 Astra, it would come to US$6,220, five times the line, again with no change in volume [3].

So set the limits where the variance is. In this example the seats need a quarterly headcount check and little else. The support assistant gets its own API project, with a hard limit above the pilot's 90th percentile and alerts well below it. The agent gets a workspace spend limit and a budget per run that code checks and enforces, the same way we recommend gating an agent's consequential actions. The six heavy users get per-person usage-credit limits that a manager can raise on request.

If the register above is kept, the monthly review should take less than an hour. These are the questions I would put to each owner.

Putting this in place is platform work as much as finance work: a project or workspace per workload, limits and alerts, per-user reporting for the coding agents, and a unit cost the business recognises. Setting up and rolling out AI work tools and coding agents for companies is core work at 1AYM; the agency platform above is the documented case, including the changes that cut its running cost. For a spend problem I would start with a fixed-scope statement of work: inventory the meters, name the owners, set the limits and measure cost per unit of work. It can start within a day of the scope being signed. If you have already scoped the job and need people to do it, we can resource it on contract from the associates who work with 1AYM, held to the same standard. Book a call below or email tayyeb@1aym.com if that would help.