定价、额度与订阅

请求能命中渠道，还需要用户有足够权益完成预扣与最终结算。管理员应在开放模型前核对价格，而不是把一次成功连接当成定价已经正确。

先区分三件事

对象	决定什么
模型定价	一次使用按什么规则计算费用
用户额度或订阅	用户可以使用多少权益
令牌额度	某个应用最多允许消耗多少

模型可以使用不同定价形式，包括 token、按次、任务用量与表达式。缓存、推理 token 和多模态 usage 的语义取决于协议与上游，不宜简单把所有数字相加。

新模型开放前

1. 确认上游成本和计价单位，并核对管理员已有覆盖配置。
2. 在模型定价管理中选择适用规则；不要直接照抄其他服务商的价格。
3. 检查请求模型别名、分组和实际定价对象是否对应。
4. 先用小规模真实请求检查日志中的用量、价格规则与最终扣费。
5. 对缓存、长上下文、图片或任务等实际使用场景分别验证。

本站不列固定的服务商价格，以免上线后随价格变动失效。输入价格时应以当前服务商资料和本实例的业务定价为准。

预扣与结算

网关可能在提交前预留额度，再根据有效 usage 完成结算或退款。预扣失败时，用户余额或令牌限额可能不足；最终消耗应以对应日志记录为准。

任务模型可能在后台继续处理。客户端超时或断开不等于上游任务停止，也不意味着一定立即退款。查清任务状态后再决定是否重试，避免重复付费提交。

订阅与余额

是否启用订阅、采用什么扣费优先级和权益周期，由实例配置决定。用户看到的套餐名称不能替代实际生效的权益和分组。出现权益异常时，记录请求时间、任务 ID、订阅状态和脱敏日志，由管理员核对。

表达式定价

表达式规则是计费逻辑，不是单纯展示文字。维护者需要阅读仓库 .agents/rules/billing.md 和 pkg/billingexpr/expr.md，确认单位、分段、缓存 token 归一化与结算安全边界。不要把此页当成可以直接上线的表达式配方。