Billing in dollars, tracking in tokens
An earlier piece made the case that this platform's cost of goods is tokens, and that every event the system records carries what it cost. That was the measurement. It left a question for later. If the cost of serving a customer changes with every page they generate, what goes on the invoice?
Why neither pricing model fits
Charging by the seat, the way software has been sold for years, does not fit here, because a seat does not consume anything. One customer with a few users can generate more pages in a week than another with a full team. The cost follows the pages, not the head count. A seat price would overcharge the light user and lose money on the heavy one.
The other model is to meter the usage and bill it, the way compute is usually sold. It is honest, and for a variable cost it is the natural fit. It also asks the customer to sign up for a number they cannot see in advance, and a bill that arrives as a surprise makes people stop using the product to stay safe.
The usual escape from that is an abstraction. Credits, points, units, some invented currency bought in blocks, so the customer reasons about a stable thing and the volatility stays on the vendor's side of the line. It is the standard answer and I did not take it. There is no credit in this product and never has been.
What the customer sees
The bill is in dollars. The meter is in tokens. Both are on the same screen.
A customer spending six dollars in a month sees the six dollars, and underneath it the token count that produced it, priced at twenty-five dollars per million tokens. Nothing is converted into a currency I invented. That rate is the same whatever they generate and has not moved since billing existed, so the unit price never changes even though their volume does.
This is where the earlier measurement pays off. Because every event already carries what it cost, the billing does not need a second system to work out what to charge. It reads the same record. The thing built to answer why a request was slow and what it cost is the thing the customer's bill is drawn from.
Matches the cost
No, a seat consumes nothing
Yes, exactly
Yes, metered to the token
Predictable for the customer
Yes
No, a surprise bill
Yes, a fixed rate and a cap
What the customer holds
A head count
A meter they cannot see
A dollar figure and a token count
The cap
Showing the meter leaves the fear that made metering unacceptable in the first place, that usage runs away and the bill with it. So the account has a cap. The customer sets the most they are willing to spend in a month, the balance is watched against it, and past the cap the work stops rather than the bill growing. The wording in the product is plain about it. AI requests are blocked once spend reaches this amount.
That is the trade. An abstraction protects the customer from volatility by hiding it. A cap protects them by stopping it. The first asks them to trust a currency they cannot check, and the second lets them watch the real number knowing it cannot pass a line they set.
Showing all of it
So the customer sees exactly what the platform sees. The same tokens, the same cost, the same record, priced at a rate that does not move and bounded by a number they chose. The counting was never the hard part, because the measurement came first. The hard part was deciding how much of it to show, and the answer turned out to be all of it.
Building something like this
I'm Jesse. I build platforms end to end, and I'm open to work. If this is the kind of engineering you need, get in touch.