OpenRouter 免费转付费的临界点怎么判断：三个官方信号

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

在 OpenRouter 上，免费和付费不是两套账号，而是同一个账号上的两组开关。GET /api/v1/key 响应里有个 is_free_tier 字段，官方注释写的是「该用户此前有没有购买过额度」——是一个历史事实，不是当前余额；官方没有进一步说明它的取值含义，所以别直接拿它当「我算不算免费用户」的判据。所以真正要判断的临界点，不是「我这个月花了多少」，而是「我撞的是哪一堵墙」：是花得太多（credit limits），还是发得太密（rate limits）。这两类限制官方分得很清楚，管的东西不同、去哪儿查不同、解法也不同。撞第一堵墙，充值就够了；撞第二堵墙，充值只能把免费模型的每日上限抬到更高一档，官方给的另一条解法是直接切到该模型的付费变体。

先分清两堵墙：能花多少 vs 能发多少

官方 Limits 页开篇就用一张表把限制拆成两类，这张表是整篇判断的地基：

• Credit limits，管的是 how much you can spend——你能花多少。它有两个来源：账户余额，以及单个 API key 上可选配置的消费上限。查的地方是 GET /api/v1/key 响应里的 limit_remaining。
• Rate limits，管的是 how many requests you can make——你能发多少请求。它覆盖免费模型的请求上限，以及 Cloudflare 的 DDoS 防护（官方说法是会拦截显著超出合理用量的请求）。查的地方是错误响应上的 X-RateLimit-* 头。

对应到官方错误码表里的 error_type 字段，也是两个完全不同的取值：额度不足是 payment_required（描述为账户或 API key 额度不足，充值后重试），限流是 rate_limit_exceeded（描述为请求级或 token 级限流，重试前要尊重 Retry-After 头）。这些取值以官方文档当前版本为准。

之所以要先分清，是因为免费用户最常见的误判就是「一报错就以为该充值了」。如果你撞的其实是 rate_limit_exceeded，充值当然也有用，但用法和撞额度墙完全不是一回事。关于限流本身的触发条件与退避写法，站内另有一篇专门讲 OpenRouter 免费层速率限制的应对方式。

官方对「免费用户」的定义，就一句话

GET /api/v1/key 的响应类型定义里，is_free_tier 这个布尔字段的注释是：该用户此前有没有购买过额度。注意它的时态——是「曾经买过没有」，不是「现在还剩多少」。这个口径值得记住，因为它和另一处是对齐的：官方那张免费模型限额表的第一列，表头是「累计购买的额度（all time）」，后两列分别是每分钟请求数和每天请求数。也就是说，免费模型的请求上限是按你历史累计的购买额度分档的。

限额表里的具体数值本文不写。要看确切数值，只能去官方的定价与限额页面查——本文也不去别处找数字来填这个空。

理解了这个口径，就能明白一件事：在 OpenRouter 上充值有两重作用，一是买推理用的额度，二是把免费模型的每日请求上限抬到更高一档。官方在 429 处理一节里也列了这一条：在免费变体上，购买一定量的额度以提高每日上限（该节第一条是指数退避重试）。免费额度到底怎么发放、用完之后有哪些选择，可以看 OpenRouter 免费额度规则那一篇。

顺便说一个很多人会试的歪招：多开账号、多开 key。官方文档在 Limits 页顶部的提示框里直接堵死了这条路——新建账号或新建 API key 不会影响你的速率限制，因为容量是全局治理的（we govern capacity globally）。同一段里官方给了一条合法的分摊办法：不同模型的速率限制不同，所以可以把负载分散到不同模型上。

三个信号说明你已经越过临界点

信号一：429 反复落在免费变体上

官方在「Handling 429 errors」一节针对免费变体给了两条解法，注意它们是并列的两条，不是一条：其一，购买一定量的额度以提高每日上限；其二，切换到该模型的付费变体，付费变体没有平台级的请求上限（no platform-level request cap）。

第二条要读准边界：官方说的是「平台级」没有请求上限。上游供应商那一侧的限流依然存在——官方明确写了 429 可能来自两个地方，一个是 OpenRouter 平台限制（免费模型的每分钟或每天请求数、以及 DDoS 防护），另一个是正在为你服务的上游供应商在限流或已满载。后者的情况下，error.metadata.provider_code 会在可获取时带上供应商的原始错误码，而且 fallback 路由会在错误抛到你面前之前自动重试同一模型的其他供应商；你也可以再指定 fallback 模型，在第一个模型的所有供应商都试完之后换模型。

信号二：你打算把它放进生产环境

官方 FAQ 在介绍免费层时，对免费模型的定位是「速率限制很低，通常不适合生产使用」（usually not suitable for production use）。这句话不是性能评价，也不是对生成质量的判断，而是官方对这批模型可用性预期的直接说明。如果你的调用已经从「自己试试」变成「有人在等结果」，那这句话本身就是一个明确信号。

信号三：你开始需要可预期，而不是更多次数

官方对 :free 变体的描述里有一句话，措辞值得逐字看：免费变体让你无成本地使用模型，但可能（may）与付费版本有不同的速率限制或可用性。官方用的是 may，没有承诺免费变体的限制和可用性会与付费版一致，也没有承诺它们会怎么变。当你的判断标准从「够不够用」变成「今天和昨天一样不一样」时，你要的东西就已经不在免费层的承诺范围里了。

怎么在撞墙之前把临界点算出来

