Buying service usage for your account and settling an individual model request are different records. The purchase explains where your available usage came from; settlement explains how much a particular request consumed.
Following each record through its own process makes temporary balance changes easier to understand. It also helps you decide when to check the original request and when to contact support.
What to take away
- Purchased service usage is consumed at the selected model's billing rates.
- A quote confirms a request; its reservation and final settlement may differ.
- A disconnected browser does not prove the request failed. Check the original request first.
1. Separate a service purchase from request consumption
tokvilo API usage belongs to the purchasing account and can be used in its APIs and Playground. API credits are a display unit for that service balance, at a fixed $1 = 35 credits, with the USD equivalent shown alongside. This unit does not change model rates, actual usage or charges. One-time packs do not automatically renew or promise a fixed number of requests. What you can run depends on the model, parameters and actual consumption.
For online purchases, check the final checkout amount and verified payment record. Enterprise transfers follow the arrangements confirmed by email, with usage added after an administrator verifies receipt. Taxes do not add API credits. Digital goods keep their separate indicative CNY prices and cannot be purchased with API credits. A purchase or allocation record does not replace a particular request's settlement details.
2. Read the quote together with its billing unit
Different models and tasks may charge by input and output usage, image count, video specifications or another interface-specific unit. The pricing page shows tokvilo's rates in credits alongside their USD equivalent. Check that units match before comparing the numbers.
A Playground quote applies to the current model and parameters. Review it again after changing the model, adding input or changing output specifications. It helps you decide whether to submit that request; it is not a fixed price for every future request.
- Confirm the exact model ID and selected options.
- Check quantity, length, resolution and other parameters that affect the amount.
- Review the billing unit and request quote before confirming execution.
3. A reservation holds credits while a request is active
When a request is submitted, the system reserves the quoted credits. Other requests cannot spend that reserved balance again. Once the result and actual consumption are confirmed, the request is settled and releasable excess is returned.
Here is a hypothetical example to explain the process, not a price for any model: a request reserves 3.5 credits ($0.1) and its confirmed consumption is 2.1 credits ($0.06), so the remaining 1.4 credits ($0.04) are released. Always use the original request's settlement record when checking a real charge.
| Stage | What to check |
|---|---|
| Quote | Current model, parameters, proposed credits and USD equivalent |
| Reservation | Original request ID and task status |
| Settlement | Confirmed consumption and released credits |
| Adjustment | The record linked to the original request or payment |
4. Check the original request after a disconnection
A browser timeout means you did not receive a complete result over that connection. The request may still be processing or may need reconciliation. Submitting a new copy immediately can create two separate requests.
Keep the original request ID and use the page's query or recovery action to check its status. Usage may remain reserved while the result is unconfirmed. Support can use that ID to inspect request and billing records.
If you see an explicit insufficient-balance message, check your available usage and what other tasks have already reserved. A previous purchase does not mean the current available balance is enough for every request.
5. Releasing usage and refunding payment are separate
Releasing a reservation restores available service usage. It does not send money back to a card or bank account. A payment refund requires a review of the purchase, delivery, consumption and applicable refund rules.
Contact support about duplicate payments, a payment without allocation, undelivered service or a potentially incorrect charge. Provide your account email, transaction or bank reference, and relevant request IDs. Do not send passwords, API keys or full card details.
Online purchases follow the applicable refund policy and non-waivable statutory rights. An approved refund adjusts the corresponding service usage. See the payment information and refund policy pages for the process.
Understand payment before buying usage
Review API usage packs, enterprise transfer arrangements, and payment and refund policies.
Continue payment ↗