OpenRouter 最低充值门槛是怎么定的？额度机制与首充注意事项

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

先把结论说完：在 OpenRouter 的官方文档里，找不到”单笔充值不得低于多少”这样的条款。官方对付费模式的描述是按 token 计价、无最低承诺。真正在起门槛作用的是另外三样完全不同的东西——一个记录”你有没有付过费”的布尔字段、一张以”累计购买额度”为行维度的免费层限额表、以及一条”余额为负时免费模型也可能跟着不可用”的规则。 这三层里，第一层只关心有没有，不关心多少；第二层关心的是全时段累计，不是单笔也不是当前余额；第三层关心的只是余额别掉到零以下。所以”最低充值门槛”这个问题，问法本身就有点错位：你要定的不是一个下限金额，而是一个能同时满足这三层判定、又不让钱闲置过期的充值节奏。

官方文档里没有”最低充值金额”这一条

先把这个负面结论坐实，因为很多人是带着”肯定有个起充线”的预期来查的。

OpenRouter 的额度体系在官方 FAQ 里被描述得很朴素：额度就是你存在 OpenRouter 上的一笔押金，你用 API 或者 Chat 界面发起请求时，平台把这次请求的成本从额度里扣掉。每个模型、每家供应商的每百万 token 单价不同，具体数字在模型页上现查。整套说明里没有任何一处规定单笔购买的下限。

唯一接近”门槛”这个词的官方表述，出现在 Stripe Projects 那份集成文档的 Plans and billing 一节。那里写了 OpenRouter 通过 Stripe Projects 提供两种计划：Free，只能访问免费模型，不需要绑定支付方式；Pay-as-you-go，按 token 计价，无最低承诺，费率去模型页看。注意这句话的适用范围是 Stripe Projects 这条集成路径下的计划描述，但它至少说明了一件事：官方并没有把”先充够多少钱才准用”写成一条规则。

所以如果你在别处看到某个具体的”OpenRouter 最低充值金额”，那个数字要么来自二手转述，要么来自支付通道本身的限制，而不是 OpenRouter 的产品规则。这类数字随时会变，也不该当成决策依据。

真正起门槛作用的三层判定

第一层：一个只认”有没有”的布尔字段

调用 GET https://openrouter.ai/api/v1/key 会返回当前 key 的信息，返回体里有一个字段叫 is_free_tier，官方给它的注释是”该用户此前是否购买过额度”。

这是个布尔值。它不记录你充了多少，只记录你有没有充过。这个设计意味着：在”是否还算免费层用户”这件事上，充一笔小额和充一笔大额，效果是同一个——把这个标志位翻过去。所以如果你的目的仅仅是”不再被当成完全没付过费的账户看待”，没有任何理由为此多充。

第二层：一张以”累计购买额度”为维度的表

官方限额文档里，讲免费模型速率限制的地方是一张表。这张表值得单独看一眼它的行维度：不是当前余额，不是本月消费，而是 Credits purchased (all time)——全时段累计购买额度。表只有两行，一行是低于某个阈值，一行是达到该阈值及以上；列是每分钟请求数和每天请求数两档限制。

本文不打算给你具体数字，一切以官方文档页当前显示的为准。但表的结构本身比数字更有信息量：

• 它是”累计”口径。你三年前充的那笔，和你今天充的这笔，在这张表里是加在一起的；你把额度花光了，累计购买量也不会退回去。
• 它只对免费模型变体（ID 带免费后缀的那些）生效。你调付费模型时，管你的是额度，不是这张表。
• 它是个台阶，不是连续函数。累计购买量在同一档里再怎么增加，每日请求上限都不动，跨过那道线才会变。

把这两点合起来看，“最低充值门槛”这个问题在免费层语境下就有了一个可操作的翻译：如果你的目的是提高免费模型的每日请求上限，你要盯的是自己的累计购买量跨没跨过官方那张表的分档线，而不是纠结某一笔充多少。

第三层：余额必须为正，否则免费模型也用不了

这条最反直觉，但它写在官方限额说明的 Credit limits 一节里：如果账户额度余额为负，你可能会看到请求失败，包括对免费模型的请求。 把余额补到零以上，才能重新使用这些模型。

