Billing Formulas

This page documents formulas, not rates. The reason is direct: rates are operational data that shift as models come and go and suppliers reprice — anything written here could be stale tomorrow. Formulas are code, and changing them requires a release. What you need is to know how the number was produced, so you can check a bill yourself.

Everything settles in credits. The exchange rate is fixed: 1 CNY = 100 credits (code constant CREDITS_PER_YUAN = 100).

The common pipeline

Regardless of billing unit, every charge runs the same chain:

Resolve the billing unit

The model config declares which unit it bills on: token_split / per_call / per_ten_thousand_characters / duration_second / cost_matrix.

Compute supplier cost, or rate directly

With a cost matrix, parameter conditions are matched first to get a cost in CNY. Without one, the configured rate is applied directly.

Apply margin

sellPrice(CNY) = cost(CNY) × (1 + marginPercent / 100)

Convert to credits, rounding up

credits = max(1, ceil(sellPrice × 100))

Apply parameter coefficient

When a parameter (resolution, mode, etc.) carries a coefficient: finalCredits = ceil(baseCredits × coefficient)

Every step uses ceil, never rounding, and the minimum charge is 1 credit (max(1, ...)). A tiny call is therefore never free. Many small calls cost slightly more in aggregate than one call of the same total volume — rounding happens on each one, not at the end.

1. `token_split`: input and output priced separately

Used by conversational models. Input and output have separate rates in credits per million tokens.

inputCharge = ceil(inputTokens × inputRate / 1,000,000)
outputCharge = ceil(outputTokens × outputRate / 1,000,000)
baseCharge  = inputCharge + outputCharge
finalCharge = max(1, hasFactors ? ceil(baseCharge × coefficient) : baseCharge)

Note that ceil runs once on input and once on output before they are summed. So a single call costs at least 2 credits (1 each) even with a trivial token count.

Fallback when tokens are not itemized

Some suppliers return only a total token count. In that case a blended rate applies:

blendedRate = tokenRate > 0
                ? tokenRate
                : ceil((inputRate + outputRate) / 2)

baseCharge  = ceil(totalTokens × blendedRate / 1,000,000)

The blended rate is the arithmetic mean of input and output rates. Real conversations produce far fewer output tokens than input, so the fallback path is usually more expensive than the itemized path. If a model’s bills look higher than expected, first check whether it reports itemized tokens at all.

Supplier cost recording

When supplier costs are configured, they are recorded alongside (this does not affect your charge; it is for platform reconciliation):

supplierCost(CNY) = (inputTokens × costInputYuan + outputTokens × costOutputYuan) / 1,000,000

2. `duration_second`: priced per second

Used by video generation, sandbox runtime, and similar.

baseCharge  = ceil(seconds × durationRate)
finalCharge = max(1, hasFactors ? ceil(baseCharge × coefficient) : baseCharge)

Under a cost matrix:

cost(CNY)      = mode === "per_unit" ? unitCostYuan × seconds : unitCostYuan   // flat = fixed
sellPrice(CNY) = cost × (1 + margin / 100)
credits        = max(1, ceil(sellPrice × 100))

flat exists because some suppliers charge per generation rather than per second — same duration unit, but selecting flat in the rule collapses it to a fixed price.

3. `per_call`: priced per call

Used by image generation and other one-call-one-result capabilities.

baseCharge  = ceil(callCount × perCallRate)
finalCharge = max(1, hasFactors ? ceil(baseCharge × coefficient) : baseCharge)

Batch generation (generate_batch) counts actual images with no volume discount.

4. `per_ten_thousand_characters`: priced per 10K characters

Used by TTS, translation, and other text-volume capabilities. It shares an implementation with per_call and adds only a divisor:

billableQuantity = characterCount / 10,000
baseCharge       = ceil(billableQuantity × rate)
finalCharge      = max(1, hasFactors ? ceil(baseCharge × coefficient) : baseCharge)

Cost-rule matching uses the raw character count (callCount); the division by 10,000 applies only when computing the amount. So a tiered rule like “over 50,000 characters switches rate” must be written against raw characters, not per-10K units.

5. `cost_matrix`: parameter conditions → cost

Not a fifth billing unit but a pricing strategy layered on top of the other four. It lets one model price differently by parameter (1024x1024 versus 4K, for example). Rule structure:

{
  "rules": [
    {
      "conditions": [
        { "key": "resolution", "values": ["4k", "2160p"] }
      ],
      "unitCostYuan": 0.5,
      "mode": "per_unit"
    },
    {
      "conditions": [],
      "unitCostYuan": 0.1,
      "mode": "per_unit"
    }
  ]
}

Matching rules:

Rules are evaluated in order; the first rule whose conditions all match wins
Multiple conditions on one rule are AND-combined
A rule with an empty conditions array matches everything and serves as the fallback
Conditions come in three shapes: enum (values, any-of), range (min / max, with minExclusive / maxExclusive choosing open or closed), and exact match (equals)

The fallback rule must be last. Placed earlier it matches first and every refined rule below becomes unreachable — with no error, just everyone billed at the fallback price.

Token units and per_call / duration units use different cost fields in a rule:

Unit	Cost fields
token	`inputCostYuan` + `outputCostYuan` (CNY per million tokens)
per_call / duration	`unitCostYuan` + `mode` (`per_unit` scaled / `flat` fixed)

