Prepaid billing, pricing, and usage

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.
• Funding history under Billing lists the account's settled and pending top-ups with amount, status, and date, read from the platform's payment records, and exports to CSV. Value added outside those records, such as a satisfied per-call payment challenge, is not a funding entry.

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 does not bypass the Singular credit balance requirement: BYOK decides which upstream key serves the request, not whether Singular meters and bills it.