An AI request has an awkward billing shape: the final cost is unknown when it starts, but a prepaid wallet must still prevent overspend. Charging a rough estimate is unfair; waiting until the response finishes can let concurrent requests spend the same balance. A reservation-and-settlement ledger resolves both problems.
01
Reserve first, charge the meter later
Before inference begins, OurToken computes a bounded estimate from the active model price and the request limits. The wallet places that amount on hold. Available balance decreases, but no customer charge has been finalized.
When the provider returns usage, the request settles against the actual normalized meters. The ledger charges the measured amount and releases the unused hold. If validation or delivery fails, the reservation is released instead of becoming a charge.
- Held balance prevents concurrent overspend.
- Settled balance reflects measured usage, not the estimate.
- Unused funds become available immediately after settlement.
- Failed requests release their holds with a bounded reason code.
02
Prices are effective-dated facts
A current pricing page is not enough to explain an old invoice. Every usage record therefore snapshots the public meter price used for that request. Later catalog or route changes do not rewrite the record.
The customer sees an Official Price and any disclosed Provider Surcharge. Internal Cost stays private and is separately effective-dated for profitability. This preserves a stable customer explanation without pretending operations have no cost.
03
A ledger, not a mutable balance cell
The wallet balance is derived from durable credit lots, holds, settlements, releases, refunds, and adjustments. Paid and promotional credit remain separate because they have different refund and expiry behavior.
Allocations are deterministic, so the same settlement cannot consume credits twice. A repair job can reconcile a stale in-progress request from ledger state without inspecting its prompt or response.
request accepted
→ reserve estimated maximum
→ invoke active model route
→ record normalized usage
→ settle actual customer charge
→ release unused reservation04
What the customer should be able to answer
For any completed request, a customer should be able to identify the model, meters, snapshotted prices, final charge, time, and API key. They should not need access to private provider costs or application content to reconcile their bill.