No Consumer App Knows What One Free User Burned This Month

You know the total, not who spent what inside it

A team that put a chatbot or a voice feature into a consumer app gets one invoice at the end of the month. They know the total. They do not know who inside it spent what.

Inworld’s unit economics work on consumer AI apps, priced against July 7, 2026 list rates, gives the shape of the number. Monthly cost per daily active user runs from $0.09 to $18.24 depending on the stack, assuming 50 chat messages or 10 voice minutes per active day. Voice lands at about $2.58 per DAU per month on a cascaded stack and about $18.24 on OpenAI’s gpt-realtime-2.1. Put a 3% paid conversion rate against that and each paying user is carrying roughly 33 people’s AI bills, and the whole burden has to fit inside a $5 to $20 monthly subscription (Inworld).

One assumption is buried in that math: that free users consume at similar rates. They almost certainly do not, and published data on how concentrated the spend actually is inside a consumer free tier is hard to find. Which suggests most teams are not looking at that distribution internally either.

So the response ends up blunt. Cost gets alarming, the free limit drops for everyone, and the users who get cut are the ones who have not yet felt what the product does. A user who hits a wall before activation does not come back. Meanwhile the small group actually driving the bill keeps consuming right up to whatever the new limit is.

Existing tooling looks somewhere else. Internal LLM spend governance slices by employee and team. Routing layers pick a cheaper backend per request. Both assume the person spending your money works for you. In a consumer app the spender is an anonymous account, and the decision to cut them off is not a cost question. It is a conversion question.

As unit prices fell, teams opened heavier features for free

Token prices keep falling and the consumer cost problem got sharper anyway, because teams spent the savings on heavier free features. Voice and long context moved into slots that used to hold a single line of text, which pushed monthly cost per user into the same order of magnitude as the subscription price.

Consumer conversion rates did not move to match. When conversion stays flat and per-user cost rises, the count of free users each subscriber carries grows past what a consumer price point can divide. A total-spend dashboard is silent exactly here. It reports that this month came in 30% higher and leaves the team guessing whether that was new signups or a handful of heavy accounts.

Log the user and the feature name on every call

Sit in front of the LLM call as an SDK or a proxy and log a user identifier and a feature name with every request. That part matches existing observability. The difference is what happens next: put each user’s accumulated cost on the same screen as that user’s conversion signals. Days since signup, whether they finished the core action, how long between sessions.

Free users then fall into four boxes. High cost with no signal, high cost with conversion close, low cost with no signal, low cost and about to pay. Only the first box is a place to put a limit.

quadrantChart
  title Where free users sit
  x-axis Weak conversion signal --> Strong conversion signal
  y-axis Low cost --> High cost
  quadrant-1 Ask for the sale now
  quadrant-2 Cap here
  quadrant-3 Leave alone
  quadrant-4 Show more value

The MVP is one dashboard. Per-user cost ranking, the conversion signals beside it, and a simulation of what happens to activation metrics if the top cost band gets cut. Enforcement comes later. Once a team starts setting its own thresholds off those numbers, the product can offer to enforce them.

Pricing against measured savings is the easier sell. These teams already know what they spend each month, so a reduction shows up without an argument.

The cost distribution among free users has to be lopsided

One assumption carries the idea: cost across free users has to be genuinely lopsided. If it is evenly spread there is no reason to look per user and a global limit does the job. Logs from three or four early customers settle this within weeks.

The second assumption is that the highest-cost users and the highest-converting users are different people. If heavy usage is what predicts payment, then every cap this product recommends is advice to cut revenue. Test that early, and be ready for the answer to turn the product from a limiting tool into a tool for timing the upgrade prompt.