Sell price is never stored: only cost plus margin, computed at billing time. Adjusting margin means changing one number, with no historical backfill.

Credit deduction order (six buckets)

Your balance is not one number but six buckets, consumed in strict order:

1. Daily check-in

Expires at midnight (UTC+8) the next day. Spent first because it lapses soonest.

2. Signup grant

Valid 90 days.

3. Plan grant

Valid for one subscription cycle.

4. Referral reward

Reclaimed after 100 days of inactivity.

5. Top-up bonus

Permanent.

6. Top-up principal

Permanent, and touched last.

In one sentence: spend what expires soonest first, and what you actually paid for last. Within a bucket, lots are consumed by expiry order.

Expiry reclamation targets a specific lot rather than following the priority order — the reclamation record carries the source transaction ID and deducts exactly that lot’s remainder. Only when no matching lot is found does it fall back to priority order. This guarantees that “signup credits expired” never eats into your paid balance.

Unknown or legacy grant types are filed into the top-up principal bucket (permanent, lowest priority) — the conservative choice, preferring to deduct late over silently swallowing user balance. Creator earnings follow two independent paths.

Buyout (unlocking an expert)

creatorEarnings(diamonds) = unlockPrice × buyoutSharePpm / 1,000,000

Shares by creator level (ppm, parts per million):

Level	Threshold (cumulative diamonds)	`buyoutSharePpm`	Effective
`rising`	0	750,000	75%
`growing`	300,000	850,000	85%
`professional`	1,000,000	900,000	90%
`master`	5,000,000	950,000	95%

profit                    = userCreditsSpent − model and tool cost
creatorEarnings(diamonds) = profit × consumptionSharePpm / 1,000,000

Level	`consumptionSharePpm`	Effective
`rising`	100,000	10%
`growing`	150,000	15%
`professional`	200,000	20%
`master`	200,000	20%

Two points are routinely misread:

Usage share is computed from profit, not gross spend. If a user spends 1,000 credits of which 700 is model cost, a professional creator earns 300 × 20% = 60 diamonds, not 1,000 × 20% = 200.
Self-purchases do not earn. Buying your own expert from your own account produces no share, which blocks wash trading.

The usage share stops rising after professional (20%) — reaching master only raises the buyout share.

Withdrawal conversion

withdrawableAmount(CNY) = unfrozenDiamonds / exchangeRate      // default exchangeRate = 100

That is 100 diamonds = 1 CNY. Freeze periods and thresholds are in Limits.

Withdrawal is currently hard-disabled in code; every request returns WITHDRAWAL_NOT_OPEN. The formula above applies once it opens.

Checking a bill yourself

Get the unit and rate for the call

The consumption record carries pricingUnit and a rate snapshot.

Compute by hand using this page

Remember every step uses ceil with a 1-credit floor.

If it doesn't match, check three things

Whether a parameter coefficient applied (factorCoefficient other than 1)
Whether the cost matrix was used instead of a flat rate
Whether a token-unit call fell back to the blended rate because the supplier returned no itemization

Those three account for nearly every “the math doesn’t add up,” and all three are visible as fields on the consumption record.

Limits

Quotas, validity, rate limits

Credits and consumption

Earning and checking credits

Revenue system

Creator earnings in full

Pricing and billing

Pricing your own expert

Verified 2026-08-11. Sources: services/core/src/db/service/credit-consume.ts (billing pipeline and six-bucket priority), services/core/src/constants/cost-matrix.ts (cost rules), services/core/src/db/service/platform-config.ts (revenue shares and withdrawal rules). Rate and cost values are ops data and are deliberately omitted.

Get Started

Core Concepts

Guides

Platform & Account

Deep Dive

Billing Formulas

Billing Formulas

The common pipeline

1. `token_split`: input and output priced separately

Fallback when tokens are not itemized

Supplier cost recording

2. `duration_second`: priced per second

3. `per_call`: priced per call

4. `per_ten_thousand_characters`: priced per 10K characters

5. `cost_matrix`: parameter conditions → cost

Credit deduction order (six buckets)

Buyout (unlocking an expert)

Withdrawal conversion

Checking a bill yourself

Limits

Credits and consumption

Revenue system

Pricing and billing

​Billing Formulas

​The common pipeline

​1. token_split: input and output priced separately

​Fallback when tokens are not itemized

​Supplier cost recording

​2. duration_second: priced per second

​3. per_call: priced per call

​4. per_ten_thousand_characters: priced per 10K characters

​5. cost_matrix: parameter conditions → cost

​Credit deduction order (six buckets)

​Expert revenue share

​Buyout (unlocking an expert)

​Usage share (consumption)

​Withdrawal conversion

​Checking a bill yourself

​Related pages

Limits

Credits and consumption

Revenue system

Pricing and billing

Billing Formulas

The common pipeline

1. `token_split`: input and output priced separately

Fallback when tokens are not itemized

Supplier cost recording

2. `duration_second`: priced per second

3. `per_call`: priced per call

4. `per_ten_thousand_characters`: priced per 10K characters

5. `cost_matrix`: parameter conditions → cost

Credit deduction order (six buckets)

Expert revenue share

Buyout (unlocking an expert)

Usage share (consumption)

Withdrawal conversion

Checking a bill yourself

Related pages