Your best customer is your worst margin

Software pricing has spent twenty years resting on one assumption: that serving one more user costs you approximately nothing. Storage and bandwidth are rounding errors, so you charge per seat, and the customer who uses the product constantly subsidises the four who forgot they had it.

Agents break that assumption, and most pricing pages haven't noticed yet.

Every action now has a real, variable, externally-set cost attached. Which means the customer who loves your product most is the one quietly destroying your margin, and the pricing model you inherited actively hides that from you.

Per seat: a bet that usage is evenly distributed

A seat price is a wager. You're betting that average usage across your users stays below the point where the seat stops paying for itself.

Usage is never evenly distributed. It follows the same long tail as everything else: a small group of users does most of the work, and in an agent product "does most of the work" means "spends most of the money." Your ten most engaged customers can cost more to serve than your next hundred combined.

The strategic damage is worse than the arithmetic. Per-seat pricing on a variable cost base quietly inverts your incentives: the customers getting the most value become the ones you'd rather had a quieter month. Those are also your reference accounts, your case studies and your renewals. A pricing model that makes you hope your best customer uses the product less is a pricing model that will eventually cost you that customer.

None of which shows up anywhere, because blended margin across the whole book looks fine. The average is healthy and the distribution is the problem.

Pure usage pricing: honest, and very hard to sell

The obvious correction is to charge for what you consume. Pass the tokens through with a markup. It's honest, it scales with cost, and your margin is safe.

It also doesn't sell, for two reasons that have nothing to do with fairness.

The customer cannot forecast it. Procurement needs a number to put in a budget. "It depends how much you use it" is not a number, and an unpredictable invoice is a renewal risk every single month rather than once a year. Buyers will knowingly pay more for a price they can predict, and they're being rational when they do.

You've made their bill depend on your engineering. This one gets missed. If you price per token, then your decision to add a reasoning step, or retry more aggressively, or switch to a chattier prompt, lands directly on the customer's invoice. You've handed them a bill that moves for reasons they can't see and didn't cause. The first time it jumps thirty percent with no change in their behaviour, you're explaining your own release notes to their finance team.

Per outcome: right in principle, with a catch

Charging per resolved ticket, per processed invoice, per completed reconciliation is the model that actually matches how the customer thinks about value. They're not buying tokens. They were never buying tokens.

The catch is the one we've written about before: you absorb the cost of everything that didn't finish. If you charge for successes and pay for attempts, then your margin is a direct function of your success rate.

That cuts both ways, and it's worth being clear-eyed about both.

It's healthy, because it puts your engineering incentives exactly where they should be. Every point of reliability you gain is margin. Nobody has to be persuaded that fixing the retry loop matters.

It's also a real exposure. A model update that quietly degrades your success rate is now a margin event, not just a quality one. A customer whose data is messier than average can be structurally unprofitable at the same list price as everyone else. If you go down this road, your success rate becomes a number the finance team cares about, and it needs to be watched like one.

What we'd actually recommend

None of the three works alone. The shape that survives is a hybrid, and it's not complicated.

// A plan that survives contact with a variable cost base needs three parts.
// The allowance is denominated in outcomes, not tokens, because tokens are a
// unit the customer cannot forecast and did not ask to buy.
type Plan struct {
    PlatformFee  int64  // charged regardless of use. Covers the floor.
    Included     int    // outcomes included per period
    OverageEach  int64  // per outcome beyond the allowance
    HardCeiling  int64  // total spend at which we stop and call them
}

// What it actually costs us to serve one customer on that plan.
type Margin struct {
    Revenue      int64
    AttemptCost  int64 // every attempt, including the ones that went nowhere
    Succeeded    int
    Attempted    int
}

func (m Margin) GrossMargin() float64 {
    return float64(m.Revenue-m.AttemptCost) / float64(m.Revenue)
}

// The number that decides whether the plan is priced correctly.
func (m Margin) CostPerSuccess() int64 {
    if m.Succeeded == 0 {
        return m.AttemptCost // all of it bought nothing
    }
    return m.AttemptCost / int64(m.Succeeded)
}

A platform fee that's charged regardless of usage. This covers your floor, makes revenue predictable on your side, and prices the part of the product that exists whether or not anyone runs anything.

An allowance denominated in outcomes, not tokens or calls. Five hundred resolved tickets, not four million tokens. The customer can reason about the first number and cannot reason about the second, and the unit you quote is the unit they'll judge you by.

Overage priced per outcome, so growth in their usage shows up as growth in your revenue rather than growth in your cost.

A hard ceiling, with a phone call attached. Not a cliff the customer hits silently, but a point at which spend stops and somebody talks to them. A fixed-price plan with no ceiling is an unbounded liability, and the fact that it's never been triggered is not evidence that it won't be.

Three things have to be true first

Every model above, including the one you already have, depends on knowing things most teams can't currently measure.

• Cost attributable to one customer, across every provider you use. If you can't produce that figure, you don't know your margin per account, and no provider console will produce it for you.
• Failed attempts counted in the denominator. Pricing off cost per success while measuring only successes produces a number that looks better the worse your system gets.
• A ceiling that acts before the spend, not after. A limit you discover at month end is a report, not a control.

That's the real reason agent pricing is hard, and it isn't a commercial problem. Every pricing conversation turns into an instrumentation conversation about ten minutes in.

The question to take to your next review

Not "what's our gross margin." That number exists and it's probably fine.

Ask what the variance is. A business running 80% blended margin with two points of spread across its customers is a healthy software company. One running 80% with forty points of spread is several different companies wearing one price list, and nobody has noticed because the average is reassuring.

If you can't answer that question today, that's the thing to fix. The pricing follows from it, and it's a much easier decision once the number is on the table.