TL;DR (June 2026): If you sell software at a flat per-seat price and your product calls an LLM that bills per token, your margin is a bet that no seat ever runs an agent. That bet is now losing in public. As one widely-shared take put it in June: "if your product sells flat per-seat and your LLM bills per-token, the math breaks the moment a power user starts an agentic loop... every enterprise AI pricing meeting is this debate." The mechanism is brutal arithmetic: an agentic task consumes roughly 1,000x more tokens than a one-shot chat, so a single power user can burn more COGS in a week than their annual seat price. The escape is not a bigger seat price - it is to meter consumption and price against it, whether you expose usage-based pricing to the customer or just instrument it to protect margin and gate runaway accounts.
We have covered the buyer's side of this - unlimited AI plans are dead and the spend cap won. This is the builder's side: you are the one selling the flat plan, and an AI feature just turned your predictable per-seat COGS into a long-tailed, per-token liability. The seat price was a fixed number; your cost behind it is now whatever your heaviest user decides to do this month.
The arithmetic that breaks per-seat
Per-seat pricing works when cost-to-serve is roughly flat across users. Storage, a login, some bounded compute - the 95th-percentile user costs about what the median user costs, so one price covers everyone and the spread is your margin. LLM features detonate that assumption, because agentic usage is not a heavier version of chat usage; it is a different order of magnitude. A one-shot completion is cents. The same task rebuilt as an agent that plans, calls tools, and loops can cost dollars - and the gap between a casual user and a power user running agents all day is not 2x, it is closer to 1,000x.
So the distribution of cost-to-serve goes from a tight bell curve to a power law, and a single flat price cannot straddle a power law. Price for the median and one power user erases the margin on a hundred others. Price for the power user and you are uncompetitive for everyone else. This is the same runaway we documented from the cost side in the $1,400 hour - except here it is not your bill, it is your customer's behavior landing on your P&L.
Why "just raise the seat price" fails
The instinct is to bump the seat price to cover the heavy tail. It does not work, for two reasons. First, you are now overcharging the 90% of users whose agentic usage is light, which is a churn and acquisition tax that compounds. Second, it does not actually cap anything - the power user who blew the old price will blow the new one too, because nothing in a flat plan is connected to consumption. You have made the median user subsidize the tail more heavily without stopping the tail. The other side effect is trust: opaque, lumpy costs hidden inside a flat plan are exactly what erodes developer trust in metered billing when the true cost eventually surfaces.
What actually works: meter first, then price
The durable answer is to make consumption visible and let price track it. That does not necessarily mean putting a per-token meter in front of the customer on day one - it means instrumenting usage so that whatever pricing model you choose is grounded in real cost-to-serve. The June consensus among practitioners, including the "route workloads by value" framing from the router pattern, converges on a few moves:
- Meter every account's token consumption attributed to that account, so you know your real per-customer margin before you set a price - not after the vendor invoice arrives.
- Pick a model that survives the power law: usage-based, hybrid (a seat that includes an allowance plus metered overage), or prepaid credits. All three require a meter underneath; only the meter is non-negotiable.
- Gate, don't just bill. A soft cap that alerts and a hard cap your app enforces turn an unbounded liability into a bounded one. The meter measures; your app decides what to do at the threshold.
- Route by value. Send cheap tasks to cheap models so the per-account cost curve is as flat as you can make it before pricing has to do the rest.
The order matters: meter first, price second. A pricing model chosen without per-account consumption data is a guess, and on a power-law cost curve a guess is how you discover your worst-margin customers by accident, one invoice at a time.
The honest take
Per-seat pricing is not dead for software - it is dead for the part of your software that calls an LLM and lets a user point an agent at it. You can keep a seat price; you cannot keep a seat price that is blind to consumption. The companies getting this right in 2026 are not the ones with the cleverest pricing page - they are the ones that instrumented usage early enough that pricing became a decision instead of a postmortem. As we argued in why usage metering needs its own database, the meter is the foundation every viable AI pricing model now stands on. UsageBox is that meter: per-account, per-model usage with real-time spend caps, so a single agentic power user is a tracked, bounded line item instead of the surprise that eats your quarter.