路由策略与成本护栏
账号级与 API Key 级共用同一份策略结构。设置入口在 控制台 · 路由偏好 与 令牌管理。
立场
路由预设
预设决定打分权重，不决定过滤。四档：
| 预设 | 语义 |
|---|---|
cheapest | 低价优先：价格明显低的权重更高，接近时看成功率与延迟 |
fastest | 高速优先：首响应更快的节点优先，价格仍参与筛选 |
stable | 稳定优先：最近成功率更高、失败更少的节点优先 |
balanced | 高质综合：成功率、响应速度与价格综合（默认） |
存活候选内部走价格加权随机而不是取最优。取最优会让最便宜的渠道被打爆 → 限流 → 所有人一起 failover（羊群效应）；从商户视角看，确定性排序意味着第 2 名永远拿不到流量，市场会死。
关闭智能优选后不做加权随机，严格按你写的批次 / 白名单顺序依次尝试 —— 你明确知道自己要什么时，我们不该二次猜测。
成本护栏
1. 单次请求花费上限（硬）
字段 maxSpendPerRequest，按美元设定单次请求的花费上限。三道里最直观的一道 —— 但它只能在请求前按估算拦截，精确到每 token 的硬顶要靠下面的单价上限。
它和单价上限管的不是同一件事：单价上限约束 $/1M token，这一道约束一次调用的总花费。$0.05/1M 听起来很便宜，但一个 200K context + 长输出的请求照样能花掉一大笔； Claude Code 这类 Agent 客户端动辄几十万 token 的上下文，差距是数量级的。
- 请求前：按
max_tokens× 渠道出价估算上界，超了直接拒绝， 请求不会发出 - 结算时：实际花费超了会告警并记账（估算总有偏差）
2. 绝对单价上限（硬）
字段 absoluteMaxOutPer1M，美元 / 1M output tokens。
与百分位池的本质区别：百分位是相对的，市场整体涨价时它跟着涨； 绝对上限是硬的、钉死不动。超过它的渠道直接淘汰，过滤后候选为空则该请求失败， 不受百分位保底、也不受强制兜底影响。
3. 价格刺客护栏（硬）
字段 maxPriceMultipleOfCheapest：候选价格不得超过「当前同模型最便宜可用渠道」的 N 倍。
绝对上限只能保护知道行情的用户。真正的价格刺客长这样： 便宜渠道集体挂掉 → failover 一路往下走 → 静默落到一个贵 50 倍的渠道上 → 逐笔淹没在正常请求里、当场难以察觉。这在商户市场里不是假设，是必然会发生的。
相对护栏挡得住这种情况，且不需要你了解任何价格。建议 3~5 倍作为起点。
百分位低价池
| 策略 | 语义 |
|---|---|
auto | 前 70%，至少保留 2 个候选。默认推荐 |
strict | 前 30%，至少 2 个。更省钱，候选更少 |
custom | 前 N%（10~100），至少 M 个。M = 0 表示明确不保底，前 N% 为空就失败 |
none | 不做百分比过滤 |
有序商家批次
字段 merchantBatches。与「加入路由」白名单的区别是有序： 白名单是一个集合，池内按打分排序；批次是有序的多个集合，批次 1 全部失败后才进批次 2。
典型用法：批次 1 放自己长期验证过的商家，批次 2 放便宜但没那么熟的。 这比单一白名单表达力强得多，也比「固定商家」精确 —— 固定只是加权，批次是硬顺序。
软约束与硬约束
区分必须做对：把软约束做成硬的，你会频繁遇到「无可用渠道」；反过来则会拿到不想要的渠道还不知情。
| 类型 | 语义 | 包含 |
|---|---|---|
| 硬约束 | 满足不了就拒绝执行并报错 | 三道成本上限、只用认证商户、只用原生协议渠道、只用 / 排除指定渠道 |
| 软约束 | 满足不了就降权，仍可能被选中 | 固定商户、偏好低延迟、偏好高成功率 |
每次请求都会回传路由元数据，说明哪些约束生效、哪些渠道被降权、尝试过谁 —— 见 协议端点 · 路由元数据。
两级合并规则
默认 ← 账号级 ← Key 级，但不是简单覆盖：
- 收紧型字段取更严的一方：三道成本上限取更小值，
requireVerifiedMerchant取或，排除名单取并集，白名单取交集 - 放宽型字段（预设、排序偏好、批次）由 Key 直接覆盖
理由：账号级设成「只用认证商户」通常出于合规或成本的硬要求，某个 Key 忘了设就把它放开， 是最容易出事又最难发现的一类配置错误。