#Product
#AI & Agents
Giant Context writes your knowledge base, the help articles a customer reads to answer their own question, out of your own material. Writing them is o...
Jesse James Richard
Read previous|
May 9, 2026Billing in dollars, tracking in tokens
|
5 min read
#Method
#Architecture
#Growth
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.
By the seat | Raw metering | Dollars and tokens | |
|---|---|---|---|
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.
Hiring an early engineer, or building something like this
Remote, Pacific time, full-time or contract. Get in touch.