这里有一个很多人不知道的限制：成功的推理响应里不带 X-RateLimit-* 头。官方在 Limits 页的注记里写得很清楚——只有当 OpenRouter 自己因为平台限制返回错误时，那个错误响应上才会带 X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset 三个头，描述刚刚被撞到的那条限制；如果每一个尝试过的供应商都返回了重试提示，错误响应上还会额外带一个 Retry-After 头。

这意味着你没法靠正常响应做事前预警。官方给的唯一办法是主动调 GET /api/v1/key。那个响应里能用来算临界点的字段有这么几组：

• usage：全时段累计消耗的额度数量。
• usage_daily / usage_weekly / usage_monthly：当前 UTC 日、当前 UTC 周（周一起算）、当前 UTC 月的消耗。注意这里的日界是 UTC，不是你的本地时区，跨时区团队做日报时口径特别容易错位。
• limit / limit_reset / limit_remaining：描述这个 key 上那道可选的消费上限，分别是上限值、重置方式、剩余量；官方说明里，limit 为 null 表示无上限，limit_reset 为 null 表示永不重置。
• include_byok_in_limit：决定外部 BYOK 用量算不算进上面这道上限。
• byok_usage 以及对应的 daily / weekly / monthly：BYOK 用量单独统计。
• 响应里还有一个 rate_limit 对象，官方注释标注它已废弃，可以安全忽略——别再往它上面搭监控。

有了这几个字段，估算的做法就很直接：对齐 UTC 日界，连着几天记 usage_daily 和 limit_remaining 的值，看斜率而不是看单点。这套做法与站内 API 成本监控该盯哪些指标 讲的通用思路是一致的，只是字段名换成了 OpenRouter 这一套。另外，官方对 Activity 页的说明是可以查历史用量并按模型、供应商、API key 过滤；账户余额的实时信息官方指的是 credits 接口。另外要说明的是，key 接口给的是这把 key 的口径，账户整体的余额与历史用量在控制台的 Activity 页看，那里可以按模型、供应商、API key 过滤。

一个会让你低估自己用量的漏计陷阱

如果限流是在流式输出已经开始之后才触发的，它不会以 HTTP 错误的形式出现——因为状态码此时早就发出去了。官方给的形态是：错误作为一条 SSE 事件返回，finish_reason 的值是 "error"，错误体挂在事件里。

后果很实在：只按 HTTP 状态码统计错误率的监控，会把这部分限流全部漏掉，让你以为自己离临界点还远。做流式调用的话，finish_reason 必须一起统计。

越过临界点之后，哪些会变、哪些不会

• 手续费只在购买额度这一步产生。官方的说法是购买额度时收取一笔费用，而底层模型的价格是原样透传、不加价（without any markup），你付的和直接找那家供应商付的是同一个价。所以「转付费到底贵不贵」要拆成两段来算：一次性的购买手续费，加上与供应商同价的推理费用。费用怎么构成、怎么自己估，见 OpenRouter 充值手续费的构成。
• 官方目前不提供批量折扣（does not currently offer volume discounts），只说特殊用例可以邮件沟通。所以别把「用量做大以后单价自然会降」写进你的成本模型。
• 额度不是永久的。按官方条款，OpenRouter 保留在购买满一年后作废未使用额度的权利。
• 余额为负时，免费模型这条退路也可能一起断。官方原文的措辞是：账户额度为负时，你可能（may）会看到报错，包括在使用免费模型时；把余额补到零以上就能重新使用这些模型。这条我要特意强调情态——官方写的是 may 不是 will。但即便只是「可能」，它也推翻了一个常见直觉：很多人以为付费只是「多一个选项」，免费那条路永远还在。实际上一旦余额跌到负数，两条路可能一起受影响。

还有第三条路：BYOK

如果你越过临界点的原因是「想在供应商那一侧直接管限流」，那么转付费并不是唯一出口。官方对两种模式的区分很直接：使用 OpenRouter 额度时，各供应商的速率限制由 OpenRouter 代管；使用你自己的供应商 key（BYOK）时，限流和成本直接由你在自己的供应商账户里控制。

但 BYOK 不等于不花钱。官方写明它有一档按套餐给定的免费额度，而且这个额度按标价推理成本计量，不是按请求数计量（measured by list-price inference cost, not request count）；超出这档额度之后，按同一模型、同一供应商在 OpenRouter 上正常需要花的成本的一定比例收费，这笔费用从你的 OpenRouter 额度里扣。具体比例和各套餐的额度请看官方定价页。

BYOK 的 key 还分两个区，这个设计对可用性影响不小：Prioritized 区里的 key 会在回落到 OpenRouter 端点之前按顺序尝试，适合放主用 key；Fallback 区里的 key 只在 OpenRouter 端点都试过之后才按顺序尝试，适合放你只想在最后关头用的备份 key。两个区之间可以在供应商详情页上拖动调整。

最后：三个最容易栽的坑

1. 拿多开账号当扩容手段。官方明说容量是全局治理的，新账号新 key 都不影响限流。想分摊，正经办法是分散到不同模型。
2. 只按 HTTP 状态码做监控。流式输出开始之后才触发的限流走的是 finish_reason: "error" 的 SSE 事件，HTTP 那一层看不见。
3. 把「额度用完」和「被限流」混成一件事。前者是 payment_required，解法是充值或调高单 key 上限、或等 limit_reset；后者是 rate_limit_exceeded，解法是退避重试、提高免费日限档位、切付费变体、或者放宽路由让更多供应商可选。混起来看，你会一边充钱一边继续撞同一堵墙。

真要动手的话，第一步很轻：现在就调一次 GET /api/v1/key，把 is_free_tier、usage_daily、limit_remaining 三个值记下来，连着记几天。临界点不是靠感觉判断的，是这三个数字连成的曲线告诉你的。