AsaleMetering & settlement
Where token counts come from, how they are cross-checked, and what stops a seller from inventing them.
The number you are billed on is the usage the upstream provider reported. Everything below exists to make sure that is the number that actually reaches settlement.
Three sources of truth
| Source | Used for |
|---|---|
The provider's own usage figures, parsed from the upstream response | Pricing. This is the fact. |
| A gateway-side estimate of output tokens | Cross-check and ceiling |
| A gateway-side estimate of prompt tokens | Cross-check and ceiling |
The estimates are heuristics — character-class weighting, not a vendor tokeniser. They exist to catch order-of-magnitude nonsense, so their tolerance is deliberately wide.
Cross-check
The reported and estimated counts are compared on both the input and output side. A deviation above 25% is recorded against the seller's reputation. It does not change the price.
Cache reads count on the input side, so a heavily cached session is not mistaken for a discrepancy.
Hard ceilings
These do change the price:
- Output is capped at the authorised budget. Every dispatch carries a signed budget; a seller cannot bill for more output than it authorised.
- Prompt is capped at three times the gateway's own estimate (or the estimate plus 1,000 tokens, whichever is larger). Over that, all four counts are scaled down proportionally so the ratio between token types is preserved.
A seller reporting nine million tokens for a small request gets billed at the ceiling and earns a risk event on their record.
Settlement
One database transaction, per request:
- Capture the hold
The frozen estimate is captured and the difference returned to your available balance.
- Cap at what exists
The charge can never exceed held + available. Your balance cannot go negative.
- Move the money
You are debited. The seller's Payable is credited with the price minus the 8% fee. The fee goes to the platform account.
- Write the ledger
Three double-entry rows, which must sum to zero.
- Close the task
Token counts, price, fee and latency are written to the request, and a settlement row with a unique key makes a double charge impossible.
If the transaction fails it is retried with backoff — never re-run blindly, because the settlement key makes a repeat a no-op rather than a second charge.
Reconciling it yourself
Both sides keep local records, and both sides can compare them against the server's. They should agree on token counts. Where they differ, the server's figure is the one that settled — the local record is for your own audit, not for billing.
Records, in the client and on the website, is the same data.