OpenRouter BYOK 费用、故障切换与密钥轮换（2026）

明明配置的是自己的 OpenAI 密钥，请求也成功了，为什么 OpenRouter 余额还是少了？因为 OpenRouter BYOK 并不是一个简单的计费开关：提供商费用、平台费用和故障切换容量走的是不同路径。而且，现行规则已经不再按“每月一百万次请求”计算。

先弄清楚：这笔钱到底扣在了哪里

OpenRouter BYOK 允许请求使用保存在工作区中的提供商凭据，同时仍由 OpenRouter 提供 API 和路由层。因此，费用会分为三条独立的路径：

排查时，第一个问题不该是“我是不是已经添加了密钥？”，而应是“这次请求究竟由哪家提供商处理？”即使密钥已配置，也可能因为速率限制、上游账户余额不足、权限不足或提供商临时故障而失败。若开启了故障切换，OpenRouter 可以通过其他提供商完成请求，并从你的 OpenRouter 余额中扣除该路由的费用，正如其关于 BYOK 收费的支持说明所述。

BYOK 改变了什么，又没有改变什么

BYOK 会让符合条件的流量通过你的提供商凭据处理，但 API 和路由层仍由 OpenRouter 保留。根据其BYOK 文档，这些凭据会被加密，仅用于路由至指定提供商的请求。

BYOK 并不意味着推理免费：模型用量仍会记入提供商账户，超过适用额度后，OpenRouter 还可能收取单独的平台费用。自带密钥也不会绕过工作区、账户或请求级别的隐私规则；如果没有任何符合条件的端点可用，即便凭据本身有效，请求也会失败。

现行 BYOK 费用按推理金额计算，不按请求次数计算

当前OpenRouter 定价页面列出的 BYOK 免平台费额度，依据的是推理的标价价值，而非请求数量：

这项额度按照同一模型和提供商在 OpenRouter 上的常规价格计算，不一定等同于你与提供商协商后的实际账单。超出额度后，5% 的 BYOK 费用会从 OpenRouter credits 中扣除；提供商的费用仍单独结算。

三类费用，务必分开记账

1. 提供商推理费用：由 BYOK 凭据对应的提供商账户支付。
2. BYOK 平台费用：超过当前套餐额度后，OpenRouter 按 5% 收费，并从 OpenRouter credits 中扣除。
3. 故障切换推理费用：当路由没有走预期的 BYOK 路径，而是使用了由 OpenRouter 付费的提供商容量时，费用由 OpenRouter credits 支付。

购买 credits 的费用则是另一回事：OpenRouter 定价页面列出按量付费的平台费用为 5.5%。一次充值扣费并不能证明某个具体请求发生了故障切换。

为什么搜索结果里仍常见“100 万次请求”的说法

OpenRouter 在 2025 年 10 月的公告中曾说明，每月前一百万次 BYOK 请求免平台费，之后收取 5%。这是该历史公告中的旧政策；页面目前已注明，BYOK 定价在 2026 年 8 月发生了变化。做成本预估时，应以当前定价页的按标价推理额度为准，并记录查询日期。

是否允许故障切换，决定了 BYOK 是不是硬边界

OpenRouter 的默认路由目标是让请求成功完成。其BYOK 指南说明了优先密钥、共享 OpenRouter 端点和后备密钥在路由中的不同位置：

• 优先级 BYOK 密钥会按配置顺序依次尝试。
• 这些尝试失败后，可以尝试 OpenRouter 的共享容量。
• 标记为后备的 BYOK 密钥会在共享端点之后尝试。
• 同一提供商下存在多把匹配密钥时，也会按顺序逐一尝试。

提供商排序还会带来一个容易忽略的细节：匹配的 BYOK 端点会先于共享端点被尝试，即便该提供商在你请求的 order 数组中位置靠后也是如此。因此，一次请求实际使用 BYOK 密钥的时机，可能早于你的通用提供商排序规则所暗示的顺序。

可靠性与计费确定性，只能优先其一

控制台中的 始终用于此提供商 选项，会阻止 OpenRouter 对该同一提供商使用自己的共享凭据。但它不是全局性的“绝不使用 OpenRouter credits”开关。OpenRouter 的支持文章指出，如果跨提供商故障切换仍然可用，请求依然可能从 Anthropic BYOK 密钥转向 Google Vertex 等其他兼容提供商。

如果你需要确定的计费归属，应在请求本身限制路由：

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

使用 provider.only 后，Anthropic 出现故障会直接变成 API 请求失败，而不会静默路由到其他提供商。这适合受监管的工作负载、带有提供商专属数据协议的场景，或每一笔请求都必须映射到单一上游账户的成本报表。对于更重视可用性而非严格提供商归属的交互式产品，这通常不是理想的默认设置。

r/openrouter 中的一位真实用户也提到了同样的控制方式：

“你可以直接在请求中指定 order/only providers，强制它只使用你的 BYOK。” —— u/Randomdotmath，Reddit 讨论帖

如果故障切换是你可靠性设计的一部分，就应为它预留预算；如果不是，就应在请求边界将其关闭。

先到 Activity 确认路由，再判断费用问题

OpenRouter 的FAQ说明，Activity 可以显示用量历史，并支持按模型、提供商和 API 密钥筛选。重点检查：

