余额与扣费
关于「扣费比预期多」「余额没变但请求失败」「充值没到账」「退款」的排查。
实付价 = 基准价 × 分组倍率
模型广场展示的是基准价，不含倍率。 同一个模型在 【Claude】Max · 惠享（×0.5）和 【Claude】Max · 顶享（×2）上， 模型名一模一样，实付价差 4 倍。
数据库里的价格到底有几个
三处价格，口径不同，混着看必然算错：
| 你在哪看的 | 是什么价 | 含倍率吗 |
|---|---|---|
| 模型广场 | 基准价 | 不含 |
| 模型价格表 | 实付价 | 含 |
| 公开价格接口 | 实付价 | 含 |
用广场数字算钱，必然算少
广场上的数字是「这个模型本身值多少钱」，你实际付的是它乘上分组倍率之后的结果。 要估算成本，看模型价格表，那里是乘好的。
现象一：扣费比预期多
原因
按可能性从高到低：
- 没算分组倍率 —— 拿着广场的基准价去算实付（最常见）
- 分组倍率本来就高 —— 比如选了
【Claude】Max · 顶享（×2） - 上下文长度跳档 —— 部分模型按上下文长度分档，超出阈值后单价上浮
- 缓存没命中 —— 缓存读便宜、缓存写贵，命中和不命中差很多
- 生图模型按次计费 —— 不是按 token，用 token 直觉估算必然错
解决
先确认你选的哪个分组 —— 控制台 → 令牌管理 → 看令牌的分组字段， 再去模型价格表看这个分组的实付价。
重新算一遍：
实付价 = 基准价 × 分组倍率倍数关系验证：同一个模型，
惠享(×0.5) 与顶享(×2) 的实付价相差 4 倍。 如果你算出来只差 2 倍，说明有一处没乘对。检查是不是跳档了 —— 长上下文任务会触发分档计价。 一次请求的上下文超过档位阈值，这一次整体按高档位算。 用单一单价乘 token 数会低估。
生图模型单独算 ——
gpt-image-2系列和gemini-3-pro-image-preview这类 是per_request（按次）计价，不按 token。详见生图模型。看控制台的用量记录与扣费明细 —— 这里有逐次请求的用量，是最权威的依据。 最终账务以控制台记录为准。
想省钱的调整顺序
- 先降分组档位（
顶享→稳享→惠享） - 再看缓存配置（把稳定不变的长提示词放前面，提高命中率）
- 避免无意义的长上下文
现象二：余额没变但请求失败
原因
这其实不是扣费问题，而是「请求没有产生计费」。 通常意味着请求根本没走到上游， 或者上游没有产生有效输出。
按平台的计费规则，这种情况通常不收取模型用量费用：
| 情形 | 是否计费 |
|---|---|
| 鉴权失败、余额不足、参数无效、平台主动拒绝 → 未转发到上游 | 不计费 |
| 已转发，但上游未产生有效输出并返回明确系统错误 | 核验后必要时退回异常扣费 |
| 已返回部分或全部结果 | 按实际产生用量计费 |
| 用户网络中断/主动取消，但上游已产生用量 | 可能计费 |
解决
先看报错原文 —— 余额没变说明没扣钱，你需要解决的是请求为什么失败。 去报错原文索引搜你的报错。
最常见的原因是分组不对 —— 令牌分组里没有这个模型， 请求在网关层就被拒了，压根没到上游。 见模型不存在。
如果上游已产生用量但你没收到结果（例如你中途 Ctrl+C、 或网络断了）—— 这部分可能正常计费，因为上游确实算了。 表现为「余额少了但你没拿到完整结果」。
确认不是看错了地方 —— 余额和用量是两个页面。 按量计费是在请求完成后结算的，可能有短暂延迟。
现象三：充值没到账
原因
- 支付回调有延迟 —— 你付了钱，但支付平台的回调还没到
- 支付成功但回调丢失 —— 需要人工核账
- 充到了别的账号 —— 多账号或用了别人的登录态
解决
先等几分钟再刷新 —— 支付回调不是实时的，别急着重复支付。
确认支付宝/微信里确实扣款成功，保存好订单号。
回到充值页确认到账金额。
实时应付金额与到账额度以充值页实际显示为准 —— 汇率会变，文档不写死数字。
超过合理时间仍未到账 → 带上下列信息走客服/群：
- 充值时间（含时区）
- 订单号
- 支付凭证截图
- 你的账号
不要重复充值
回调延迟时反复充值，可能造成多笔订单，退款流程会更麻烦。先等、再查、后补。
现象四：退款了，为什么额度不自动变
现象
你发起了退款（或申请了取消），但账户里的额度没有相应增减。
原因
支付适配是一个独立服务，与额度账务是分开的。
退款/争议不自动增减额度，需要人工核账。 也就是说：支付侧的钱怎么动，和账户里的额度怎么动，不是同一条流水线自动打通的。
解决
- 不要自己反复操作 —— 等人工核账结果。
- 走官方客服渠道申请，附上订单号与支付凭证。
- 具体的退款条件、手续费和时限，以《服务特定条款》和客服/群内公告为准。 文档不在此处复述具体政策，避免与最新规则不一致。
关于退款政策
退款涉及的条件、手续费比例、处理时限等，请以 服务特定条款的原文和官方客服的答复为准。 群里的口头说法不构成对条款的修改。
顺带：赠送额度和充值余额不是一回事
平台可能分账记录两类额度：
| 类型 | 来源 | 特点 |
|---|---|---|
| 充值余额 | 你实际支付并到账 | 可用于消费；退款规则按服务特定条款 |
| 赠送额度 | 注册奖励、邀请奖励、活动、兑换码等 | 不构成实际支付，通常不可提现、转让、开票或退款 |
两者可能有不同的使用顺序、适用模型、分组和期限。 具体以活动规则、购买页面和账务记录为准。
现象五：余额提醒
现象
收到余额不足的邮件或站内提醒。
说明
这是平台的低余额提醒功能，达到阈值时自动发出，提醒里的充值链接指向控制台充值页。
提醒阈值和提醒方式以控制台实际展示为准。 这是一条便利功能， 不要把它当成账务依据 —— 账务一律以控制台的余额和用量记录为准。
解决
- 需要充值 → https://fluxtoken.ai/purchase（支付宝 / 微信）
- 不想收提醒 → 控制台的相关设置里调整（如提供）
想程序化核对价格
要写脚本自动算成本，别抓网页，用公开价格接口：
curl -s https://status.fluxtoken.ai/pricing/provider-pricing.json- 返回的
input_price/output_price是已乘倍率的实付价 - 单位是 USD / 每 100 万 tokens
- 生图模型是
per_call形态，字段不同 - ⚠️ 该接口的
currency字段声明为CNY，但数值实际语义是美元，按美元处理 - 建议抓取间隔不低于 15 分钟
字段详解见公开价格接口。
还不行怎么办
- 服务状态页 https://status.fluxtoken.ai/ —— 确认不是上游波动导致的失败
- 控制台的错误请求记录 —— 平台允许你查看自己的错误请求，含失败原因
- 控制台的用量与扣费明细 —— 最终账务以此为准
- 进群 —— QQ 群
1108757955· Telegram https://t.me/fluxtokengroup
涉及账务争议时请附上：订单号、请求 ID、发生时间、模型名、分组名。
账务争议走官方渠道
《服务特定条款》里明确：用户应优先通过官方客服提交计费或退款争议。 群聊属于交流场所，正式争议请走客服。