AI cost you cannot split by customer: decide the unit before the amount
Decide whether you count AI cost by customer, by feature or by model before you set the budget amount.
Key points
- No unit chosen means one shared budget
- Decide the unit before the amount
- The split follows the request's label
- Cap on combinations: add one at a time
Overview diagram in preparation
Contents
A budget with no unit chosen becomes one budget
A&A perspective
The unit you split by is the cut the running total is divided along.
A&A perspective
This article calls one call to a model a request.
A&A perspective
When you rebuild how your company works around AI, your company pays the model fees in one place and hands the result to customers as a service. At the end of the month the total is easy to read.
A&A perspective
What is not easy to read is the breakdown. Which customer, and which feature, pushed that total up.
Hypothetical example
Suppose you offer draft replies to inquiries, meeting summaries and first-pass estimates through the same system. If they all call the same model with the same API key, the bill shows them as a single number.
A&A perspective
Automate & Augment (A&A), the company writing this article, builds AI-native ways of working for small companies. A&A reads this as a missing unit of aggregation rather than a missing record.
From the sources
Cloudflare runs a service that sits in front of AI calls. It publishes a document on putting a spend limit in place. The document says a spend limit counts something different from a rate limit. A spend limit tracks the actual dollar cost of each request based on model pricing, it says.
From the sources
The same document lists the units a rule can be scoped by: provider, model, and a custom metadata key attached to requests. The document calls such a unit a dimension.
From the sources
The same document also states what happens when no unit is set. If a dimension is not configured on a rule, all values share one budget bucket, it says.
A&A perspective
A&A reads that as a choice, not an absence. Not splitting is choosing a setting in which everyone's usage goes into one budget.
A&A perspective
Stopping still works. When the total reaches the limit, later requests are blocked. What stays unknown is who it stopped for.
Hypothetical example
Suppose you run the same drafting service for three customers. When the limit is hit, one shared budget cannot tell you whether one customer was running a trial or three customers' ordinary use overlapped.
Decide the unit before the amount
A&A perspective
Before deciding how much the limit should be, decide what that money is counted by.
From the sources
Cloudflare's document describes two modes for each unit. One gives every distinct value its own budget. The other applies the rule only when the unit equals a specific value. In the first mode, each distinct value gets its own independent budget bucket, it says.
A&A perspective
Make a customer identifier the unit and split by value, and you get a per-customer budget.
A&A perspective
There are three candidate units: customer, feature and model. A&A suggests choosing only one to begin with.
A&A perspective
Split by customer and you can see who is pushing your margin down. Where to take next month's price conversation is settled.
A&A perspective
Split by feature and you can see which feature does not pay for itself. The decision becomes whether to move it into a paid tier or run it on a cheaper model.
A&A perspective
Split by model and you can see where the spend is concentrated. You get replacement candidates, but no per-customer breakdown.
A&A perspective
Which one you pick follows from your next move. Looking for someone to raise prices with means customer; looking for a feature to retire means feature.
A&A perspective
The other mode applies a rule only at a specific value. If one customer's usage stands out, you can name that identifier and cap only that customer.
Hypothetical example
Suppose you offer three things: draft replies, meeting summaries and first-pass estimates. Split by feature and next month tells you which of the three is losing money.
A&A perspective
When the choice is unclear, A&A suggests customer. Price changes and usage limits are both conversations with a customer. That is A&A's judgement, not a statement in either source.
| The unit | What it shows | What you can do next |
|---|---|---|
| Customer | Which customer pushes the cost up | Raise the price or discuss a usage limit |
| Feature | Which feature does not pay for itself | Move it to a paid tier or a cheaper model |
| Model | Where the spend is concentrated | Consider a replacement |
The split follows the label on the request
A&A perspective
What decides whether you can split sits on the sending side, not on the counting side.
From the sources
Cloudflare's document says that for a metadata unit you enter the name of a custom key attached to requests. The examples it gives are an agent identifier and an environment name.
A&A perspective
That short marker on the request is what this article calls a label.
From the sources
The same document gives two ways to attach one. When the gateway is tied to authentication, the authenticated user id is added automatically, it says. When it is not, you pass your own identifier with the request.
A&A perspective
A&A reads a consequence from this: the split cannot be applied backwards. A label is attached at the moment a request is sent, so requests already sent without one cannot be assigned to customers later.
A&A perspective
Neither of the two documents this article cites says the split can or cannot be applied backwards. The reading comes from where the label lives.
A&A perspective
So the day you decide the unit and the day you start attaching labels are the same day. Start the labels first and the budget amount can still be decided later.
Hypothetical example
Suppose you start adding a customer identifier to each request. Even with no spend rule in place yet, next month shows a per-customer breakdown.
A&A perspective
What goes in the label can be the identifier already in your customer list. Then the bill and your own records can be matched by the same number.
A&A perspective
Adding labels has its own cost. Every extra field on a request adds something to build and maintain, and widens what is affected when it is wrong. That too is A&A's judgement, not something either source states.
Combinations have a ceiling
A&A perspective
How finely you can split has a limit on the platform side.
From the sources
Stripe provides payment and billing infrastructure. It publishes a document on recording usage through its API. The document says there is a limit on how many unique combinations of configured units it accepts.
From the sources
The same document gives the numbers as well. For each meter, which is the counter for a usage figure, up to 10,000 unique combinations per hour of received events. Per customer on a meter, up to 100 unique combinations across all events.
From the sources
It also describes what happens past that point. Events for combinations already counted continue to process. Events that introduce a new combination after either limit is reached are invalid and surface in a report carrying a specific error code, it says.
A&A perspective
They are not merely unrecorded. They are rejected. A&A treats the difference as serious: unrecorded figures can be added later, while rejected events pile up in a report until someone notices.
Hypothetical example
Suppose you split by 10 customers, 3 features and 2 models. That is up to 60 combinations. Add a date or a version and it multiplies. These are hypothetical figures and change with the actual setup.
A&A perspective
A&A suggests adding one split at a time, and counting how many combinations the current setup produces before adding another.
A&A perspective
Both documents are product documentation published by their own vendors. Neither is an independent audit, nor a test comparing which way of splitting works better. The combination numbers are constraints of that billing platform and can change.
In summary
A&A perspective
A budget with no unit chosen puts everyone's usage in one budget.
A&A perspective
Decide customer, feature or model before you decide the amount.
A&A perspective
The split follows the label on the request, so start attaching it the day you decide the unit.
A&A perspective
Combinations have a ceiling, so add one split at a time.
A budget with no unit chosen puts everyone's usage in one budget. Decide customer, feature or model before you decide the amount. The split follows the label on the request, so start attaching it the day you decide the unit. Combinations have a cap, so add one split at a time.
FAQ
Do I need to split when I only have three customers?
The number of customers does not decide it. What decides it is whether you can name who you will talk to next month about a price change or a usage limit. If you can, the month-end total and your own memory are enough. If you cannot, start the labels first.
Can I tell that a limit is about to be crossed?
The spend limit document says the tracking is eventually consistent. A burst of concurrent requests can briefly exceed the limit before enforcement catches up, it says. Set the limit on the understanding that it is not a strict guarantee.
What if I want to change the unit later?
You start counting again from the day the new label is attached. Past usage cannot be re-split, so keep the old aggregation while you compare the two periods. That is A&A's way of working, not a statement in either source.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Spend limits
Cloudflare · 2026-09-30 (last updated, stated on the page)
Accessed 2026-10-26 - Record usage for billing with the API
Stripe · undated documentation page; no visible publication date
Accessed 2026-10-26