Picture the feature everyone praised at the last review. An AI assistant bundled into your $20-per-seat plan. Adoption climbs, the usage chart goes up and to the right, and someone screenshots it for the board deck. Three months later finance flags that gross margin on that plan fell eight points. The feature people love most is the one bleeding the most cash.
This is the part 2026 made real. For fifteen years, a heavily used SaaS feature was free margin. You paid to build it once, then every extra click cost you close to nothing. AI broke that assumption. Every generation, every retrieval, every tool call now carries a per-use cost you pay in real money to a model provider.
So usage stopped being a vanity metric you could let run wild. It became a cost driver. And the more a user loves your AI feature, the more of your margin they quietly consume.
The margin trap behind every active user
Run the math on one power user. Say your assistant costs four cents per interaction in tokens, and a heavy user fires 600 interactions a month. That's $24 in raw inference cost against a $20 seat. You're underwater before you count infrastructure, support, or the rest of the product they barely touch.
The trap is the distribution. Most users stay light, a few go heavy, and the heavy tail is where the loss concentrates. Average cost per user looks fine on the dashboard while your top 5 percent of accounts each cost more than they pay. The monetization guides call this exact pattern heavy-user margin collapse, and it shows up almost only in AI products.
Flat-rate and per-seat pricing make it worse. Both decouple what you charge from what a user consumes. A seat costs the same whether someone runs two prompts a week or two hundred a day, but your bill from the model provider tracks the second person, not the first.
The healthiest-looking adoption curve and the steepest margin decline can be the same chart. If you only watch one, you'll celebrate the feature that's sinking the plan.
Make cost per interaction a first-class metric
You can't price what you don't measure. Most teams track activation, retention, and revenue per account, then treat inference cost as a line item finance worries about later. By the time it surfaces in a margin report, the pricing is already shipped and hard to unwind.
Put three numbers next to the usual growth metrics:
- Tokens per session: the typical and the 95th-percentile token spend for one real task, not an average that hides the tail.
- Cost per active user: monthly inference spend divided by active users, then again for your heaviest decile so you can see the spread.
- Break-even usage: the interaction count where a plan's cost to serve crosses the price the user pays.
Once you have break-even usage, you know exactly which accounts are profitable and which ones invert. That single threshold turns a vague margin worry into a number you can design pricing around.
This is unit economics applied to a feature instead of the whole business. The same chain still holds: contribution margin is revenue minus the variable cost to serve, and a negative contribution margin on your most engaged users is a structural problem, not a rounding error. If the model isn't familiar, walk the metrics through the unit economics calculation topic, and use the unit economics assistant to pressure-test your CAC, LTV, and contribution margin before you commit to a price.
Price the value, not the tokens
Here's where most teams misfire. They feel the cost problem and reach for the cost lever: meter everything, pass the bill straight through, charge per token. That protects margin and kills adoption, because buyers can't forecast a token bill and won't sign up for a meter they don't understand.
The stronger move is to anchor price to the value the feature creates, then choose a model that lets cost scale underneath it. That's the whole point of monetization and pricing as a system: value capture first, mechanics second. A support AI that resolves tickets isn't selling tokens. It's selling resolved conversations and lower handle time, and the price should ride that outcome.
A few model patterns fit AI features better than flat seats:
- Hybrid: a base subscription plus variable usage or overage. Keeps the bill predictable for the buyer while letting your revenue grow with the cost you're absorbing.
- Credit-based: users buy a pool of credits they spend across actions. Kyle Poyar has tracked the broad shift toward AI credits precisely because they give buyers a budget and give you a governor on consumption.
- Outcome-based: charge per result delivered, like tasks completed or tickets resolved. Powerful when attribution is clean and the buyer trusts the count.
Picking among these is a strategy call, not a spreadsheet exercise. It depends on your buyer, your channel, and how variable your cost is. The pricing and monetization assistant is built to work through that decision with you: it maps the feature's value metric, weighs hybrid against credit against outcome pricing for your specific cost structure, and flags where each model puts friction. Treat it as the place to define the monetization strategy for an AI feature before you wire up billing, not after the margin report lands.
Gating that protects margin without capping growth
Pricing sets the ceiling. Gating controls what happens between the floor and that ceiling. Done well, it keeps the heavy tail from sinking the plan while leaving the experience generous for the people who'll never come close to the limit.
The principle from the monetization playbook applies cleanly: put friction after value is proven, not before. A new user hitting your AI feature for the first time should never see a meter. A user on their four-hundredth call that month is a different conversation.
Practical moves, lightest to heaviest:
- Soft caps with clear signals. Generous included usage, then a visible nudge as someone approaches it. Most users never notice; the heavy tail gets a fair warning instead of a surprise bill.
- Fair-use limits per tier. Bake an interaction ceiling into each plan so the model cost stays bounded by design. The included amount becomes a packaging lever, not a hidden risk.
- Metered overage above the line. Once a user passes the included usage, charge for the excess. The base stays predictable, and the cost driver finally connects to revenue where it actually bites.
- Credits for the heaviest workflows. When usage is genuinely unbounded, a credit pool turns an open-ended cost into a budget the buyer controls and you can forecast.
The goal isn't to punish your power users. It's to make sure the accounts driving the most cost are also driving the most revenue, so love and margin point the same direction.
When to cap, meter, or tier
The right control depends on how usage and value line up, not on what feels generous. A simple read:
- Cap when usage past a point adds cost but little extra value, like a user re-running the same query out of habit. A ceiling here protects margin and costs you nothing real.
- Meter when more usage means more value and you can bill the overage without spooking the buyer. This fits hybrid pricing, where the base covers the common case and the meter handles the tail.
- Tier when distinct segments use the feature at structurally different volumes. Let the light segment buy a light plan and the heavy segment self-select into one priced for their consumption, with the middle tier designed as the default.
Run every AI feature through one question before launch: at what usage level does this account stop being profitable, and what happens when a real user crosses it? If you can't answer, you're not ready to price it. That threshold, paired with a unit economics model you actually trust, is the difference between a feature that compounds and one that quietly taxes every win.
Adoption was the goal when building was the only cost. Now building is cheap and serving is not. The PMs who win the AI margin game treat cost per interaction as a product decision they own, price for the value underneath it, and gate the tail before it sinks the plan. Get that right and the feature everyone loves becomes the one that pays for the rest.
