Prepaid billing, pricing, and usage
Understand the live retail price source, balance-backed requests, and the difference between authoritative totals and UI estimates.
ReferenceAvailability: Stable
On this page
Prepaid model
The consumer product uses prepaid credit rather than subscription seats. A successful metered request reserves and captures cost against the applicable balance or wallet according to the key and organization configuration.
For a standalone developer key, /topup creates a funding session and reveals the newly funded key once at /claim. Signed-in account checkout instead funds the account's default runtime key. It does not fund a separately issued Settings key.
Use the Pricing page for human browsing and https://api.impossi.build/pricing.json for machine-readable retail rates.
Token-cost formula
For a standard text request, the public estimate is:
cost = (prompt_tokens × prompt_rate_per_million / 1,000,000)
+ (completion_tokens × completion_rate_per_million / 1,000,000)Model-specific cached-token, reasoning-token, per-request, media, or upstream billing behavior can differ. The settled gateway event is authoritative, not a client-side estimate.
Account views
- Billing shows the authenticated key's authoritative balance and rolling use, available promotional or affiliate credit lots, and top-up controls.
- Usage shows authenticated-key-scoped gateway totals plus app-derived model and space views and CSV export. It is not an account-wide aggregation across every key.
- Current consumer funding history is intentionally empty when the gateway cannot provide a safe key-scoped history; the UI does not fabricate it.
Authoritative versus estimated data
The authenticated key's balance and recent spend total come from the gateway's money source of truth. UI time-series and per-model groupings are derived from app-stored messages, and the Space selector samples those daily points rather than filtering an authoritative gateway dimension. Read them as estimates. Reconciliation-sensitive workflows should use gateway settlement records or operator reports.
Zero-price rows
Do not treat every zero-looking catalog row as free. The storefront currently normalizes unavailable values, so zero can also represent unknown or on-request pricing. Only a clearly published positive rate or explicit free designation should drive automated spend decisions.
Low-balance behavior
A request can be rejected when the key or backing wallet cannot reserve the required ceiling. Do not repeatedly retry a balance error. Top up the key or satisfy an advertised accountless payment challenge. Attaching a BYOK credential through Settings does not currently bypass the Singular credit balance requirement.