Credits and billing
Estimate decision costs, purchase prepaid credits, and understand refunds.
Request cost
Decision credits are separate from provider tokens. Cost is computed from the validated request before inference:
blocks = max(1, ceil(canonicalRequestUtf8Bytes / 4096))
credits = questionCount * blocksCanonical JSON sorts object keys, preserves array order, and includes the effective model: the explicit alias/version, or the deployment default (otherwise jev-latest) when omitted. Billing counts the entire canonical request, including state, questions, names, criteria and extensions. A required state: null, omitted/null instructions and nullable Noul criteria retain their original JSON meaning. Formatting whitespace is not billed as extra canonical content, although it counts toward the raw request limit. UTF-8 bytes are not character counts, especially for Chinese text.
| Canonical request size | Questions | Credits |
|---|---|---|
| 1–4,096 bytes | 1 | 1 |
| 1–4,096 bytes | 3 | 3 |
| 4,097–8,192 bytes | 3 | 6 |
These are arithmetic examples. Raw requests must also satisfy the separate 64 KiB limit. A larger state is shared across questions, but each question is charged for its block count. Unknown upstream token usage remains unknown and does not change this formula.
Prepaid packs
| Pack | Credits | Price (USD) |
|---|---|---|
| Starter | 10,000 | $10 |
| Builder | 60,000 | $50 |
| Scale | 300,000 | $200 |
Packs are one-time purchases, not recurring subscriptions. These are the repository’s configured packs; the deployed checkout is authoritative for a particular installation. Prices and credit amounts are selected by the server from config/plans.ts, not supplied by the browser.
Sign in and choose a pack on the main website’s pricing page. When Stripe is configured, checkout uses TinyShip’s existing order, payment, and credit fulfillment flow. Credits are granted after server-side payment validation; visiting a success URL is not proof of payment. Repeated fulfillment must not add the same purchase twice. The purchase updates the same account balance used by both the API and playground.
Welcome credits
The default welcome grant is 100 credits, once per account after email verification and a session-authenticated System One interaction. Operators can set SYSTEM_ONE_SIGNUP_CREDITS from 0 to 10000; zero disables the grant. Check the console for the actual configured amount and balance. New keys, repeated sign-ins, and repeat visits do not create extra grants.
Local setup can permit unverified sign-in for development; that does not make the account email-verified and does not bypass the welcome-credit condition.
Reservations, refunds, and replays
The service reserves credits in the shared D1 ledger before contacting the model. Requests that cannot be funded return 402 insufficient_credits. Concurrent requests use transactional accounting so they cannot spend the same available balance twice.
On success, the reservation becomes the request's billed amount. On an ordinary inference failure, it is refunded before the error response. Authentication, local admission validation and missing-provider failures do not create a new inference charge. Native upstream errors retain their original 4xx/5xx status and JSON unless a documented safe replacement is required. A 401 from the provider is not a platform session error; inspect the error classification headers. Interrupted reservations are reconciled by scheduled cleanup; see failure recovery.
A successful idempotent replay does not reserve or charge again. Its X-System-One-Credits is 0, X-Idempotency-Replayed is true, and X-Request-Id identifies the original ledger operation. Read these headers for accounting. New success bodies contain no injected platform billing or IDs; any provider-owned billing, request_id or replayed is not platform metadata. New caches preserve the original text/status/allowed headers; legacy caches have explicit upgrade limitations. A new key—or a request without one—represents a new potential charge.
After a confirmed refund, the charge header is also 0. A 503 request_reconciliation_pending omits it because the balance is unsettled: never convert a missing charge header to zero. The TypeSafe model list requires a platform key but creates no decision reservation or charge. openrouter-adapted evaluations use the same platform ledger; any provider-reported usage cost remains separate.
Inference credit refunds are separate from Stripe cash refunds. The deployment operator handles cash refunds, disputes, and chargeback reconciliation against orders and the credit ledger; these adjustments are not automatically promised by this integration.
Usage records
The console shows persisted balance and decision activity for the latest 30 UTC days, including the most recent 50 requests in that period. It does not substitute demonstration usage for missing data. A latency measurement reflects that recorded request; it is not an upstream performance guarantee. Omitted provider token counts are not estimated.
For a disputed or interrupted operation, retain X-Request-Id and, when available, X-Upstream-Request-Id, then review the ledger with the deployment operator. Request metadata and replay-cache retention are described in data handling.