Understand every cent before you send a request.
Model.sale uses one prepaid blended rate per model. The public rate is easy to compare, while the usage ledger keeps the detailed token mix and the exact final charge.
The short answer
For a completed request, the charge is the reported charged-token amount multiplied by the current public price. A reservation floor may be held before dispatch, but it is not a final fee and the unused part is released:
charge = charged_tokens / 1,000,000 × blended_rate\nfinal_charge = measured_charge\nreleased_reservation = reserved_amount - final_chargeThe price version is snapshotted when the request is admitted. A later price change cannot change an in-flight request. If terminal usage is missing, the request remains billing_pending for reconciliation instead of being charged by guesswork.
What “charged tokens” means
Protocols name usage fields differently, so Model.sale normalizes them into a consistent ledger view:
| Usage field | How it is shown | Billing treatment |
|---|---|---|
| Input / prompt | Input tokens | Included once in charged tokens |
| Cached input | Cached tokens | Retained separately; the active blended model price defines the charge |
| Output / completion | Output tokens | Included once in charged tokens |
| Reasoning | Reasoning tokens | Diagnostic subset when reported; never added on top of output |
If a protocol does not return terminal usage, the request is marked billing_pending rather than silently guessing a final amount.
Worked examples
Examples use a $0.09 blended rate. The reservation floor is only a temporary hold; your model’s current rate is shown on the pricing page.
| Charged tokens | Raw calculation | Final charge |
|---|---|---|
| 10,000 | $0.0009 | $0.0009 |
| 100,000 | $0.009 | $0.009 |
| 1,000,000 | $0.09 | $0.09 |
| 2,000,000 | $0.18 | $0.18 |
A conversation with several messages is settled message by message from each response’s measured usage.
Failed requests
A request rejected before model dispatch does not consume inference. Admission, error class and any released reservation remain visible in usage.
Streaming
Streaming responses flush immediately. A completed terminal event settles reported usage; disconnects follow the provider’s documented usage policy.
Limits
Wallet balance, key limits and the single-request cap are checked before dispatch. The gateway never substitutes a different model to fit a limit.
How to compare prices fairly
Official APIs commonly publish separate input, cached-input and output rates. A percentage “saving” is meaningful only for a stated workload with the same token mix, currency and cache rules.
- Measure the input, cached and output mix in your own requests.
- Apply the official tariff to that exact mix.
- Apply the Model.sale blended rate to the measured charged-token total.
- Include failed-request, retry, reservation release and rounding behavior in the estimate.
Reference prices on the comparison page include a source URL and check date. They are not a benchmark or a promise that similarly named models produce identical output.
Price versions and transparency
Every public rate has an effective version, a reservation floor and a checked timestamp. The reservation is not a final charge: after terminal usage, only measured tokens are settled and the remainder is released. Availability is separate: an unavailable model can retain a visible price while its route is being repaired, but it cannot receive customer traffic.
Model.sale does not store prompts or response bodies for billing. Operational records contain request metadata, token counts, charge, margin and safe error classification.