OpenRouter 充值有效期规则：额度会不会过期、怎么查剩余

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

先把结论摆出来：OpenRouter 的额度不是”永久有效”的。官方 FAQ 里有一条标题就叫 Do credits expire，答案是——按服务条款，官方保留在购买后经过一定期限仍未使用时作废这部分额度的权利（具体期限以官方条款页为准）。注意措辞是”保留权利”，不是”到期自动清零”，这两件事在读者体感上差别很大。但实际把额度弄丢的，绝大多数不是这条时效条款，而是另外三种更常见的情况：账户余额被用成负数、单个 API key 上挂了消费上限、以及删掉账号重建。查剩余额度也不是只有一个入口——控制台的 Activity 页、GET /api/v1/key、credits 接口三者的口径与鉴权要求都不一样，用错了会得出互相矛盾的数字。

官方对”额度过期”到底写了什么

OpenRouter 的额度体系在官方 FAQ 的 Credit and billing systems 一节里说得很直白：这是一套 credit 系统，有一个统一的基础货币，站点和 API 上的定价都以这个单位标注；用户可以手动充值，也可以设置 auto top up，让余额低于自己设定的阈值时自动补充。

关于有效期，官方只给了一句话，指向的是服务条款：他们保留在额度购买后经过一定时间仍未被使用时，作废这部分未使用额度的权利。

这句话有三个细节值得抠：

第一，它约束的对象是 unused credits，也就是”未使用的额度”。已经消耗掉的部分不存在过期不过期的问题。

第二，它的计时起点是 购买时点，不是最后一次调用的时点。也就是说，这不是”账户静默多久就清零”的休眠规则，而是一笔一笔额度各自从购买那天开始算。如果你的习惯是一次性充一大笔再慢慢用，这个起点选择对你是不利的；分批充、用完再充，反而更贴合这条规则的设计。

第三，官方用的是”保留权利”（reserve the right）的表述，而不是”将会作废”。这是条款里很典型的写法，意思是平台有权这么做，但不承诺一定这么做、也不承诺什么时候做。所以你既不该假设额度永久有效，也不该拿它当成一个可以精确倒计时的日期。真要卡这个点，只能以官方条款页当前版本为准。

顺带说一句：官方 FAQ 里明确写了目前不提供按采购量递减的价格优惠（可以邮件沟通特殊场景）。所以”一次多充一点更划算”这个在别的服务上成立的直觉，在 OpenRouter 上没有对应的机制支撑，反而要多承担上面那条时效条款的风险。手续费怎么产生、影响费用的变量有哪些，另见充值手续费的构成与自己估算的方法。

比”过期”更常见的三种额度消失

一、余额变成负数，连免费模型都调不动

官方 Limits 文档里有一条我认为是全篇最该记住的：如果账户额度余额为负，你可能会看到额度不足类的错误，而且这种失败会波及免费模型。把余额补到零以上，才能重新使用这些模型。（官方用的是「可能」，不是「一定」。）

这条反直觉的地方在于，很多人以为”免费模型”是完全独立于余额的一条通路，余额见底大不了付费模型不能用。事实不是这样——余额为负时，免费通路也可能跟着不可用。对于那种平时只跑免费模型、偶尔手滑调了一次付费模型把余额带成负数的账户，症状会表现成”整个 key 突然全线失效”，很容易被误判成 key 被封。

二、单个 key 上的消费上限

官方把额度限制拆成了两个来源：账户余额，以及单个 API key 上可选配置的消费上限。后者由 GET /api/v1/key 响应里的 limit、limit_reset、limit_remaining 三个字段描述。

这两个来源是相互独立的。账户里明明有余额，但某个 key 的 limit_remaining 已经耗尽，这个 key 照样会失败。官方给的处理顺序是：先充值把账户余额补到正数，再检查这个 key 的 limit_remaining 是否耗尽——耗尽了就提高该 key 的额度上限，或者等它按 limit_reset 描述的周期重置。

三、删除账号

这条藏在 Account management 一节里，很容易漏：官方在讲怎么删除账号时特意加了一句备注——未使用的额度会随账号删除而丢失，且在你之后重新注册时无法找回。删号重建不是重置，是清空。

查剩余：三个入口，三种口径

GET /api/v1/key：用普通 key 就能自查

请求 https://openrouter.ai/api/v1/key，带上 Authorization: Bearer <你的 key>，返回体里 data 对象的字段是这样一组：

• label：这个 key 的标识
• limit：该 key 的额度上限，无上限时为 null
• limit_reset：该 key 上限的重置类型，永不重置时为 null
• limit_remaining：该 key 剩余的额度，无上限时为 null
• include_byok_in_limit：是否把外部 BYOK（自带上游 key）的用量算进这个上限
• usage / usage_daily / usage_weekly / usage_monthly：分别是历史全量、当前 UTC 日、当前 UTC 周（周一起算）、当前 UTC 月的用量
• byok_usage 及其日/周/月版本：BYOK 用量的同款四件套
• is_free_tier：官方对这个字段的注释是”该用户此前是否付费购买过额度”

