Skip to main content
Rock API charges depend on the model, the group used for the request, and the applicable billing rules. Check the current model catalog and prices, then reconcile completed requests against your dashboard usage logs. A displayed base price alone is not a quote for your final charge, and there is no universal discount across all models or API calls.

​
Read the currency and unit first

Open the model details and record the exact model ID, billing mode, selected group, currency, and price unit. Availability and rates can change; this guide does not maintain a separate price list. Use the currency label shown on the page: USD and CNY amounts are not interchangeable. Balance and usage displays can use a configured currency or quota units. Internal quota units are accounting units, not a count of model tokens. Payment currency and credited balance also need to be checked separately on the top-up order.

​
Usage-based, per-call, and dynamic billing

Usage-based billing combines the chargeable usage categories with their rates. Where cache, image, or audio tokens have their own price, avoid counting them again as ordinary input or output tokens. Upstream usage formats differ; use the normalized categories in the billing breakdown rather than adding every response field together. Per-call billing uses the configured unit price and the billable quantity. An image or task request can also depend on parameters such as quality or duration. Do not apply a token formula to a model marked as per-call. Dynamic billing evaluates a model’s pricing expression. The result can depend on context length, token categories, or request conditions. The service saves the expression and group multiplier for the request and uses that snapshot for settlement. Check the matched tier in the log; the lowest displayed tier may not apply to your request. For a flat token rate, you can reconcile the arithmetic without assuming any particular prices:
Use this formula only for flat token pricing. For per-call pricing, replace the token calculation with unit price * billable quantity; for dynamic pricing, evaluate the applicable rule. Use rates before the group multiplier, or effective rates with it already included, consistently. Do not apply the multiplier twice. The settled amount also reflects conversion to internal quota and rounding.

​
Group multipliers and top-up costs

A group multiplier changes API consumption cost relative to the configured model base rate. The group actually used, an account-specific group rate, or automatic group routing can affect the result. Check the request’s logged group and applicable multiplier, even if you previously viewed a different group in the catalog. Top-up pricing determines how much you pay to receive balance. It can depend on payment settings, account group, or an offered top-up discount. This is separate from the group multiplier used when consuming API balance. Compare the payment amount and credited balance on your order; a group multiplier is not, by itself, a guaranteed discount against a provider’s public price. OpenAPI marketplace subscriptions and renewals follow the selected service’s displayed plan and terms. Check those separately from AI model token prices.

​
Pre-consumption and settlement

Before sending an eligible request upstream, the service can reserve estimated quota. This estimate can include an output allowance, so the temporary balance change may exceed the final charge. Account balance and API key quota checks can reject a request before it is sent. After usage is known, settlement adjusts the difference between the reservation and the calculated charge: it can deduct more or return the unused reservation. A failed, unsettled request can enter the pre-consumption reversal path. Streaming interruptions and asynchronous tasks need their own usage or task record checked; an HTTP error alone does not establish the settled charge. Reversal of a reservation is an accounting adjustment, not a promise of a payment refund. Consult the applicable order or service terms for payment refunds and renewals.

​
Reconcile a completed request

  1. Save the request time, model ID, API key label, selected group, and request or task ID when available. Keep the response usage and relevant parameters; redact API keys and private content before sharing.
  2. Find the matching completed entry in the dashboard usage or task logs. Confirm the model, group, billing mode, usage categories or billable quantity, and settled consumption.
  3. Use that entry’s rates and multipliers to reproduce the calculation. For dynamic billing, inspect its saved rule and matched tier. Where available, log details include billing_mode, matched_tier, group_ratio, and an account-specific user_group_ratio; fields vary by request type.
  4. Compare the result in the same currency and unit. Allow for quota conversion and rounding. Reconcile a top-up payment against its own order, rather than against a single request log.
If the figures still differ, provide the timestamp, request or task ID, redacted usage, and your calculation through the support channel shown in the dashboard. A current catalog price may differ from the rule recorded for an earlier request.

​
Next steps