Many AI tools have moved from a flat seat price to credits, request allowances or usage windows. That is fair for the vendor and awkward for the buyer, because the monthly bill is no longer a fixed line. This article is for product and finance leads who need a monthly plan that is simple enough to keep up. It does not explain how credits work in general; for that, see our guide to the move from AI subscriptions to credits. Here we cover the monthly routine: who owns the number, when you get a warning, and what happens at the cap.
Why a monthly plan is different from an annual budget
An annual budget answers "can we afford this programme?" A monthly plan answers "are we on track right now, and who acts if we are not?" The first is a planning document; the second is an operating habit. If you are building the annual view, our article on total cost of ownership and annual budget planning for AI agents covers it. The monthly plan sits underneath and uses the same assumptions.
It is also different from technical cost controls such as per-task limits and loop limits. Those protect you from a single run going wrong, and we describe them in budgets and loop limits for AI agents. The monthly plan protects you from many normal runs adding up to more than you expected.
The one-page template
Keep it to one page that a finance colleague and a product owner can both read in five minutes. It needs these fields:
- Owner. One named person, plus a named deputy for holidays. Not a team, not "IT".
- Monthly credit amount and what it costs in money, with the date the credits reset.
- Split of the amount into three parts (see below).
- Workloads and their share. Which tools or agents draw on the credits and roughly how much each is expected to use.
- Alert levels and who receives each.
- Cap rules. What happens to each workload when the credits are gone.
- Review date and the numbers to bring to it.
Split the amount into three parts
- Planned use: the expected consumption of work you already run. Base it on last month's real usage, not on the vendor's estimate.
- Reserve: an amount you do not allocate to anything. It covers busy weeks and the fact that usage is rarely even through the month.
- Experiment allowance: a small, fixed amount for trying new things. When it is used, experiments wait until next month.
The proportions are your decision and depend on how predictable your work is. A team with steady, repetitive use can keep a smaller reserve; a team that is still learning needs a larger one. Whatever you choose, write it down, because a split that exists only in someone's head will not survive the first busy week.
Who owns the number
The owner is the person who can say "slow down" or "we need more", and who sees the usage data. In practice this is often a product owner for the workload with a finance partner who sees the invoice. Two rules help:
- The owner reads the usage figure on a fixed day each week. A budget that is looked at only when an alert arrives is already late.
- The owner can approve a small, defined top-up without a meeting. Anything above that limit goes to the person who holds the wider budget. Agree the limit before you need it.
Alerts at 70 and 90 percent
A single alert at the cap is only a notification that it is too late. Use two levels with different meanings:
- 70 percent: awareness. The owner looks at which workload is using the most and whether that is expected. No decision is needed yet.
- 90 percent: decision. The owner decides between three options: carry on and accept the risk of reaching the cap, reduce use of the lower-priority workloads, or add credits.
The percentages are a starting point; change them if your use is very uneven.
Compare the percentage with the calendar
A usage percentage means little without the share of the month that has passed. Compare the two:
Worked example (invented numbers, for illustration only). A team has 10,000 credits for a 30-day month. On day 12, usage is 4,000 credits, which is 40 percent. By day 12, 40 percent of the month has passed (12 ÷ 30), so usage is exactly in line with the calendar. If the same 4,000 credits had been used by day 8, the share of the month passed would be about 27 percent (8 ÷ 30) and usage would be running ahead: at that pace the full month would need roughly 15,000 credits (4,000 ÷ 8 × 30), or one and a half times the amount.
The calculation is simple enough to do by hand: divide usage so far by days passed, multiply by days in the month, and compare with the amount. A weekly check with this formula often warns you earlier than the 70 percent alert. It assumes even use, so treat it as a signal, not a forecast, and be careful in months with known peaks.
What happens at the cap
This is the part most plans leave out, and it is the one that causes trouble. When the credits are gone, one of several things happens, depending on the vendor and the contract: the tool stops, it slows down, it moves to a different plan or it continues and charges extra. Check which applies to each tool you use, using the vendor's current documentation, and record it in the plan.
Then decide for each workload, in advance:
- Protected: work that touches customers or a deadline. It gets a rule such as "top up immediately, within the owner's limit".
- Slow down: work that is useful but can wait. It switches to a cheaper option, runs in smaller batches or waits for the next reset.
- Stop: experiments and nice-to-have tasks. They stop and are noted for next month.
Write who tells the affected people, and how. A tool that stops silently leads to a message to the support desk, and a person doing by hand what an agent used to do. If a protected workload has a manual fallback, say where it is described; our article on what to do when an AI service fails covers that situation, and the cap is a predictable version of the same problem.
The monthly review
Once a month, ten to fifteen minutes with the owner and the finance partner is enough. Bring four numbers and one question:
- Credits planned and credits used, in total and per workload.
- How much of the reserve and of the experiment allowance was used.
- How many times each alert fired and what was decided.
- Whether any cap rule was applied.
- The question: what did we get for this? If you already measure the value of an agent, take it from your monthly review of benefits and costs and do not create a second set of figures.
Adjust the plan by what you saw. If the reserve was never touched for three months, reduce it. If the experiment allowance ran out in the first week, ask whether the experiments are producing anything. If one workload takes much more than planned, decide whether it is worth it, not just how to pay for it.
Common mistakes
- No named owner. Alerts go to a shared mailbox and nobody acts.
- Planning from the vendor's estimate. Use your own usage from the previous month, even if it is only a few weeks of data.
- One alert at 100 percent. By then every option is a bad one.
- No cap rule. The decision is made under pressure, often by whoever is online.
- Ignoring the reset date. Credits may not carry over; a large unused balance at the end of the month is a planning signal, not a saving.
- Treating the credit price as the total cost. Review time, rework and the time of the owner are costs too.
Where to start this week
Take last month's usage per tool, write the one-page template with an owner and a deputy, set the two alerts, and answer the cap question for each tool in one sentence. Everything else can be improved after the first monthly review.
Sources
- The current documentation and contract terms of each AI tool you use, for credit rules, reset dates and behaviour at the cap (check the current version before relying on any detail).
- Our related articles linked above; all figures in the worked example are invented for illustration.