Blog · 6 November 2026
Run a quarterly API cost review: four checkpoints that stop token spend drifting
An AI API bill rarely jumps. It drifts — a model switch here, slightly longer outputs there, a few more retries, one feature that quietly gets used ten times more than you planned. Month to month the change looks small, which is exactly why it is dangerous: by the time the bill is obviously too big, three months of drift have already been paid for. The fix is a rhythm, not a tool: a quarterly cost review, done on a fixed date, that re-prices what you actually run and asks what moved and why.
Checkpoint 1: re-price your top features, not last quarter's bill
Start from current usage, not from the last invoice. Paste a representative prompt from each feature into the token counter to get a real token count, then run it through the monthly cost estimator with this quarter's actual request volume. Do it per feature: a chat feature with long outputs and a summarizer with short ones can have wildly different costs per user, and a single blended average hides the expensive one. If you are considering a provider or model switch, the model price comparison shows where the same workload lands cheapest — but the cheapest per-token model is not cheapest if it needs twice as many retries to get a usable answer.
Checkpoint 2: compare quarter against quarter, and name the cause
A total that went up 20% tells you nothing until you know which of the three levers moved: volume, tokens per request, or price per token. Split the change between them. Volume up because a feature grew is good news with a cost attached; tokens per request up because prompts got longer is a design choice worth questioning; price per token up because a provider changed its rates is a fact to re-budget around, not a surprise to discover at invoice time. Write the split down in one line per feature — “volume +30%, tokens flat, price flat” — and next quarter's review takes minutes instead of an afternoon. Usage-based spend is variable, and so is the profit it sits inside: if you are self-employed, that variability is also why a fixed monthly tax reserve misleads, as covered in your AI API bill varies every month — your tax reserve should vary too.
Checkpoint 3: cap the surprises before they happen
A review finds drift; caps prevent it. Per-key spend limits, output-token caps and retry budgets turn an unbounded API bill into a bounded one, and a bounded bill is one you can actually forecast. Set the caps per feature, not just per account, so one runaway feature trips its own limit instead of eating the budget for everything else. Check the caps themselves each quarter too — a cap set when a feature had a hundred users is the wrong cap at ten thousand.
Checkpoint 4: review it alongside your quarterly admin
A review that lives on its own is easy to skip; one attached to admin you already have to do gets done. Quarterly reporting is becoming the normal rhythm for small businesses on both sides of the Atlantic: in the UK, Making Tax Digital now asks sole traders and landlords for a quarterly update to HMRC on the same four dates every year. If you run a UK side business, a free MTD readiness checker tells you whether the rules already apply to you, and the quarterly deadline calendar lists the four dates. Do the API cost review in the same sitting as the quarterly admin: same quarter, same numbers, same habit. Two reviews done together stay in proportion; two done separately drift apart — which is the problem you are trying to solve.
Four checkpoints, once a quarter: re-price what you actually run, split any change between volume, tokens and price, cap the surprises, and do it alongside the admin that already has a quarterly deadline. Token spend will still vary — that is the nature of building on APIs. It just will not vary without you noticing.
This post is general information about budgeting, not tax advice. Tax rules mentioned here are for UK Making Tax Digital for Income Tax as published on GOV.UK; your actual obligation depends on your full return. See the About page for how this site's cost estimates are produced.