也就是说，OpenRouter 的免费模型不是”和账单无关”的东西，它挂在同一个额度体系上。日常最容易踩的场景是：你的付费调用把余额扣成了负数，然后你发现连一直好用的免费模型也全部报错，于是跑去查模型状态、查 key、查网络——查错了方向。遇到这种全线失败，第一件事是看余额。

官方还提到了额度限制的第二个来源：单个 API key 上可选配置的消费上限。GET /api/v1/key 的返回里，limit、limit_reset、limit_remaining 三个字段描述的就是这个上限、它的重置方式和剩余量。官方给的 402 处理顺序也是分这两层的：先充值把账户余额补到零以上，再检查这个 key 的 limit_remaining 是不是耗尽了（耗尽就提高上限或等 limit_reset），最后建议主动调这个接口做提前监控，别等请求开始失败才发现。关于这两层额度怎么配合着管，站内另有一篇OpenRouter 额度管理可以对照着看。

首充比后续充值多出来的两步

首次购买和之后的每一次购买，流程是不一样的，这点官方在讲发票 Tax ID 的那篇文档里顺带交代得很清楚。

入口是 settings/credits 页面的 Add Credits 按钮。如果你此前没有购买过，弹出的窗口会先带你填账单地址（billing address），再让你添加支付方式，两步都在同一个弹窗里完成。 这两样保存好之后，主购买表单才会出现，表单里可以展开 Edit Tax ID 那一节填税号。

对国内读者，这里有三个实际提醒：

第一，账单地址这一步是首充独有的，后续充值不会再问你。所以第一次操作耗时更长、卡住的环节也更多，别把它当成”点两下就完事”的动作安排在很赶的时间点。

第二，Tax ID 最好在首充时就填。 官方的说法是，保存税号后 Stripe 会把它挂到你的客户记录上，并出现在之后每一张发票上。措辞是”going forward”，也就是对已经开出的发票不追溯。企业报销场景下，第一张发票如果漏了税号，事后再补会麻烦得多。税号支持的类型来自 Stripe，涵盖多国的增值税号、公司税号等，输入框会按你选的国家代码提示格式。

第三，标价不含税。 官方明确写着 OpenRouter 上的价格是不含适用税费的，在你所在司法辖区需要征收时，增值税或商品服务税由 Stripe 在购买时自动计算并加到发票上。所以你实际付款的金额和你购买的额度面值本来就不会完全相等——再叠加充值环节本身的平台手续费，这个差额还会更大一些。手续费是怎么产生的、和调用费为什么是两笔账，OpenRouter 充值手续费的构成那篇讲得更细。

支付方式方面，官方 FAQ 列出的是：主流信用卡、支付宝（AliPay）、以及以 USDC 结算的加密货币支付，另外提到 PayPal 在接入计划中。这就是官方支持的全部方式，任何官方渠道之外的路径都不在本文讨论范围内。

决定首充充多少，该看的是这几条规则

既然没有下限约束，那”充多少”就完全是你自己的取舍问题。官方文档里有四条规则直接影响这个取舍，建议在下单前一起看：

退款窗口是从交易被处理的那一刻起算的。 官方政策是，未使用额度的退款申请须在交易处理后二十四小时内提出；超过这个窗口没有申请，未使用的额度就变为不可退。申请入口是 Credits 页面上的退款按钮，金额退回原支付方式。注意窗口的起点是交易时间，不是你发现充多了的时间——这意味着周五晚上的一笔冲动充值，很可能等你周一想起来时窗口已经关了。

平台手续费不退。 即便你在窗口内成功退了未使用的额度，充值环节产生的那笔平台费用也不在退还范围内。所以”先充一大笔试试，不合适再退”这个想法的成本并不为零。

加密货币支付永远不可退。 官方的表述没有留任何余地。如果你还在评估阶段、不确定用量，选加密支付等于放弃了那个二十四小时的反悔窗口。

额度不是永久有效。 按官方条款，平台保留在购买后一段时间作废未使用额度的权利，具体期限以官方条款为准。这条决定了”一次充够、省得麻烦”这个策略是有沉没风险的。

再补一条容易被当成常识但在这里不成立的：官方 FAQ 明确回答过目前不提供用量折扣（有特殊场景可以走邮件沟通）。所以”多充能拿到更低单价”这个在很多云服务上成立的直觉，在 OpenRouter 上没有依据，也就不构成把首充金额往上加的理由。