有两个坑要点名。一是这些统计口径全是 UTC，周还是从周一起算——你在国内看日报，跨时区会让”今天”的边界跟你以为的差半天，对不上账很多时候不是数据错了。二是响应里还有一个 rate_limit 对象，官方注释写明它已废弃、可以放心忽略，别再照着它写监控逻辑。

官方对 402 类错误还给了一条主动动作：不要等报错，直接定期调 GET /api/v1/key 跟踪 limit_remaining 和用量。这是把”事后排障”改成”事前预警”最省事的做法，和通用的 API 成本监控做法是一个思路。

credits 接口：口径不同，而且要 management key

官方 FAQ 在”如何监控额度用量”里提到了另一个入口：一个 credits API，提供账户余额与剩余额度的实时信息。

但翻到 SDK 文档那一侧，同一个操作（GetCredits / get_credits）的描述是”返回该已认证用户累计购买与累计已用的额度”，并且明确标注 需要 management key。

这两处描述的口径并不完全一致，一处说的是”余额与剩余”，一处说的是”累计购买与累计已用”。真要拿它做对账，以官方 API 参考页当前版本的返回结构为准，别按其中一句话的措辞去猜字段。

Management key 本身也有边界：它在 settings 下的 Management API Keys 页面单独创建，不能用来调用补全类接口，只用于管理操作。所以想在应用里顺手查一下余额，GET /api/v1/key 是成本更低的路径；需要账户级汇总时才动 management key。这一块的详细分工见余额和用量怎么查。

Activity 页：适合看历史，不适合看”还剩多少”

控制台的 Activity 页可以查看历史用量，并按模型、供应商、API key 三个维度过滤。官方还提到有实时用量指标的看板。但它的定位是回看已经花掉的部分，判断”还能撑多久”仍然要回到上面两个接口。

余额快见底时，系统行为会变

这是官方性能文档里一条很少被提到、但对生产环境很实际的机制：为了保证计费准确、防止超支，OpenRouter 会在两种情况下做额外的数据库校验——用户额度余额处于很低的区间时，以及某个 API key 接近它配置的额度上限时。在这两种条件下，官方会更激进地让缓存失效，代价是在补充额度之前延迟会上升。

换句话说，余额见底不是一个”用完那一刻才出事”的悬崖，而是在到达零之前就已经开始影响系统行为。如果你的服务对延迟敏感，把补额度的触发线设在余额低区间之前，比等报错再补要合理得多——auto top up 的阈值设置正是为这个场景准备的。

组织账户里的额度归属

如果你在组织（organization）下用 OpenRouter，有几条限制会直接影响”额度在谁手里、能不能挪”:

• 普通成员不能购买额度、也看不到账单信息，额度相关的事只能找管理员。
• 组织内任何成员创建的 key，产生的用量都计入组织的额度池。
• 个人账户的额度可以自己转给组织：在 Settings 里的 Credits 页选择转移到组织，选中符合条件的组织后确认。
• 但走发票或欠款计费的组织无法接收转入额度——它们是按发票结算，不使用预付额度余额这套机制。
• 转移对话框还有两条额外限制：新加入的组织成员需要满足一定的任职时长要求，组织才能接收转移；刚接收过一次转移的组织，要过一段冷却期才能再接收下一次。

这几条合在一起意味着一件事：额度不是一个可以随时在账户之间来回搬的东西。如果你打算把个人账户的余额挪到公司组织下统一管理，要在充值之前就把结算方式想清楚，而不是充完再找补。

一个容易混淆的额度：插件的第三方额度

还有一处特别容易搞混。如果你用了 OpenRouter 的联网搜索插件并选择了 Firecrawl 这类 BYOK 搜索引擎，官方文档写明：接受对方服务条款后会用你的邮箱自动创建一个该服务的账户，这个账户自带一份初始额度，而且这份额度有自己的过期期限（期限与计费口径见对方官方页面）。搜索时消耗的是你在那边的额度，OpenRouter 不额外收费。

所以”我的额度会不会过期”这个问题，在开了插件之后其实有两个答案：OpenRouter 侧一套条款，第三方搜索服务侧另一套。两边的到期规则、计费单位都不通用，别拿一边的余额去推另一边还能用多久。

最后：容易栽的两个坑

第一个坑是把”没过期”当成”没风险”。时效条款只是众多让额度消失的路径中最不常触发的一条。真正让人猝不及防的是负余额可能连免费模型一起波及、以及单 key 上限耗尽——这两个都不看时间，只看用量。

第二个坑是只盯着一个数字。账户余额和单 key 剩余额度是两条独立的闸，任意一条触顶都会让请求失败；而 limit_remaining 为 null 意味着这个 key 没有单独上限、完全跟着账户余额走，不是”剩余为零”。看错这个 null 会让你朝完全错误的方向排查。

真要落地，最小可用的做法是：给关键 key 配上限并记下它的重置类型，同时定期调 GET /api/v1/key 把 limit_remaining 和 usage_daily 推到你自己的监控上；充值节奏上按需分批，别一次性押一大笔进去。如果你是刚充完发现钱花得不对，先去看退款规则与申请路径——那条路径有明确的时间窗口，错过就不可逆了。