Measure AI costs before you price your product.
Track model usage per customer and keep provider costs separate from what you charge.
A model name is not a cost model
Two customers on the same plan can create very different infrastructure costs. Long prompts, repeated tool calls, large outputs and caching behavior all affect the cost of serving an AI feature.
Start by recording usage against a stable customer identifier. Capture the model and token counts with the operation that produced them, rather than trying to reconstruct them from a monthly total.
Use current examples, keep rates configurable
The refreshed OurPay examples use GPT-6 Astra and the Responses API. OurPay’s event metadata can record a model identifier; that identifier does not automatically maintain a provider’s changing price list.
Use the provider’s current rate card for the service tier and features you actually use. Separate cached input, uncached input and output where applicable. Record tool or infrastructure costs separately instead of assuming token pricing covers everything.
Keep units explicit
OurPay’s cost-event amount is expressed in cents. Convert provider prices into that unit deliberately, and preserve enough precision for small API calls. Revenue, provider costs and your product’s usage price should remain distinguishable.
For example, a token count can power a usage meter while a cost event records what the provider charged to serve that request. They describe the same activity from different perspectives.
Price from observed behavior
Review the distribution of usage, especially the customers who cost much more to serve than the average. A plan can combine a base subscription, included credits and a clearly disclosed usage limit.
The useful question is whether the plan covers the work it actually causes. A current model name in a demo is helpful; measuring real usage is what makes the pricing decision defensible.