How to bill for AI tokens

If you resell a language model, you have a cost that is measured per token and a price that probably is not. That gap is where AI companies quietly lose margin, and it usually stays invisible until someone reconciles a month by hand and finds the shape of it.

This is what to meter, how to rate it without arithmetic drift, and what to watch so a customer's changed prompt does not become your problem.

Meter input and output separately

Providers price input and output tokens differently, often by a factor of three or more, and the ratio between them varies enormously by workload. A summarisation product is input-heavy. A generation product is output-heavy. If you meter a single combined token count, you have thrown away the one property that determines your cost.

So the event you record should carry, at minimum: the model, the direction, the token count, and the customer. Everything else — region, endpoint, prompt template — is worth keeping too, because you cannot analyse a dimension you did not record.

{
  "event_id": "b41f8c02-9d15-4e77-8a30-6f2c1b95e4d8",
  "event_type": "tokens",
  "timestamp": "2026-06-16T09:14:22Z",
  "account": "acct_customer_412",
  "quantity": 18402,
  "unit": "tokens",
  "properties": {
    "model": "atlas-large",
    "kind": "input",
    "endpoint": "/v1/summarise"
  }
}

Rate per model, not per product

A rate that matches on the model name gives you two things. First, when a provider changes a price, you change one tariff line rather than auditing your codebase. Second, when you add a model, you add a line — you do not deploy.

This is the same longest-prefix matching that telecom uses for dialling codes, pointed at a different property. A rate for 'atlas' covers every atlas model; a more specific rate for 'atlas-large' overrides it. Model families tend to share naming conventions, which makes this more useful than it first sounds.

Do not use floats

At £0.000012 per token, floating-point arithmetic drifts. Not dramatically, and not immediately — but across tens of millions of tokens per month, the total in your database stops matching the total on your invoice. The discrepancy is small enough to look like a bug and large enough to erode trust when a customer finds it first.

The fix is unglamorous: store rates as decimal strings, do the arithmetic in fixed point, and round once, at the final amount, using banker's rounding. Never round an intermediate value. A system that rounds at each step will disagree with itself depending on the order it processes events in, which is a genuinely miserable class of bug to diagnose.

Watch margin per model, continuously

Your cost per token is a moving target — providers change prices, and your traffic mix changes without anyone deciding it should. A customer who switches from a small model to a large one has changed your margin on that account, and nothing in your product told you.

The useful alert is denominated in money and scoped to a route: 'atlas-large for this account went margin-negative at 14:02' is actionable. 'Token volume exceeded threshold' is not, because volume going up is usually good news.

Give customers the breakdown

The single most common support ticket in usage-based AI products is some version of 'why is this month higher?'. You cannot answer it from an aggregate. You need to be able to show the events, grouped by model and direction, with the rate that applied.

Being able to answer that quickly is worth more than it looks. It converts a billing dispute into a conversation about how the customer is using the product, which is a conversation you want to be having.

A sensible starting point

• Meter every call with model, direction and token count, from day one, even before you price anything.
• Keep raw events. Aggregates cannot answer questions you have not thought of yet.
• Price per model with a family fallback, so new models do not need a deploy.
• Set a margin alert per model, in pounds.
• Make sure a customer-facing breakdown exists before you need it in a hurry.