Recently, I’ve been pondering: what is the true essence of a payment model?

One sentence: just pay.

These five words represent the most elegant promise in modern business. They mean—once the user pays, everything else is taken care of. No waiting, no learning, no repeated trial and error. The result emerges naturally, and value is delivered directly. What users are truly buying is a guaranteed outcome, not a complicated process.

Looking back at the evolution of many industries, the shift has fundamentally been from “paying for the process” to “paying for the result.” Renovations are no longer billed by the day but by the delivery standard; consulting is no longer charged by the hour but priced based on effectiveness; software subscriptions follow the same logic—you’re not buying code, but the ability to solve a problem. The process can be complex, but users want it hidden.

In other words, the best service is one that users don’t even notice exists.

This is also why I’ve always had reservations about the per-call, per-token billing model for large language models. The number of calls or tokens consumed doesn’t represent the value of the result. The output of these models is too uncertain—you may need multiple rounds of trial and error, constant prompting, and repeated validation just to get a “usable” answer. That experience feels more like “paying for uncertainty.” In the end, users aren’t paying for intelligence; they’re paying for chaos.

A truly sustainable business logic isn’t about making billing more complex—it’s about standardizing results.

Standardization means compressing the volatility of the process into deliverable certainty: fixed quality, reusable templates, stable output. For large language model products, this translates to—not selling APIs, but selling results. Not selling reasoning capabilities, but selling ready-to-use “outcomes”: a polished piece of copy, a competent block of code, a deployable solution.

Standardization makes “just pay” possible. Users shouldn’t have to understand tokens, call counts, or prompt engineering—these intermediate steps. The ideal product form is one where users simply pay and receive a “solved problem.” The shorter the path from payment to result, the more refined the experience; the fewer the distractions, the more solid the business model.

Perhaps a great product should be like water—you don’t need to know its flow; just turn on the tap, and it comes out naturally. What users want isn’t control, but certainty; not participation in the process, but peace of mind in the result.