System One
System One
DocumentationSDK documentationModelsAPI referenceOpen System OneDocumentation index

SDK & API

Build with decisions

Choose a modelDecision primitivesAgent integration: typed tool routingSystem One for coding agents (Claude Code, Cursor, Codex)

Usage & data

Billing and creditsPrivacy and zero data retention

Billing and credits

How System One credits work for the hosted decision API and where to manage billing. New accounts get 100 credits on signup; credits never expire.

System One hosted API uses prepaid credits for evaluations. The Playground and your API connections use the same account balance. The open-source SDK itself does not require these credits; direct SDK connections to other services use those services' billing. Check your hosted account balance in the console before starting work.

Answer-ready

Q: How do System One API credits work?
A: The hosted System One API meters usage in credits. New accounts get 100 credits on signup, and credits never expire. Manage billing from your account console.

Check the selected model's price

Models can have different prices. In the Playground, select a model and click the Model information button beside the selector to review its current rate and limits, rather than assuming that every request costs one credit. Details are hidden until opened. The pricing page is for credit packs. Available models and prices can change; Choose a model explains what to compare.

The Playground estimates the cost of your current request before you submit it. Loading an example is not a billable evaluation; running it is a real request.

How a request's cost is calculated

The cost depends on three things:

  1. Question count: every question in the request contributes to the charge.
  2. Full request size: use the selected model's pricing.bytesPerBlock UTF-8 bytes per block, rounding up with a minimum of one block.
  3. Selected model's rate: the credit price per question per block.
blocks = max(1, ceil(canonicalRequestUtf8Bytes / selectedModelBytesPerBlock))
credits = questionCount × blocks × selectedModelRate

“Canonical request” means the parsed, consistently represented full request—not just the message you want reviewed. It includes the selected model, context, questions, option names, criteria, and any supported extra fields. Formatting spaces do not add to this billing size, but the content inside text does. UTF-8 bytes are not the same as characters; Chinese text and emoji can use several bytes per character.

Hypothetical examples

For arithmetic only, suppose a model uses 4,096-byte blocks and costs 2 credits per question per block. This is not a current model price or a quoted offer.

Full canonical request sizeQuestionsBlocksExample cost
1–4,096 bytes111 × 1 × 2 = 2 credits
1–4,096 bytes313 × 1 × 2 = 6 credits
4,097–8,192 bytes323 × 2 × 2 = 12 credits

All questions share the context, but each question is charged for the full request's block count. A score or probability does not change the price: the calculation is based on the request, not whether you agree with the answer. Token counts, when shown, are separate usage information and do not replace this credit formula.

The full submitted request must also fit the selected model's limits.bytes: Jev and HTTP modes retain 64KB (65,536 bytes); migrated Clef/Clef Flash entries allow up to 13MB (13,631,488 bytes), with smaller administrator limits preserved. Formatting counts toward this submitted-size limit even when it does not add to billing size. The entire images field—including base64 strings and media types—counts toward parsed-request billing, not just the decoded image size. Image count and decoded-byte limits apply separately. Check image limits and the updated Playground estimate before running; an image is not a flat-price attachment.

Model availability, default selection, limits and pricing can change. Check the current catalog before starting a new operation. An operation already admitted keeps its reserved charge; a failed operation refunds that amount. Successful same-key replay remains free even after a price change or model removal from the public catalog.

Buy a one-time credit pack

Sign in and open the pricing page, or the purchase section of your console billing page. Choose a pack and review the amount, currency, and number of credits at checkout before paying.

Credit packs are one-time purchases, not recurring subscriptions. The current checkout is authoritative; this guide does not fix pack amounts or prices. After the payment is confirmed, check your account balance for the purchased credits. If payment appears complete but credits have not arrived, contact support with your order reference rather than paying again immediately.

Welcome credits

New accounts get 100 free credits on sign-up. Each account receives this grant once. Creating more API keys or signing in again does not add more welcome credits.

How billing blocks work

