An average is like crossing a river that is one metre deep on average: the near bank is ankle-deep, the middle is over your head. Compare average cost per user with the average price and you will often see a reasonable margin; but the invoice is cut by the tail, not the average user. Cost grows linearly with requests while a flat price stays put, so above some threshold every extra request eats profit. Bessemer's AI pricing playbook frames the difference like this: in classic SaaS, serving one more customer costs virtually nothing, while in AI every query incurs a non-trivial expense. a16z, in a 2020 piece, also called cloud infrastructure a substantial, and sometimes hidden, cost for AI companies. That is why the tool asks for two user definitions, typical and heavy. It returns three numbers: typical margin, heavy margin, and the blend of the two.

The pricing model reshapes that distribution. Under a flat price there is a loss threshold and everything above it is a loss; your heaviest user is the one who costs you most, not the one who pays most. Under usage-based pricing, cost passes through to the customer and margin holds as long as the price per request covers cost per request; if it does not, every request loses money. Bessemer notes that outcome-based models require you to absorb cost variability, and describes hybrid models as a way to give customers predictability while capturing upside, calling it an effective middle ground for early-stage startups. Poyar wrote in 2024 that the perceived uncertainty of usage-based pricing spooked many companies, and that in the SaaS slowdown usage-based businesses saw growth decelerate faster than subscription ones. In his 2024 look at 40 leading AI startups, most application-layer companies chose subscriptions and very few use pure usage-based pricing. This is our inference: cost follows usage, while revenue often does not. In a hybrid, move the included requests (Q). If the loss threshold sits below Q, the included part is already losing money; if it sits above Q and the overage price covers cost, there is no loss beyond it. Where to put Q is a rule of thumb, not a proven optimum. In the outcome-based model (the fourth option in the tool) every request is an attempt: you are paid only for a successful one, and the cost of a failed attempt stays with you. According to Bessemer, a difficult customer issue can consume far more compute than anticipated, and the model works when you are confident in your AI's performance, when you can absorb cost variance, and when the outcome is unambiguous and measurable. Beyond the cost variability Bessemer describes, our reading (interpretation) is that the success rate is what erodes margin fastest: as it falls, the same cost is divided by less revenue. The tool therefore shows the margin separately if the success rate drops.

In Turkey there is an extra layer: providers list prices in dollars, while your revenue may arrive in lira. If the exchange rate rises and your lira list price lags, your margin erodes without you changing anything. It is a logic similar to inflation; as on the Real Growth page, the nominal figure grows while the economy underneath can shrink. The tool shows this in two ways. Set the currency to TRY and switch to the "Cost $, price ₺" mode: you enter token prices and other variable cost in dollars and your prices in lira, and the tool converts the dollar cost to lira at the rate you enter. The table shows where typical, heavy and blended margin go when the rate rises 10, 25 and 50 percent with the lira price held fixed. The last column answers a separate question: how much the price must rise to keep the same lira profit. The tool makes no rate forecast; it does not say where the rate is going or call one scenario likelier than another. It only calculates the rate you enter and those four scenarios, and the default rate is an example, not the current rate. The calculation assumes all cost is in dollars. If you pay some line in lira (say, a support team), a rate rise does not grow it by the same share; read the result with that in mind. If you do not use the rate mode, the inference cost change input and the sensitivity table ask the same question as a general cost increase.

The tool is only as accurate as its inputs. Take request counts and token averages from your own logs rather than estimates, and derive the heavy-user multiplier and share from the real distribution. The default values are examples, not current prices or an industry benchmark. It does not model cache write fees as a separate line; it uses only the cached share and the read price. Two user groups are also a simplification of reality. And the tool shows only the cost side: whether high usage means buying intent or abuse, and what value the user gets, you must read elsewhere. If you put your pricing page next to the bill your heaviest user runs up, would you still write the same price?