计费说明

这一节只讲按 token 计费的模型。图像、视频等按次、按量或按秒计费的模型不适用这套算法，各自的计价方式直接看对应的模型广场：

• api 站的模型看模型广场
• Seedance 与 Seedream 系列看ark 站模型广场

单价是模型本身未含分组倍率的基准价。分组倍率是账号所在分组带来的系数。单价乘上分组倍率，才是你实际付的价格。

先把各项用量乘单价得到「费用」：

费用 = 输入 token      × 输入单价
     + 输出 token      × 输出单价
     + 缓存写入 token  × 缓存写入单价
     + 缓存读取 token  × 缓存读取单价

再把费用乘上分组倍率，得到实际扣费：

实际扣费 = 费用 × 分组倍率

单价是怎么定的

单价以模型的官方价格为基准，部分模型另有规则：

• 分级定价：按用量分档，用得多单价越低，具体分档见 billing_expr
• 长上下文定价：输入超过一定长度后按更高单价计，超长文档、整本书这类场景会触及
• 缓存写入与读取分开计价：写入缓存按 create_cache_ratio，命中缓存读取按 cache_ratio，两个系数不同

分组同样影响最终价格：同一个模型，不同账号看到的价格可能不同——差的不是单价，是分组倍率。你的分组系数在模型广场和 GET /api/pricing 的 group_ratio 里都能查到；不同分组的倍率不一样，可以在控制台里选适合自己的分组。

This section covers per-token models only. Per-call, per-quantity, or per-second models like image and video don't follow this math; see each model's catalog entry for its pricing:

• For api-site models, see the model catalog
• For the Seedance and Seedream series, see the ark-site model catalog

A unit price is the model's base price before the group ratio. A group ratio is the multiplier that comes with your account's group. Unit price times group ratio is what you actually pay.

First multiply each usage figure by its unit price to get the cost:

cost = input tokens          × input price
     + output tokens         × output price
     + cache write tokens    × cache write price
     + cache read tokens     × cache read price

Then multiply the cost by your group ratio to get the actual charge:

actual charge = cost × group ratio

How unit prices are set

Unit prices follow the model's official list price, with some models adding rules:

• Tiered pricing: the price drops as volume rises; see billing_expr for the tiers
• Long-context pricing: input past a certain length is billed at a higher price, which very long documents and whole books will hit
• Separate cache write and read pricing: writes are billed at create_cache_ratio and cache hits at cache_ratio; the two coefficients differ

Your group affects the final price too: the same model may show different prices to different accounts — what differs isn't the unit price, it's the group ratio. You can find your group coefficient in the model catalog and in group_ratio from GET /api/pricing. Ratios differ by group, and you can pick a group that suits you in the console.

不同模态的计价单位不同：

具体到某个模型用哪一种，看模型广场上标注的计费方式，或 GET /api/pricing 里的 quota_type 与 model_price、model_ratio 字段，字段含义见模型价格与分组接口。

Pricing units differ by modality:

To see which applies to a given model, check the billing method marked in the model catalog, or the quota_type, model_price, and model_ratio fields from GET /api/pricing; the fields are described in Model pricing and groups.

文本类模型大多支持上下文缓存。缓存分两步，各有一套价格：

• 写入缓存：按 create_cache_ratio 计费，通常比正常输入价略高
• 命中缓存读取：按 cache_ratio 计费，通常明显低于正常输入价

长对话、固定系统提示词这类反复出现的输入，写入一次后后续都按读取价算，省得最多。

两个系数在模型广场上标注了，也可以从 /api/pricing 里查。用法见OpenAI 上下文缓存。

Most text models support context caching. Caching has two steps, each with its own price:

• Cache writes: billed at create_cache_ratio, usually a little above the normal input price
• Cache-read hits: billed at cache_ratio, usually well below the normal input price

For inputs that recur — long conversations, a fixed system prompt — you write once and later requests are billed at the read price, which saves the most.

Both coefficients are marked in the model catalog and available from /api/pricing. For usage, see OpenAI context caching.

1. 调用前校验：请求到达时先检查剩余额度。余额为 0 或已用完，产生费用的接口会被直接拒绝
2. 调用结束结算：按实际用量扣费。流式请求在流结束时结算
3. 查询类接口不受影响：查用量、查余额、列模型这类不产生费用的接口，余额为 0 时也能正常调用

被拒绝时返回的错误码与处理方式，见错误码说明。看到余额不足的提示，去控制台钱包页面充值后重试即可。

1. Check before the call: remaining balance is checked when a request arrives. With a zero or exhausted balance, endpoints that incur charges are rejected outright
2. Settle after the call: you're charged by actual usage. Streaming requests settle when the stream ends
3. Query endpoints are unaffected: usage, balance, and model-list endpoints incur no charges and work fine with a zero balance

For the error codes returned on rejection and how to handle them, see Error codes. If you see an insufficient-balance message, top up on the console's wallet page and retry.

• 用量：每条请求的模型、token、费用、耗时与状态
• 仪表盘：当日与累计消耗
• 订单：充值与购买记录

也可以用接口查：

• Usage: model, tokens, cost, duration, and status for each request
• Dashboard: today's and cumulative spend
• Orders: top-up and purchase records

You can also query through the API:

在控制台钱包页面点「添加资金」，可以选择固定金额、自定义金额，或者用兑换码冲抵。

付款方式支持微信支付、支付宝、Stripe，以及加密货币 BEP20、TRC20 两条链。到账后余额即时更新，页面顶部能看到订单历史。

On the console wallet page, click "Add funds" and choose a preset amount, a custom amount, or redeem a code.

Payment methods include WeChat Pay, Alipay, Stripe, and two crypto chains, BEP20 and TRC20. Balance updates as soon as payment lands, and the order history is at the top of the page.

两边的算法相通，都是单价乘分组倍率（按 token 计费的还要乘 token 量），但单价、分组、余额都是分开的。ark 站的模型普遍采用阶梯计价，实际单价以各自模型广场为准，同一个模型名在两边也不共享额度。

The math is the same on both sides — unit price times group ratio (and for per-token models, times token count) — but prices, groups, and balances are separate. Ark-site models generally use tiered pricing, so go by each catalog for actual prices, and the same model name doesn't share a balance across the two sites.