OpenRouter 充值手续费是怎么产生的？费用构成与自己估算的方法

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先把结论说完：OpenRouter 收你的钱分两层，而且这两层收的位置完全不同。第一层是你充值时的一笔平台手续费；第二层是你调用模型时的推理费，而这一层官方明确声明按底层供应商的价格原样透传、不加价。 这个结构决定了三件事：一、比较”走 OpenRouter 还是直连供应商”，差价不在调用环节，而在充值环节；二、加密货币支付走的是另一档费率，且不可退款，属于要单独决策的一条路；三、如果你用 BYOK（带自己的供应商 key），费用模型会再变一次，不是很多人以为的”零成本”。搞清楚钱在哪几个时点产生，比背下任何一个具体费率都有用——费率会变，这个结构不会。

两笔钱产生在不同环节，别混在一起算

官方 FAQ 里关于费用只有两句话，但这两句话把整个计费结构定死了。第一句是购买额度时会收取一笔费用；第二句是平台把底层模型供应商的价格原样传递，不加任何 markup，所以你付的推理单价和直接找供应商是一样的。

这意味着一件很多人算错的事：当你问”用 OpenRouter 是不是更贵”时，答案不能笼统地说贵或不贵。调用一次模型的钱，和你直连那家供应商是同一个数；多出来的部分，是你把钱充进 OpenRouter 账户那一刻就已经付掉的。

所以正确的比较方式是这样的：把你的月度支出拆成”充多少额度”和”这些额度买到多少次调用”两部分。前者带手续费，后者不带。如果你的调用量很大、充值次数很少，手续费被摊薄的程度就高；反过来，如果你习惯每次只充一点、频繁补充，那这笔固定环节的费用在你的总支出里占比就会明显一些。

这也解释了 OpenRouter 的盈利模式为什么和很多中转服务不同。官方在 FAQ 里自问自答过”OpenRouter 怎么赚钱”，回答就是购买额度时收取的这笔费用，并再次强调从不给底层供应商的定价加价。你可以不认同这个模式，但至少它是公开写在文档里的，而不是藏在你看不到的单价差里。

基础货币是美元，这决定了你还有一层隐性成本

官方文档明确写着额度体系的基础货币是美元，站点和 API 上的所有定价都以美元计价。这一点对国内用户有两个实际后果。

第一个后果是，你实际付出的人民币金额，取决于你使用的支付方式在结算那一刻的汇率与相关费用，这部分不由 OpenRouter 决定，也不体现在它的费用说明里。所以你在 OpenRouter 后台看到的余额数字，和你银行卡上少掉的钱，本来就不是一一对应的关系。做成本核算时，这两个口径要分开记。

第二个后果是，官方支持的支付方式里包含了信用卡、支付宝和 USDC 加密货币支付这几类，文档里还提到 PayPal 在接入计划中。支付方式的选择会影响到费率档位和退款可能性，下一节专门讲这件事。

加密支付是单独一档，而且它换走了你的退款权

官方在同一段费用说明里，把加密支付的费率单独列了出来——这说明它和常规支付走的不是同一档。文档没有把两者说成同一件事，你在写自己的成本模型时也不该把它们合并。

更需要提前知道的是退款规则。OpenRouter 的退款政策是：交易处理后二十四小时内可以申请退还未使用的额度，在 Credits 页面用退款按钮操作，金额退回原支付方式。但这条规则有两个限定：平台手续费部分不退，以及——加密货币支付永远不可退款。

把这两条放在一起看，选择加密支付实际上是一个交换：你可能拿到一档不同的费率，代价是彻底放弃了那个二十四小时的反悔窗口。如果你是第一次用、还不确定要充多少，或者你所在的组织有报销与冲正流程，这个交换大概率不划算。

顺带说一个容易被忽略的时间点：那个退款窗口是从交易被处理的时刻开始算的，不是从你发现充多了的时刻开始算的。超过窗口没申请，未使用的额度就变成不可退了。

BYOK 不等于免费，它是第三笔账

如果你已经有某家供应商的 key，想通过 OpenRouter 的统一接口去调用，这就是 BYOK。很多人默认这样等于只付供应商的钱、白用 OpenRouter 的接口层，但官方文档说得很清楚：这是要收费的。

官方给的机制是这样的：BYOK 有一个随套餐而定的免费额度，而且这个额度是按推理成本的挂牌价来衡量的，不是按请求次数。这个区别很重要——同样一万次请求，你调的是小模型还是旗舰模型，消耗掉的免费额度完全不是一个量级。超出免费额度的部分，按同一模型、同一供应商在 OpenRouter 上正常价格的一定比例收取，这笔费用从你的 OpenRouter 额度里扣。

