AI pricing must expose workload variance before margins

AI pricing must expose workload variance before it promises margins. I want to know what changes the cost of delivering the same billable unit before I believe a forecast built around its average. A request, an action, and a completed task are commercial abstractions. None tells me how much context the system read, how much it generated, or how much reasoning it used. If those quantities vary, the price model is also a decision about who absorbs that variation.

The first distinction I make is between the unit customers understand and the resources the provider charges for. A customer might buy document reviews. Underneath, one review may involve a short input and a label; another may involve a long document and an extended explanation. Input and output tokens can have different rates, so counting total tokens alone loses information that matters. Charging the same amount for both reviews can be deliberate. Treating them as the same cost because they share an invoice label cannot.

Blended token prices make this mistake look respectable. A weighted rate helps compare providers when the assumed input-to-output mix resembles the work being bought. I would keep that assumption visible rather than promote the blended number into a universal cost. A classification feature and a drafting feature need separate estimates even when they use the same model. Their combined average describes the current product mix; it does not guarantee the economics after customers start using more of the expensive feature.

Reasoning introduces another separation between what the buyer sees and what the system consumes. A short final answer need not imply a cheap run when billable reasoning tokens precede it. I would record the provider-reported usage components and reconcile them without counting the same tokens twice. More importantly, I would connect that usage to the feature and the selected reasoning configuration. Otherwise a product change that enables deeper reasoning can alter delivery cost while the visible output and customer price remain unchanged.

My pricing worksheet would therefore begin with workload classes, not a target margin percentage. For each class I would state the expected input size, output requirements, reasoning mode, and whether processing can wait. I would examine ordinary runs alongside expensive runs and ask what happens if the latter become a larger share of demand. This is a sensitivity test, not a prediction dressed as certainty. Its purpose is to identify which product promises make the business dependent on a favourable workload mix.

Timing belongs in that worksheet because asynchronous batch pricing exchanges responsiveness for a different cost structure. I would not use batch economics to justify a price for work promised immediately. Committed-volume discounts introduce a different dependency: the quoted saving rests on usage and contractual terms, including what happens when demand falls short. Neither discount removes workload variance. Each changes the conditions under which a delivery-cost estimate holds, and those conditions should travel with the margin forecast.

There is one boundary to my argument: a fixed price per request is sensible for a narrowly specified workflow whose input limits, output limits, reasoning configuration, and observed cost distribution remain stable. I would not force token-level billing onto that customer. The simplicity is earned by the bounded workload, with a review triggered when those bounds change, rather than by assuming every future request resembles the initial sample.

For a broader product, I would choose allowances, overage rules, or separate service tiers only after exposing these differences. A subscription can make the base bill predictable without making delivery costs constant; an overage rule needs an intelligible unit and clear limits. The customer does not need my entire cost ledger. They need to understand which choices change their bill, while I need to understand which choices change my obligation. Margin is the result of that agreement under a stated workload mix, not a property I can attach permanently to a pricing page.