Pricing an AI workload against cost to serve
Metering an AI product means charging for operations whose cost moves with usage, which changes how the rates have to be built.
pricing, unit-economics, ai
A seat price is a guess about value. A per-operation price is an arithmetic problem you can lose. I built the monetization model for an AI first collaboration platform from scratch, including a Credits consumption system, and the whole exercise came down to whether I understood the cost sitting under every operation I was about to charge for.
The Credits priced multiple operations: ingestion of various filetypes, metadata generation, token consumption on RAG queries, and AI summaries. Each rate was calibrated against cost to serve. That sentence is easy to write and harder to execute, because cost to serve for an AI operation is not one number. It is a distribution, and the shape of that distribution decides whether the price holds.
Why a headcount model breaks here
Under a seat model, a customer who uses the product ten times more than average costs almost nothing extra. Support load moves a little. The margin on that account improves as they engage more, which is why heavy usage reads as a retention signal rather than a cost problem.
Under an AI workload, that same customer is the one who can put a tier underwater. A RAG query consumes tokens, and so does an AI summary. File scanning consumes compute that scales with file size and file count, while metadata generation runs per object. None of that flattens out as a customer gets more engaged. It compounds.
The first decision was structural rather than numerical. Usage had to be metered and charged, because a flat tier sitting on a variable cost base is a bet that your heaviest users stay rare. That bet gets worse every time the product gets better.
Calibrating a rate is a costing exercise first
Before I could set a credit rate for an operation, I needed the cost of that operation at the level it actually varied. Token consumption on a RAG query varies with retrieved context length and response length. File scanning varies with file size and format, while metadata generation runs per object rather than per byte. Those are different cost drivers, and one blended rate across them would have let one operation quietly subsidize another.
The failure mode there is silent, which is what makes it expensive. A blended rate looks accurate at launch because the launch mix is the mix you priced against. Then a large account arrives whose workload is mostly one operation, and the rate that was right on average is wrong on that account by a wide margin. Nothing alerts you. Revenue grows while gross margin degrades one cohort at a time, and by the time it surfaces in a quarterly review you are explaining a trend instead of correcting a rate.
Pricing each operation against its own cost removes that exposure. It also makes the model legible internally. When engineering changes how metadata generation works, there is a rate attached to that operation, so the pricing consequence is a line item rather than an investigation.
What a credit abstraction buys, and what it costs
A credit is a layer between the customer and the cost. It lets you hold one currency in front of the user while the rates underneath move independently. If the cost of an operation falls, you can change what a credit buys for that operation without republishing a price list or reopening a contract.
The cost of that abstraction is transparency and understanding. A customer who cannot predict their bill will either underuse the product or leave after the first surprise, and both outcomes are worse than a less elegant price would have been. Credits work when the conversion between a familiar unit of work and credits is something the customer can hold in their head. They stop working when the customer has to model your system to forecast their own spend.
That tension does not resolve. You are trading pricing flexibility against customer forecastability, and where you land depends on how volatile the underlying costs actually are. When costs are moving fast, the abstraction earns its complexity. When they settle, the case for it weakens and the honest move is to simplify.
Getting the rates right sets the floor. It does not set the price. A rate calibrated to cost with no margin structure above it is a cost-recovery scheme, and cost recovery gives away the part of the product that was hardest to build, which is everything wrapped around the inference call. The rates gave me a defensible floor and margin visibility at the operation level. What is included in a plan and how overage behaves are commercial decisions, and having the floor right is what lets you make them on purpose.