Usage-based pricing is spreading fast across software, and it is a fair question whether media should follow. The logic sounds clean: people pay for exactly what they consume, and price tracks value.
Whether it works, though, depends on a prior question that usually goes unasked: what are you actually pricing?
Price the unit of value, not the format
The useful principle is that pricing should follow the economic unit of value, not the delivery format or the type of customer. Get the unit right and the choice of model becomes much clearer; get it wrong and no pricing cleverness rescues it.
For some products the unit of value is a discrete, countable thing: a compute cycle, an API call, a document retrieved. For others it is continuous and hard to count: a relationship, a habit, a sense of membership.
Usage-based pricing fits the first kind - not so much the second.
That, rather than “humans versus machines,” is what determines where it belongs.
Why it misfires for habitual reading
For most consumer reading, the value is not a countable unit. Many consumer publishers are selling continuing access, habit and affiliation, not a metered quantity of compute. Charging by the article tries to price something that was never really discrete.
It also works against the behavior the publisher most wants.
When readers cannot predict the bill, they have an incentive to reduce exactly the reading the business depends on.
A flat subscription removes that friction and lets the habit form; a meter reintroduces it every time someone opens a page. That is why per-article charging has struggled to become a mainstream model for general consumer news, even as it works elsewhere.
There is an operational cost too - accurate metering, dispute handling, reconciliation - and a forecasting effect worth being precise about. Consumption pricing does not create revenue volatility out of nothing; flat subscriptions already swing with acquisition and churn. What it does is move part of the variance from subscriber count into consumption volume, which makes forecasting and reconciliation more complex.
None of this means readers reject usage pricing everywhere - they accept it readily for utilities, transport and mobile data. It just means that for habitual reading specifically, the unit of value does not lend itself to a meter.
Why it can fit machine access
Now change the customer, and the unit changes with it.
Machines do not want a pricing model - they don’t really want anything. But the parties operating them evaluate contracts on predictability, marginal value and measurable usage rather than habit. And machine access has a property habitual reading lacks: it’s often measurable in an explicit way. An AI company training on your archive, or an agent retrieving articles on demand, consumes in units you can actually count - requests, documents, tokens, the scope of the archive reached.
That measurability is what makes consumption-style contracts viable for machine access where they would fail for readers. It is a property of the value, not a preference of the customer. And it is not universal: plenty of machine deals are better served by fixed licenses, minimum commitments or flat enterprise terms.
The point is not that machines take usage pricing and humans take subscriptions. It’s that machine access is more often measurable in a way that makes consumption pricing sensible.
So what should actually be metered?
If the unit of value is the thing to price, it is worth being concrete about what those units can be.
Depending on the deal, machine access might be priced by:
- requests or calls
- documents retrieved
- token volume
- freshness — how current the content is
- archive scope — how much of the back catalog is reachable
- training rights — permission to use content to train a model
- the number of end users the output eventually serves
These are very different bases, and the right one depends entirely on where the value sits for that customer. “Per request” is one option among many, not the default.
The system has to recognize the unit
Here’s the practical catch.
Running more than one pricing logic - a flat subscription for readers, one or more metered arrangements for machine access - is not something a subscription billing system does on its own. That’s not because billing cannot calculate usage charges; modern billing systems, Stripe Billing among them, handle metered pricing perfectly well. It’s that billing does not identify each incoming requester, decide which content policy applies to them, and enforce that decision before the content is served.
It prices the relationship once you know what the relationship is - working out what it is, per request, is a different job.
That job belongs to an access layer: it recognizes who or what is asking and applies the commercial rule the publisher has configured for that relationship - a flat entitlement for the subscriber, a metered one for the machine, whichever unit the contract uses. Same content, different units of value, resolved at the point of request.
Get that right and you stop charging readers for a habit they would rather not count, and you can price machine access in the unit that actually reflects its value.
