Tokens, not subscriptions. Per employee. With a refund for coming in under.
This post reflects our direct experience operating AI workloads against metered APIs. It is a starting point for discussion — not an accounting recommendation or a procurement policy.
The Line Item
If a company talks about "using AI" but has no monthly API-token line in the budget, it is not using AI. It is using a chat product. Subscriptions are flat-rate consumption capped by the vendor, billed once a month, and forgotten. Real work runs on metered API tokens, against your own keys, inside your own tools, on your own data. Until that line item exists, every claim about AI adoption is procurement theatre.
The test is straightforward: pull the general ledger, look for a recurring API spend with a model provider, and check whether it is allocated to a specific cost centre or sitting on a corporate credit card that nobody reviews. If the answer is the credit card, the company is not running AI. It is sampling it.
Per-Employee Allocation
Hand each employee a monthly token budget and let them spend it. Central allocation by a manager who is not doing the work produces the worst possible signal — they cannot tell which prompts are worth the cost because they are not the ones writing them. The employee learns fastest what a model is and is not worth asking.
Pair the allocation with a payout for the unspent portion when the work still shipped on time and on spec. The incentive lines up: finish the job, do not burn tokens to look busy. Anyone who has watched an agent loop on a wrong assumption for forty minutes understands what is being prevented. The budget is not a cap. It is a piece of authority the employee did not have before, and it is the only structure that lets a workforce develop judgement about cost.
Why Budgets Are Hard, and Why You Set One Anyway
LLMs cannot estimate their own cost. Ask one to price a task and the answer comes back roughly an order of magnitude under what it actually spends. The gap is filled by retries on wrong logic, half-finished tool calls, context bloat, and the model's tendency to keep going when a person would have stopped. Monthly spend does not stabilise until the team has run real workloads for several cycles. Forecasts before that point are guesses.
Set the budget anyway. The budget is not a forecast. It is the only thing that forces a forecast to exist, that produces the data the next cycle's budget is built from, and that gives an employee a fixed number to make trade-offs against. A wrong budget, revised quarterly, beats no budget revised never.