没有一款消费级应用知道单个免费用户这个月烧了多少

总额你知道，里面谁花了多少你不知道

在消费级应用里加了聊天或语音功能的团队，月底会收到一张账单。总额是清楚的，这笔钱里谁花了多少则不清楚。

Inworld按2026年7月7日的标价算过消费级AI应用的单位经济，量级由此可见。按每个活跃日50条聊天或10分钟语音计算，每日活跃用户的月成本随技术栈不同，在0.09美元到18.24美元之间。语音这一端，级联方案约为每月2.58美元，用OpenAI的gpt-realtime-2.1则约为每月18.24美元。再放进3%的付费转化率，一个付费用户大约要承担33个人的AI账单，而这份负担必须装进每月5到20美元的订阅价里，生意才成立(Inworld)。

这套算法里埋着一个假设：免费用户的用量差不多。现实几乎不可能如此，可是关于免费层成本究竟向头部集中到什么程度，公开资料很难找到。这也说明团队自己内部同样没在看这张分布图。

于是应对方式变得粗糙。成本一吓人就把免费额度对所有人一起下调，被砍掉的往往是还没体会到产品价值的新用户。在激活之前撞墙的人不会回来，而真正在烧钱的那一小撮，额度降了照样用到新的额度为止。

现有工具看的是别处。企业内部的LLM支出治理按员工和团队切分，路由工具按请求挑更便宜的后端。这两者都假设花钱的人属于自己这边。消费级应用里花钱的是一个匿名账号，要不要限制他，判断依据不是成本而是转化可能性。

单价降下来多少，团队就把多重的功能免费开出去

token单价一直在降，消费级应用的成本问题反而更清楚了，因为省下来的部分被团队用来免费开放更重的功能。原本只走一行文本的位置换成了语音和长上下文，单用户月成本因此上升到与订阅价同一个数量级。

与此同时消费级应用的付费转化率没有跟着变。转化率不动而成本上升，一个付费用户要养的免费人数就会增加，很快越过订阅价能摊开的边界。总额看板在这个位置什么也说不出来，它只告诉你这个月多了30%，却不区分这是新增流量带来的，还是几个重度用户造成的。

每次调用都把用户和功能名一起记下来

以SDK或代理的形式挡在LLM调用前面，每次调用都记录用户标识和功能名称。到这一步和现有的观测工具一样。不同的是下一步：把每个用户的累计成本，和这个用户的转化信号放在同一块屏幕上。注册后的天数、是否完成了核心动作、再次打开的间隔。

免费用户于是分成四块。成本高但没有转化信号的，成本高且接近转化的，成本低也没有信号的，成本低但快要付费的。该设限制的只有第一块。

quadrantChart
  title 免费用户的位置
  x-axis 转化信号弱 --> 转化信号强
  y-axis 成本低 --> 成本高
  quadrant-1 现在就引导付费
  quadrant-2 该设限制的地方
  quadrant-3 保持原样
  quadrant-4 再多展示价值

MVP一块看板就够：按用户排的成本榜、旁边是他们的转化信号，再加一个模拟，显示砍掉成本头部区间之后激活指标会怎么动。真正的拦截功能放在后面。等团队开始照着这些数字自己定阈值，产品再接手去执行这些规则。

按节省下来的金额定价更容易谈成。用这套工具的团队本来就知道每月花多少，省下多少可以直接看到。

免费用户的成本必须是偏斜分布才成立

核心假设只有一条：免费用户的成本分布必须真的明显偏斜。如果分布是均匀的，就没有按人看的必要，调整整体额度即可。拿三四家早期客户的日志看几周就能验证。

第二个假设是，成本最高的那批用户和转化最好的那批用户确实不是同一批人。如果用得多的人最后就是会付费的人，那么这个产品建议的每一次限制都是在劝人砍收入。这一点要在导入初期就验证，结果不同的话，产品方向要从限制工具转向判断付费提示时机的工具。