Prairie Labs

A Sustainable Monetization Model for Artificial Intelligence

Usage incentives for AI services

The chief issue with existing artificial intelligence monetization methods is that users who haven't exhausted their time-constrained usage may run meaningless processes in order to extract the most value out of their subscription as possible.

For example, if you take a user who:

  • Has only used 40% of their limit in the first six days, assuming usage resets weekly
  • Their week's work is entirely one project
  • Has already completed 90% of a project

That user may be inclined to:

  • Expend the remaining 60% of their total usage for only 10% of the project
  • Open up a new front and expand the project last-minute
  • Start a new project entirely

This results in an effect where extra usage is applied to work with a lower token-to-meaning value. Applying 60% to a new project may be more total work, but given the lack of steering, it is likely largely meaningless.

How can services escape this trap? If the nature of subscriptions is such that users feel inclined to extract all the value out of them, and LLM cost is determined on a per-token basis, then what can be done to reconcile the two? This is particularly relevant because high-volume usage can become expensive very quickly.

There is also a psychological element at play if users are forced to pay on a per-token basis. It is equivalent to watching money drain from your bank account. A service where users watch a meter gradually evaporate money in their checking account is not one people will be inclined to use.

The solution is rather simple. Instead of charging on a per-token basis or a flat monthly subscription, both of which can create bad incentives, users may purchase a subscription and receive cash-back if they have extra remaining usage at the end of the subscription period. Insofar as this cash-back does not exceed the actual cost saved by the service, it is a net positive.

Consider the following:

  • An AI service introduces a subscription of $20/month
  • A user exhausting the monthly usage limit expends $20 of compute
  • One user spends $10 in compute
  • They receive $5 at the end of the month as a reward for conserving
  • The service still nets $5

This can be applied in ways ranging from giving users a certain percent down to the penny or even something as simple as giving any user who stays under some general percentage a fixed chunk of change.

It also reverses the psychology. By being conservative in how they use the model, users are literally given cash which goes directly into their bank account or rolls over to the next month of the subscription.

This method makes it impossible to lose money on compute. How much you make is simply a question of how conservative users are. If the subscription is $50, but that $50 only grants $40 of compute, you are already making $10 per user, but you also get a nickel for every dime of compute the user does not expend.

The provided hypothetical does not consider all of the other costs associated with running a large service. Compute is only one component. That being said, you can determine the per-user value of every other cost and bake it into the subscription.

There is another monetary system which may generate savings and, as is the case with the above model, increase general efficiency. Instead of charging users per-token, charge users per-unit of energy. I often find myself having a very long conversation in a single context window which likely could have been reset multiple times. This is terribly wasteful.

Tokens are abstract. Units of energy can be equated to a shower, phone, or hamburger.