Claude 中转的六项能力
协议接入
接口沿用 Anthropic Messages 形态，支持普通和流式调用。x-api-key 与 Authorization: Bearer 都可用于鉴权，两者同时出现且不一致时返回 400，不会随机挑选。请求字段按清单校验，不支持的字段在发往上游前返回明确的 400，不会被默默丢弃。
权限与配额
每个 Key 绑定项目，可单独设置模型范围、预算、速率、有效期和 IP 白名单。Key 上设置的并发、RPM、TPM 与账户总上限同时生效，超限返回 429 和 Retry-After。子 Key 限额只收紧边界，拆分 Key 不增加账户总容量，也不创造余额。
同版本路由
请求按你指定的具体模型版本路由，只在该版本的合格等价通道之间选择。只有确认上游没有接受生成时才换通道重试，每个请求最多增加一次尝试；已发送且状态不明时不自动重复生成。没有合格通道时明确返回 503，不会换成其他模型。
流式响应
SSE 事件逐个转发，不拼装、不改写正文。响应头发出后上游若中断，发送带 request_id 的 error 事件并结束，不伪造 message_stop，也不拼接另一次生成。客户端取消会传递给上游，已产生的用量不因取消自动免计。
用量计费
准入后按输入估算和 max_tokens 冻结费用上限，结束时按实际用量结算并释放差额。输入、输出、缓存读取和缓存写入按各自单价分项计算，缓存不会再按普通输入重复计费。每个请求只结算一次，平台发起的重试不重复向你收费。带 cache_control 的请求会在 system 最前面多一段按账户固定的短文本（约 8 到 15 个输入 Token，照常计费），用来隔离各账户的提示词缓存，见计费规则。
请求追踪
每个请求生成 request_id，随 request-id 响应头和错误信息返回。控制台可按编号查看传输状态、账务状态、用量分项和资金来源。默认只记录脱敏元数据，不记录提示词和生成正文。
四个处理场景
以下均为示例，用来说明处理规则，不对应任何真实请求。¥X、¥Y 表示实际响应里的具体金额。
- 步骤 1accepted 鉴权、模型权限和字段校验通过，取得速率与并发准入。
- 步骤 2reserved 按输入估算和 max_tokens 算出费用上限并冻结。
- 步骤 3dispatched 固定价格和路由版本，选定合格通道并发送。
- 步骤 4streaming HTTP 200 发出，SSE 事件逐个转发，正文不改写。
- 步骤 5completed 收到 message_stop，取得完整用量。
- 步骤 6settled 按实际用量分项结算，释放冻结差额。
- 步骤 1accepted、reserved 与正常流程相同：准入通过，费用上限已冻结。
- 步骤 2dispatched 选定通道，开始第一次尝试。
- 步骤 3连接失败 DNS、TLS 或建立连接失败，确认请求还没有发出。
- 步骤 4自动切换 最多换一次其他合格的等价通道。切换成功就按正常流程继续，只结算一次。
- 步骤 5failed 没有可换的合格通道时，返回 503 overloaded_error 和 request-id。
- 步骤 6released 释放全部冻结，本次不收费。
- 步骤 1accepted、reserved 与正常流程相同：准入通过，费用上限已冻结。
- 步骤 2dispatched、streaming HTTP 200 已发出，内容正在返回。
- 步骤 3上游中断 上游在 message_stop 之前中断或报错，此时状态码已无法更改。
- 步骤 4failed 发送带 request_id 的 error 事件后结束，不伪造 message_stop，不拼接另一次生成。
- 步骤 5有可靠用量 直接按实际用量结算，进入 settled。
- 步骤 6没有可靠用量 进入 usage_pending，冻结保留，等待核对用量。
- 1 小时告警 待核算 1 小时未解决，触发告警。
- 24 小时关闭 仍无可靠用量证据时，只按已被上游证实的字段计费，未证实部分释放；一个字段都未证实则全额释放。
- 步骤 1校验与准入 鉴权、模型权限、字段校验和速率准入通过。
- 步骤 2费用上限 按输入估算和 max_tokens 算出本次请求的费用上限。
- 步骤 3额度不足 当前可用额度覆盖不了费用上限，冻结不成立。
- 步骤 4HTTP 402 返回 402 billing_error，请求没有发往上游。
- 步骤 5未扣费 没有冻结，不扣任何金额，也不会先扣一部分再失败。