还有一条属于账户层面的：官方 FAQ 讲删除账号时说明，未使用的额度会丢失且无法找回，即使你之后重新创建账号也一样。评估阶段的账号别随手删。

首充之后立刻该做的两件事

一是把自动充值的阈值定下来。 官方支持手动充值，也支持设置 auto top up——余额低于你设定的阈值时自动补充。有意思的地方在于，这个阈值是你自己定的，平台没有替你规定。前面说的”没有最低充值门槛”在这里变成了它的另一面：门槛的位置由你决定，代价是你得自己承担定错的后果。定得太低，容易在半夜业务高峰时撞上余额见底；定得太高，闲置额度又要面对过期风险。

顺带一个很少被提到的机制：官方在讲延迟的文档里写明，当用户额度余额偏低、或某个 API key 接近它配置的额度上限时，OpenRouter 会做额外的数据库校验以保证计费准确、避免超额，并在这种状态下更激进地让缓存过期，直到补充额度为止。换句话说，长期贴着余额下限运行，代价不只是”随时可能断”，还包括这段时期的额外校验开销。

二是把余额和用量的查询接进你自己的流程。 有三个口径要分清：

• GET /api/v1/key：看当前 key 的额度上限与剩余量，以及 usage、usage_daily、usage_weekly、usage_monthly 这几个累计用量字段（分别对应全时段、当前 UTC 日、当前 UTC 周、当前 UTC 月）。用你平时调用的那把 key 就能查。
• Credits 相关的接口：官方描述为查询该账户已购买与已使用的额度总量。要注意的是，在官方 Go SDK 文档里，这个操作被标注为需要 management key，和上面那个用普通 key 就能查的接口不是一回事，以官方文档当前版本为准。
• Activity 页面：查历史用量，支持按模型、按供应商、按 API key 过滤。做归因排查时这个最直观。

这几个口径的取值范围和刷新时机都不一样，别混着用。更通用的做法可以参考站内的API 成本监控。

几个会栽的坑

想靠多开账号或多建 key 绕开限额，官方直接说了没用。 限额文档开头的提示里写着：额外创建账号或 API key 不会影响你的速率限制，因为容量是全局治理的。同一段里官方给的替代思路是——不同模型的速率限制不同，可以靠分散到不同模型来分担负载。这是官方自己给的合规做法，和开小号是两回事。

充值没到账，先等满一小时。 官方明确说 Stripe 集成偶尔会让额度延迟显示，让你允许最多一小时。一小时后仍未到账，官方给的顺序是：确认自己是否真的被扣款、有没有收到 Stripe 的收据邮件；没有收据也没被扣款，多半是卡被拒了，换卡或换支付方式重试；确实被扣了款却没有额度，发邮件给官方支持并附上购买详情。加密支付出问题同样走邮件。这个顺序值得照做，最怕的是一看余额没变就立刻再付一次。

组织账户下，普通成员根本充不了值。 官方写明常规组织成员不能购买额度、也不能访问账单信息，需要联系管理员。另外，个人账户往组织转移额度虽然可以自助操作，但转移对话框会强制两条限制：新加入的成员资格要满足一定的在职时长要求，组织刚接收过一次转移之后有冷却期才能再接收下一次。走发票或欠款计费的组织则完全不能接收转入的额度，因为它们用的不是预付额度余额。团队场景下这些规则要提前问清楚，别等到项目要用了才发现充不进去。

最后

把”最低充值门槛是多少”换成三个更有用的问题：我需要让账户有过购买记录吗？我要不要够到免费层限额表的上一档？我的余额会不会掉到零以下？这三个问题的答案决定了你该怎么充，而它们没有一个是关于单笔金额的。

如果你现在还在评估阶段、根本没想好要不要付费，那更合理的顺序是先把免费的那部分跑透——新用户有一笔小额免费额度，另外还有一批免费模型和一个自动挑选免费模型的路由器可用。这条路怎么走，站内的OpenRouter 免费模型那篇更对口。等你确认了自己的真实用量，再回来定充值节奏，比一上来就纠结充多少要靠谱得多。