Skip to content
SingularSingular

Prepaid billing, pricing, and usage

Understand the live retail price source, balance-backed requests, and the difference between authoritative totals and UI estimates.

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:

text
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.

Updated 2026-08-10. Live model availability, rates, account state, and payment rails remain request-time data.