常见问题

账户与计费

账户与计费

怎么计费

一个账户一份美元余额，随工作完成而扣减。没有订阅、没有月度承诺 —— 先充值，后消耗。

  • 文本按 token 计量，输入、缓存输入、输出分别定价。
  • 任务（图片、视频、特效、工作流）在提交时预扣、完成时结算。

在哪看花了多少

两个地方，数据同源：

  • 控制台，可看调用次数、token、费用与按密钥的明细。
  • GET /v1/usage，同样的数据可编程获取 —— 包含 by_model、by_capability、by_api_key。

任务失败了怎么算

预扣会退回。 GET /v1/tasks/{task_id} 会在任务上体现退款，GET /v1/usage 会把 credits_refunded 与 credits_settled 分开列出。

这一点对你自己的账务很重要：如果你的账本只记预扣、从不读退款，数字迟早和账单对不上。 两边都要对。

余额为什么会是负数

credit_balance 可以低于零。长任务在完成时才结算，所以已经受理的工作会跑完并计费，即使中途余额已经归零。充值后余额会回到正数。

余额归零会怎样

账户上所有付费操作开始返回 402 insufficient_credits —— 这是账户级的，不是按密钥算的。已受理的任务会继续跑完。不会删除任何数据，也不会吊销任何密钥；充值后立即恢复。

如果你有面向用户的服务，请对 402 配告警，别等用户来告诉你。

请求频率额度是怎么定的

按累计已付充值额，而不是按套餐。 充值会让账户永久升到更高档位 —— 档位只升不降，因为它依据的那个数字只增不减。

当前额度与下一档位在控制台可见，也在 GET /api/user/self 的 rate_limit 里：

1"rate_limit": {
2  "enabled": true,
3  "window_minutes": 1,
4  "success_count": 20,
5  "next_tier": { "min_topup_quota": 50000000, "success_count": 30 }
6}

有两点是刻意不体现的：赠送额度与邀请奖励不计入档位；这里显示的数字也不包含单把密钥自身可能设置的更严限制。

额度会过期吗

不会。余额一直保留到用完为止。

同样的提示词为什么价格不一样

四个原因，按最常让人意外的顺序：

  1. 输出长度会变。 输出是文本调用里贵的那一半，而不设上限时长度由模型决定。
  2. 缓存输入比新鲜输入便宜。 重复一段长系统提示词可能命中缓存，只花首次调用的一小部分。
  3. 有些模型按时段计价。 DeepSeek 系列在北京时间工作日高峰时段翻倍；混元 hy3 有自己的每日窗口。具体时段见价目页脚注。
  4. 有些模型按上下文长度计价。 GPT-5.6 与 Grok 系列在超过阈值后按更高档位计费。长会话会在无声无息中越线。

每次响应的用量记录都会显示实际适用的档位。

能按应用分别看成本吗

给每个应用发一把独立密钥。 GET /v1/usage 的 by_api_key 就会按密钥归集任务数与额度消耗，不需要你做任何额外工作。

怎么充值

在控制台充值。支付确认后余额立即更新，之后不需要再启用什么。

对某笔扣费有疑问

在控制台提交工单，附上该次调用的 request_id 或任务编号，两者都能定位到唯一一条记录。