所以 BYOK 的真实价值不在于省钱，而在于官方自己写的那句话：让你直接和供应商去管理限流和成本，同时仍然使用统一接口。如果你的诉求是绕开 OpenRouter 的限流、或者你在供应商那边有企业协议价，BYOK 才是对的选择；如果你的诉求单纯是省手续费，它并不解决这个问题。关于 key 本身的管理，可以参考API Key 安全管理的通用做法。

额度会过期，所以”一次充够”有沉没风险

这一条藏在条款里，很少有人注意：按照 OpenRouter 的服务条款，平台保留在购买后一段时间内作废未使用额度的权利。具体期限以官方条款为准，但”额度不是永久有效”这个事实本身，会改变你的充值策略。

配合这条规则再看官方提供的自动充值功能，逻辑就清楚了。官方支持手动充值，也支持设置自动充值：当余额低于你设定的阈值时自动补充。这个功能的意义不只是省事——它让你有条件采取”少量多次”的节奏，而不必为了减少充值次数一次性压进大额资金。

要不要用自动充值，本质上是在两种成本之间做取舍：一次充大额，摊薄了充值环节的费用，但承担额度闲置与过期的风险；少量多次，规避了过期风险，但充值环节的费用在总支出里占比更高。没有标准答案，取决于你的用量是否稳定、可预测。顺便说一句，官方 FAQ 里明确回答过目前不提供用量折扣（有特殊场景可以邮件沟通），所以”充得多单价更低”这个在很多云服务上成立的直觉，在这里不成立。

怎么把自己的月成本估出来

不背单价，也能把账算清楚，方法是按下面的顺序走：

第一步，先确定你的模型组合。 去官方模型目录看你实际会用到的那几个模型的挂牌价——这个数字必须去官方页面现查，不要用任何二手来源，包括本文。这一步拿到的是”每单位 token 多少钱”。

第二步，估你的 token 量，而不是请求数。 这是最容易出错的地方。请求数对成本几乎没有指示意义，因为一次长上下文请求可能抵得上几十次短请求。如果你已经在用了，直接去 Activity 页面看历史用量，它支持按模型、按供应商、按 API key 过滤，这比任何估算都准。如果还没开始用，就用你的典型输入长度乘以预期调用次数，先得一个粗略量级。

第三步，把充值环节的费用加回去。 前两步算出来的是推理费，还要按你计划的充值节奏，把充值时产生的那笔费用加上。这一步不能省，否则你算出来的永远比实际付的少。

第四步，上线后用接口持续校准。 官方提供了查询剩余额度的 credits API，能拿到账户余额和剩余额度的实时信息。把它接进你自己的监控，比等到调用失败才发现余额见底要好得多。这方面的通用做法可以参考API 成本监控这篇。

几个真会栽的坑

充值没到账，先等满一小时再折腾。 官方明确说了 Stripe 支付偶尔会有延迟，让你允许最多一小时的到账时间。一小时后还没到，官方给的排查顺序是：先确认自己是否真的被扣款、有没有收到 Stripe 的收据邮件；如果没有收据、或者没被扣款（官方用的是「或」），官方说卡可能被拒，换一张卡或换个支付方式重试；如果确实被扣款了却没有额度，发邮件给官方支持并附上购买详情。加密支付出问题同样是走邮件。这个顺序值得照做——很多人一看到余额没变就立刻重复支付，结果变成要处理两笔交易。

余额为负的时候，免费模型也可能跟着用不了。 这条反直觉但确实写在官方限额说明里：账户余额为负时你可能会看到错误，包括对免费模型的请求。把余额补到零以上才能恢复。所以如果你某天发现免费模型突然全都调不通，先去看余额，别去查模型状态。

别忘了 API key 上可能还有一层独立的额度上限。 官方的额度限制来自两个地方：账户余额，以及单个 key 上可选配置的消费上限。第二层是很多人自己设了又忘了的。查询 key 信息的接口会返回上限、重置周期和剩余量三个字段，遇到额度问题时两层都要看。关于额度本身的管理，站内还有一篇OpenRouter 额度管理可以对照着看。

最后

这篇没有给你任何一个具体费率，是有意为之——费率、免费额度、限额这类数字随时会调整，写死在文章里只会让读者在几个月后被误导。真正稳定、值得记住的是结构：充值环节收费、调用环节透传、加密支付另一档且不可退、BYOK 另有一套按挂牌价衡量的免费额度、额度本身不是永久有效。

把这个结构记住，任何时候去官方定价页看一眼当前数字，你就能自己把账算准。如果你还在决定要不要走聚合层，站内的API 聚合与中转的横向对比从另一个角度讨论了这个选择。