一个端点，
所有模型。
Tare 是挡在你所有模型前面的一层 OpenAI 兼容网关 —— 我们的，和你自己带来的。一个 base URL、一把 key，每一个 token 都算得清。
计费规则
是否收费只取决于这次 token 由谁支付。
| 走的路由 | token 费 | 路由费 |
|---|---|---|
| 平台模型 | 按你的价目表 | — |
| 你自己的渠道 | 不收，供应商已经直接向你收过 | 合同约定时才收 |
[!NOTE] 因此余额为零不会阻断自有渠道上的调用：这部分 token 并不欠平台，阻断它也与「仅更换 base URL 即可接入」的设计前提相冲突。
路由费（如果有）
按每百万 token（input + output）从一张公开价目表计收，不是按供应商收费比例抽成。 Routing 页会展示价目表；不收取时明确标注。
余额与额度上限
- 账户余额仅作用于平台模型。
- key 上的额度上限独立于余额，限制单把 key 的消费额。失控的任务停在上限，不会耗尽账户。
- 用尽时返回专门的错误码（见错误码），不是笼统的失败。
中断的调 用仍然计费
流式中断时上游的 token 已经消耗。Tare 会事后向上游回查并补记，而不是丢弃；否则账单金额会 低于供应商的实际账单。
故障转移遍历全部已配置路由
一个模型可配置任意多条路由，一次调用会按顺序全部尝试，直到其中一条成功为止。 平台不设上限：配置了四条备用即最多尝试四次。是否为多一条备用承担额外等待时间， 由账号所有者自行权衡。
有两种结果不计为一次尝试，在调用详情中单独列出：
- parked —— 那条渠道当时被熔断关着，一个字节都没发出去；
- never tried —— 未被轮到的候选（仅在账号配置了尝试次数上限时出现；默认不设上限）。
⚠️ 每一次真实尝试都计入路由费保底。 一次转移意味着平台发出了两次上游请求 —— 建立了两次连接、等待了两次超时 —— 因此保底按两次计算。被熔断挡下的不计入： 一个字节都未发出，且属于平台侧的问题。
故障转移与计费行数
一次调用不会出现两条计费行。转移只发生在首字节返回之前，即这次尝试尚未产生任何 token 消耗时；内容开始返回后不再转移。因此：
- 失败尝试的 prompt token 不计入你的账单；
- 一次业务调用在账单上只有一行收费。
⚠️ 风险落在平台一侧：非流式请求因超时转移、而上游实际已完成时，平台可能被上游计费两 次。这部分成本由平台承担，不转嫁给客户。
另有一类行不是收费行：中途断开的流式调用 usage 永远不会到达（它在末帧里），平台事后
向上游回查真实成本并补记一行，该行 cost = 0，只含上游成本，属于平台侧的亏损记录，
不向客户收费。它同样带 gen- 编号，可按编号关联。