Cost is based on request size: every 4KB is one block, and anything smaller than 4KB still counts as one block. Cost = blocks × questions × the model's unit price.

For example, a 6KB request with 2 questions on Jev (1 credit per block) = 2 blocks × 2 × 1 = 4 credits.

Credits never expire

Credits never expire. You can see your recent usage history in the console. Looking up older history later does not change your balance.

Failures, repeat requests, and uncertain outcomes

What happenedWhat it means for you
The request was rejected for sign-in, input, or insufficient-credit reasons before evaluation.No new evaluation charge is created. Correct the cause before trying again.
An evaluation failed and its credit return is confirmed.The evaluation's credits have been returned. This is a credit adjustment, not a cash refund.
The service reports that billing is still being resolved.The final charge is not yet known. Check usage and contact support if it remains unresolved.
Your browser or application timed out, disconnected, or was closed.This does not prove the request failed or was free. It may have completed. Check usage before submitting again.
An API connection successfully recovers an answer using the original request and replay key.The recovered answer is not charged again. This is a replay, not a new evaluation.
You run the Playground again or make a new API request.It can be a new billable evaluation, even when the questions look identical.

A replay key is called an idempotency key in the API. Create a new key for each new business operation; save it with the complete request and reuse both only for retries of that operation. Keys are scoped to your account, so changing API keys does not create a separate replay scope. Within the retention window, the same key with a changed request returns 409 idempotency_conflict without a new evaluation charge. An unchanged successful request replays the original answer without another charge—it does not run a fresh evaluation.

Successful answers can be recovered within 24 hours from request creation. This is not permanent duplicate protection. After expiry, another submission can be a new charge. A retry's X-System-One-Credits: 0 means no additional charge for that HTTP attempt, not that the original operation was free or its pending credits have been returned. See Request recovery for pending, failed, and uncertain outcomes.

Do not assume a missing charge value means zero or that every error confirms a credit return. In particular, avoid repeatedly pressing Run after an interrupted Playground request.

Cash refunds for purchases are separate from credits returned for failed evaluations. For purchase questions, contact support@system-one.dev; this guide does not promise an automatic cash refund.

Review usage and get help

The console shows your balance and activity for the latest 30 UTC calendar days, including the latest 50 requests in that period. UTC day boundaries may differ from your local time. This recent view is not a complete lifetime record.

For a charge you do not understand, keep the request ID when available, approximate time, and any order reference relevant to a purchase. Send those details to support@system-one.dev. Never send an API key, sign-in code, or full payment-card details.

For a disputed or interrupted operation, retain X-Request-Id and, when available, X-Upstream-Request-Id, then review the ledger with support. Request metadata and replay-cache retention are described in Data and privacy.

In Credits & billing → Balance & activity, the balance overview separates available credits, total received (purchases plus bonuses), and total used (before refunds). Online activity lists each change and its balance after the transaction. Choose 10, 25, 50, or 100 entries per page; changing the page size returns to page one. Use the first/last and nearby page numbers, or enter a valid page number and press Enter or Go to jump directly. Dates and times use your local timezone. Desktop tables become compact rows on mobile without truncating descriptions. Switch to Archived history to retrieve your private older records; returning to online activity keeps your page and page size until you reload. Archive date filters use UTC.

Older usage history

Credits never expire. The console shows your recent usage history. Older records may leave that recent view later; your available credits and lifetime totals stay the same. You can download your own older records from the billing page. Other accounts cannot download them.

System One for coding agents (Claude Code, Cursor, Codex)

Install the System One agent skill and paste a prompt for classification, tool routing, or completion checks in Claude Code, Cursor, or Codex.

Privacy and zero data retention

How System One handles request data, retention, and privacy for the hosted API.

On this page

Answer-readyCheck the selected model's priceHow a request's cost is calculatedHypothetical examplesBuy a one-time credit packWelcome creditsHow billing blocks workCredits never expireFailures, repeat requests, and uncertain outcomesReview usage and get helpOlder usage history