Usage-based pricing arrives as a single monthly figure that answers no useful question. It does not say which feature drove it, which customers are expensive, or whether the increase came from growth or from something regressing.
AI cost allocation is the work of making that bill legible, and it is worth doing before the number gets large rather than afterwards.
Tag every call at the point it is made
The attribution has to happen where the request originates, because nothing downstream can reconstruct it. Every call should carry the feature, the customer or account, the environment, and the version of the configuration used.
Retrofitting this is painful and partial, which is why it belongs in the first version. It costs almost nothing to add at the start and it is the difference between a bill you can act on and one you can only pay.
Find the expensive shapes
- Long prompts sent on every call, where a large fixed context is charged repeatedly.
- Retrieval returning more than the model needs, which inflates every request quietly.
- Retries, which double or triple the cost of the requests that trigger them.
- Conversation history resent in full each turn, growing linearly through a session.
- A premium model handling work a cheaper one would do identically.
The last two are usually the largest and the easiest to fix. Trimming history and routing simple work elsewhere frequently removes a large share of spend without any change users would notice.
The bill almost never rises because of the hard requests. It rises because something simple is being done expensively, thousands of times a day.
David Kwon, Head of Automation, Engineered With AI
Caching is the cheapest win available
Many workloads repeat: the same questions, the same documents, the same fixed instructions. Caching identical requests removes their cost entirely, and provider-side caching of a large shared prefix reduces the cost of a fixed context substantially.
The design point is to structure prompts so the stable part comes first and the variable part last, which makes the reusable portion as large as possible. That is a small change to how prompts are assembled and it pays continuously.
Put limits in before you need them
The genuine risk with usage pricing is a loop, a bug or an abusive user producing a month's budget in an afternoon. Provider dashboards usually alert after the fact, which is too late.
Set your own caps per feature, per customer and per run, with an alert well below the ceiling. A job that stops at a limit is an incident ticket; one that does not is an invoice nobody expected.
Watch cost per unit of work, not total spend
Total spend rising alongside volume is healthy. Cost per document, per ticket or per conversation rising while volume is flat means something regressed, and only the per-unit figure makes that visible.
Know what it is worth
Cost is only meaningful against value. A feature costing a few hundred a month that saves a day of work weekly is cheap; the same cost on something nobody uses is waste, and the bill alone cannot distinguish them.
Once spend is attributed by feature, that comparison becomes possible for the first time, which is the real argument for doing the attribution work at all.
Review it on a schedule
Model pricing changes, cheaper models become capable enough for work that previously needed a larger one, and caching options improve. A routing decision that was correct six months ago is worth revisiting.
A quarterly look at the largest cost lines, asking whether each still needs the model it is using, tends to find something. That review is closely tied to model routing, which is usually where the savings are implemented.
Make the cost visible to the people creating it
Engineers write prompts without seeing what each one costs at volume, which is how a fixed context of several thousand tokens ends up on a call made a million times a month.
Showing cost per request in the development environment changes behaviour immediately and permanently. Controlling AI costs is far easier at the point the prompt is written than in a quarterly review six months later.
Price your own product with headroom
Where you charge customers for a feature built on usage-based pricing, your margin moves with their behaviour. Model the heaviest plausible user rather than the average, because that user exists and will find you.
Bill rising faster than usage?
We will break your spend down by feature and customer and find where it is going.