1. 实际服务提供商：是否与 BYOK 凭据绑定的提供商一致？
2. 模型和端点：路由器是否选择了其他兼容端点？
3. 应用 API 密钥：是哪一个环境或工作区密钥发起了请求？
4. credits 扣款：这笔金额是推理消费、BYOK 费用，还是与充值相关的余额变化？

如果 Activity 中的提供商与 BYOK 提供商不一致，应先排查故障切换，而不是急着更换凭据。如果提供商一致，且用量已接近套餐额度，则应排查 BYOK 平台费用。这样可以避免为了修复路由策略问题而错误轮换一把本来有效的密钥。

适合生产环境、可平滑轮换的密钥架构

应将 OpenRouter 应用密钥和上游 BYOK 凭据视为两种不同的机密，它们的归属与管理者也不同：

配置并验证一组 BYOK 凭据

在排查生产流量之前，先完成以下简短流程：

1. 在工作区的 BYOK 设置中添加提供商凭据，或通过BYOK 管理 API创建凭据。
2. 为其命名时明确标识提供商、环境和用途。
3. 在共享工作区凭据前，先配置模型、OpenRouter API 密钥或成员筛选条件。
4. 将密钥放入优先级区域；只有在其计费与故障处理职责明确时，才添加后备密钥。
5. 发送测试请求，在 Activity 中确认实际服务提供商，再决定是否保留共享容量故障切换。

云提供商的凭据并不能互换使用：

这些限制来自 OpenRouter 的提供商专属 BYOK 文档。密钥本身有效，但资源类型、区域、部署配置或权限错误，属于配置失败，并不说明 BYOK 不受支持。

OpenRouter 的 BYOK 设置支持按模型 slug、OpenRouter API 密钥哈希和工作区成员筛选。凭据要符合资格，所有启用的筛选条件都必须匹配；文档规定每种筛选条件最多可添加 100 项。建议使用明确的允许列表；大型团队应拆分到不同工作区，而不是维护一份覆盖范围不断扩大的凭据。

只轮换 OpenRouter 应用密钥，不动提供商密钥

OpenRouter 的API 密钥轮换 cookbook说明，BYOK 提供商凭据关联的是 OpenRouter 账户，而非某一把特定的应用密钥。其零停机轮换顺序如下：

1. 创建一把替代用的 OpenRouter 应用密钥，设置清晰的名称和合适的额度。
2. 将其保存到机密管理器，并部署到所有使用旧密钥的服务、任务和环境。
3. 在 Activity 中确认生产流量已使用替代密钥。
4. 只有在迁移完成后，才删除旧密钥。

Management API 文档指出，Management API 密钥属于管理凭据，无法调用 completion 端点。撤销旧应用密钥之前，必须确保替代密钥已经可用。

提供商凭据要单独轮换

轮换提供商密钥是另一项变更。应遵循提供商自身的凭据策略，并测试该工作负载实际使用的模型、区域、权限和配额。

1. 在上游创建替代凭据，并只授予所需的最小权限。
2. 以不同名称和受控优先级，将其添加到 OpenRouter BYOK 连接中。
3. 发送测试请求并检查 Activity。
4. 将替代凭据调整到主用位置，监控错误和提供商用量。
5. 在重叠窗口结束后，于上游撤销旧凭据。

这个流程是基于 OpenRouter 已文档化的优先级行为给出的运维建议；提供商自身的撤销规则仍具有最终效力。OpenRouter 的BYOK 创建 API接受原始凭据，但说明凭据会静态加密，且不会在之后的 API 响应中返回。请在自己的机密管理器中保存源凭据，因为 OpenRouter 不是凭据恢复备份。

哪些情况下不该默认使用 OpenRouter BYOK

如果单一提供商的原生日志、精确端点行为或厂商工具链，比统一路由更重要，直接调用提供商 API 是更好的默认选择。若你拥有多个提供商账户、已有提供商 credits 或承诺容量，并且需要工作区级控制，BYOK 则更合适。

OpenRouter BYOK 常见问题

使用自己的密钥后，OpenRouter 还会收费吗？

会。提供商可能通过 BYOK 凭据收取推理费用；超过当前套餐额度后，OpenRouter 可能从 credits 中扣除 5% 的 BYOK 平台费用；故障切换还可能让 OpenRouter credits 支付其他提供商路由的费用。

“始终用于此提供商”会关闭所有故障切换吗？

不会。它只会阻止 OpenRouter 对指定提供商使用自身的共享凭据，并不能阻止请求转向其他兼容提供商。当跨提供商路由必须完全不可能时，应使用 provider.only。

企业应如何管理 BYOK 的安全性和预算？

OpenRouter 表示凭据会被加密，原始提供商密钥不会通过管理 API 返回；默认情况下，BYOK 消费不计入 guardrail 和工作区预算。其BYOK 文档说明，如需统一预算，应启用 Include BYOK spend 或 include_byok_in_budgets。企业团队还应采用最小权限凭据、工作区隔离、筛选条件、机密管理器托管、定期轮换和 Activity 审查。

默认配置应取决于你能接受哪种失败

应根据你最不能妥协的目标——请求完成率、提供商归属，还是成本可见性——来选择路由与预算控制方式。