Qufas AI

Overview

Qufas AI uses prepaid USD credits. Add credits from the dashboard, send requests withqf_sk_ API keys, and Qufas deducts the measured model usage from your balance after each successful billable request.

Billing records are visible in the dashboard alongside request logs, so teams can connect spend to model, provider, API key, token usage, latency, and request status.

Credits

Credits are denominated in USD and are stored on the account balance. The current Stripe checkout flow accepts card payments from $1 to $1000 per top-up.

A checkout creates a pending transaction first. When payment is confirmed, the transaction becomes succeeded and the credit amount is added to the balance.

Each credit purchase has a payment processing fee calculated as the greater of amount × 5.5% and $0.80. This fee applies only to the credit top-up; it is separate from model usage cost and does not apply again to each API request. The fee is paid in addition to your purchased credits, not deducted from them. Credit and fee amounts are rounded to whole cents; the percentage fee is rounded to the nearest cent before the minimum is applied.

A settled credit purchase adds the purchased credits without rounding your existing fractional-cent balance. The balance update and successful transaction record are committed together; repeated confirmation or webhook delivery does not credit the same payment again. If payment and balance records disagree, contact support for reconciliation rather than submitting the payment again.

Credits purchased	Processing fee	Checkout total
$10.00	$0.80	$10.80
$100.00	$5.50	$105.50

Usage Charges

Qufas calculates usage from provider response metadata and the selected model's configured pricing. Text usage separates input and output tokens so different rates can be applied accurately. See the current registry-backed rates on Models & Pricing.

For per_1m_tokens, divide each token count by one million exactly once. The database rounds input and output costs separately to 12 decimal places in USD, then adds them. There is no minimum token count or minimum token-usage request charge; rounding is not a positive fee floor. Dashboard currency formatting can display fewer decimals than the stored charge. Input and output counts come from the provider's prompt_tokens and completion_tokens. There is no separate cached-token discount or reasoning-token rate in this billing path; tokens included in those counts use the corresponding input/output rate.

Token billing (USD)

1input_cost  = round(input_tokens  / 1_000_000 * input_rate_per_1M, 12)2output_cost = round(output_tokens / 1_000_000 * output_rate_per_1M, 12)3cost_USD    = input_cost + output_cost

Before provider execution, inference requires a balance greater than zero; otherwise the API returns HTTP 402 insufficient_balance. This check does not reserve credits or guarantee that the final charge will fit. At settlement, the database reads the current model price and locks the balance row. Concurrent usage charges serialize at that row; a charge exceeding the remaining balance is rejected, not applied as a negative balance. Usage, deduction, and the billing transaction commit atomically for a successful usage charge.

If balance is spent during generation, settlement may fail after output has already been produced. Non-streaming Chat Completions can return HTTP 402 at this stage; an already-open stream reports an in-band billing error instead of changing HTTP status. Other accounting failures may also occur after generation. Keep enough balance for concurrent work and reconcile usage by request ID before retrying.

For streaming, client-facing include_usage=false does not disable provider usage collection or billing. For non-streaming Chat fallback, failed provider attempts are not separately billed; only the final successful logical operation is charged. If every attempt fails, no successful-result usage charge is created.

Stopping a response stops client receipt/display, not necessarily provider generation. Final usage may include tokens generated after Stop. When final provider usage reaches accounting, the logical operation is settled once using tenant-scoped idempotency; Stop does not waive that charge. An incomplete stream, missing usage chunk, or[DONE] alone is not proof of billing success or zero cost. See the Stop and disconnect contract before reconciling or retrying a request.

Text models	Input and output tokens are billed from model pricing per 1M tokens.
Image models	Image generation is recorded as usage with model, provider, cost, and latency.
Streaming	Streaming requests are charged once usage is known for the completed request.
Fallback	Failed provider attempts are not billed separately; one successful logical operation is charged once.
Failed validation	Requests rejected before provider execution are not usage-charged.
Insufficient balance	Requests are blocked before model execution when balance is not positive.

Balance API

Use the balance endpoint to show remaining credits inside your own internal tools. The endpoint uses the same Bearer token authentication as other Qufas API endpoints.

Request

1curl https://qufas-ai.vercel.app/v1/billing/balance \2  -H "Authorization: Bearer qf_sk_your_api_key"

200 response

1{2  "object": "balance",3  "balance": 20.75,4  "currency": "USD"5}

402 response

1{2  "error": {3    "message": "Insufficient balance. Please recharge before making requests.",4    "type": "insufficient_balance"5  }6}

Transactions

Billing transactions represent both credit top-ups and model usage. Use transaction status together with the balance and ledger to reconcile changes. For a credit purchase, the transaction amount is the credit amount; processing fee and payment total are separate metadata, shown when recorded. Legacy records may not have a fee breakdown.

Status	Meaning
pending	A Stripe checkout session was created, but payment has not been confirmed yet.
succeeded	Credits were added or usage was charged successfully.
failed	The payment or billing operation reported a failure. Reconcile the account ledger before retrying; status alone is not proof that no balance change occurred.

Best Practices

Keep production API keys server-side and avoid exposing them in client applications.
Use separate API keys for development, staging, and production billing visibility.
Set monthly spend limits on high-risk or experimental keys.
Log the Qufas request ID so usage charges can be traced back to application events.
Use Idempotency-Key for duplicate-operation protection; do not use request IDs as idempotency keys.
Monitor balance before large batch jobs to avoid mid-run insufficient balance errors.

A Generation exposes the stored historical cost for one request. It is observability metadata, not an account ledger; use Usage and Billing APIs for aggregation. See Generations.