Billing.
Prepaid dollars, an integer ledger, and a published formula. Every response is its own receipt.
Credits
You top up in USD from the dashboard (Stripe checkout, fixed amounts). There is no subscription and no monthly minimum — credits sit in your account and each call deducts its metered price. When the balance reaches $0.00, calls are refused with 402 insufficient_credits; the ledger never goes negative.
The ledger
Balances are kept as integers in micro-USD (1 µ$ = $0.000001), so there is no float drift — ever. The ledger is append-only: top-ups, charges, and promo credits are individual rows, and every usage charge carries the request_id of the call that caused it. What you see in the dashboard is the same ledger the API reads.
What a call costs
charged = ceil(upstream_cost × 1.5) floored at $0.0001 per billable call
upstream_cost is the real price the provider charges us for that call at its published rates — not a bundled estimate. We resell at a flat 1.5× multiple, rounded up to the next micro-dollar, with a $0.0001 minimum per billable call. Per-mode differences (deep research costing more than a plain search, say) flow straight through from the upstream price sheet.
Token-billed providers
| provider | metered from actual usage |
|---|---|
| jina | tokens processed, as reported per response |
| perplexity | flat request fee + tokens in and out |
| xai | flat search fee + model tokens + sources consumed |
For these three, the flat price is only the base: the token component is computed from the usage the upstream actually reports on each response, then passed through the same 1.5× formula. A short answer costs less than a long one — we do not bill worst-case token estimates.
Failures are free
Only calls that return results are charged. Upstream failures (502), internal faults (500) and calls where every engine came back empty are logged with their request_id and refunded in full.
"Refunded" is literal. Before a call is dispatched we reserve the most it could cost against your balance, because otherwise two simultaneous requests could each pass a balance check and spend money that only exists once. A successful call settles that reservation down to the real cost; a failed one returns all of it. You may briefly see a reservation-sized dip in balance_usd — the ledger records both movements, so the arithmetic is auditable rather than merely promised.
Receipts & invoices
Every successful API response carries billing.charged_usd and billing.balance_usd, so your client always knows what it just spent and what is left. Top-ups generate numbered invoices, listed in the dashboard with PDF download.