OpenRouter 退款规则怎么算？官方政策与申请路径

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

先把结论说完：OpenRouter 的退款只覆盖一种情形——你充进去但还没花掉的那部分额度，而且必须在这笔交易被处理之后的 24 小时之内，自己去 Credits 页面点退款按钮发起。过了这个窗口，官方条款写得很直白，未使用额度就变成不可退了。除此之外还有三条边界同样容易吃亏：退的只是未使用额度本身，购买额度时收的那笔平台手续费不退；加密货币支付的部分官方明确写了永不可退；而「额度没到账」「请求失败却像被扣了钱」「注销账户后额度消失」这三类最常被当成退款问题的情况，官方给的其实是完全不同的处理路径，当成退款去申请只会白等一轮。

官方那一段退款政策，实际上设了四道条件

OpenRouter 官方 FAQ 里退款只占一个问答条目，篇幅很短，但里面塞了四个互相独立的限定，缺一个理解都会偏。

第一道是对象限定：可退的是 unused Credits，也就是未使用额度。已经被推理调用消耗掉的那部分，不在讨论范围内。这意味着退款申请的可行性，取决于你在这段时间里到底跑了多少请求，而不取决于你充了多少。

第二道是时间限定：申请要在这笔交易被处理起的 24 小时之内提出。注意官方措辞是「自该笔交易被处理时起算」，是按交易计的，不是按账户计的。至于开了自动补充额度之后，每次自动补充的窗口各自怎么起算，官方文档没有说明。24 小时之内没有收到退款申请，官方的原话是这批未使用额度即成为不可退款。这个期限以官方条款当前版本为准。

第三道是路径限定：在窗口期内要发起，用的是 Credits 页面上的退款按钮，退回原支付方式。也就是说这是一个自助操作，不是先发邮件走人工。官方没有说明按钮在什么情况下不显示；如果你在页面上找不到它，按官方给的账单类问题联系方式去问支持邮箱即可。

第四道是范围限定：官方原文是 the platform fees are non-refundable——平台手续费不退。OpenRouter 收你钱的位置本来就分成两层，充值环节的手续费和调用环节按供应商原价透传的推理费，这两层的差别我在充值手续费是怎么产生的里拆过。退款只作用在额度这一层，手续费那一层是沉没的。所以频繁小额充值再退款，除了手续费一次次沉没之外没有别的效果。

申请之前，先把「未使用」这个口径查准

既然退的是未使用的部分，那你在按下按钮之前最该确认的就是：截至此刻，这笔充值到底被消耗了多少。官方给了两个查法，粒度完全不同。

一个是 Activity 页面。官方 FAQ 说明它可以查看历史用量，并且支持按模型、供应商、API key 三个维度过滤。这个页面的价值在于定位——如果你发现额度掉得比预期快，用 key 维度过滤一遍通常能直接看出是哪个应用在吃额度。

另一个是 credits 接口。FAQ 里把它描述为提供账户余额与剩余额度的实时信息；而官方 SDK 文档里同一个操作（getCredits，也就是 Get remaining credits）的说明写的是「返回该已鉴权用户累计购买与累计已用的额度」。两处措辞的口径不完全一样，具体返回结构以官方 API 参考页为准。

这里有个很容易卡住的细节：SDK 文档在这个操作下面单独标注了需要 management key。它和你平时发推理请求用的那把 key 不是一回事，拿普通 key 去调这个接口是走不通的。想把余额查询做进自己的监控里，这一步得先解决。更一般的成本监控该怎么搭，可以参考API 成本监控这篇，OpenRouter 只是其中一种具体形态；只想把控制台和接口两个口径对齐的话，余额和用量怎么查那篇讲得更细。

加密货币支付这条路，没有退款可言

支付方式会直接改变退款的可能性，这一点在别的服务上不常见，在 OpenRouter 这里是明写的。

官方接受的支付方式是主流信用卡、支付宝，以及 USDC 形式的加密货币支付，另外还说了正在推进接入 PayPal。前两类落在上面那套退款规则里；但加密货币支付这一类，官方单独补了一句 cryptocurrency payments are never refundable——永不可退，没有 24 小时窗口这回事。

所以决策顺序应该反过来：不是充完了再想能不能退，而是在选支付方式的时候就把这条算进去。如果你对充多少心里没底，或者只是想先试试这个平台合不合用，那么选一条本身留有退款可能的支付方式，比事后补救有意义得多。

另外有个容易踩空的历史包袱：加密支付的老接口已经不能用了。官方文档写明，由于 Coinbase 弃用了底层 API，POST /api/v1/credits/coinbase 这个端点已被移除，现在请求它会返回 410 Gone，响应体里带着一句说明让你改用网页端的额度购买流程。官方目前的加密购买走的是 Coinbase Business Checkouts。如果你手上还有早年写的自动充值脚本调这个端点，它不会「充失败等你重试」，而是直接 410，得改成走网页流程。

三类被误当成退款的情况，各有各的官方路径

我把这三类单独拎出来，是因为它们的共同特征是「钱看起来没了」，但处理方式和退款完全不搭边。

额度没到账：这是排查，不是退款

官方在 FAQ 里给了一条顺序很明确的路径：用 Stripe 支付时偶尔会有集成延迟导致额度显示滞后，允许等待最多一小时；一小时之后仍然没出现，先去确认自己到底有没有被扣款、有没有收到 Stripe 的收据邮件；如果没有收据、或者没被扣款（官方用的是「或」），官方说卡可能被拒，换一张卡或换一种支付方式重试；如果确实被扣了款但额度没到，这时才是发邮件到官方支持邮箱、附上购买详情；加密支付出问题同样是走邮件。

注意这条路径里从头到尾没有「申请退款」这一步。卡被拒的情况根本没有产生成功交易，没有东西可退；已扣款未到账属于对账问题，走的是支持工单。把它当退款去点按钮，只会因为找不到对应交易而卡住。这一整套排查的展开版见充值失败怎么办。

请求失败却像扣了钱：官方有一层默认兜底

这一类值得单独讲，因为很多人不知道它存在。OpenRouter 有个叫 zero completion insurance 的机制，官方明说它对所有账户默认开启、不需要任何配置。

它的触发条件官方列了两条，满足任意一条就不对该模型的 prompt、completion、reasoning 三类 token 计费：响应的 completion token 数为零且 finish reason 为空或 null；或者 finish reason 是 error。落到界面上，被这层保护覆盖的请求，在 Activity 页面上显示的 token 用量扣费是零——即便上游供应商实际上就 prompt 处理向 OpenRouter 收了钱。

但它的边界要看清楚：它不覆盖那些在响应失败之前就已经真实执行过的辅助服务。官方点名的是联网搜索、文件解析与 PDF OCR、网页抓取这几类，这些工作按实际发生的量仍可能计费，即便模型的响应最后以 error 收场；只有在某些完全没有产生 token 的上游失败场景下，这些费用才会一并跳过。真被计费时，它们会出现在该次请求的用量明细里。

非文本模态还有各自的判定口径。语音合成这边，官方把「可用输出」定义为响应流交付了格式有效的音频——MP3 至少一个完整的 MPEG 帧，PCM 至少一个完整采样；空的、无效的、被截断的输出不计费；而按字符计价的请求，一旦交付了可用音频就按完整输入计费，包括客户端在收到部分音频后取消的情况。图像生成这边，可用输出指响应至少交付了一张 base64 载荷非空且可解码的图片；没有图像数据、载荷为空、或者载荷不是合法 base64 的，被判为上游失败不计费。官方还特意说明这层校验只检查 base64 能否解码，不检查解码后的字节格式。

所以遇到「请求报错了但好像扣了钱」，正确动作是先去 Activity 页面看那次请求的用量明细，确认扣的到底是模型 token 还是辅助服务，而不是直接去申请退款。

额度过期与注销账户：这是失效，不是可退

还有两条会让额度消失、但和退款无关的路径。

一条是过期。官方条款里保留了在购买之后的一段时间作废未使用额度的权利，具体期限以官方条款为准。这是条款层面的权利声明，不是退款通道——额度到期作废不会退回你的支付方式。

另一条是注销账户。官方给的入口是 Settings 页面点 Manage Account，在弹出的窗口里选 Security 标签，那里有删除账户的选项。同一段里紧跟着一句提醒：未使用的额度会随之丢失，且在删除后重建账户也无法找回。这条对准备换账号、换主体的人尤其要紧——先把额度用掉或在窗口期内处理完，再动注销这个动作。

组织账户里，谁能发起这件事

如果你的额度在组织账户下，退款相关的操作权限是收敛的。官方文档写明，购买额度、查看详细账单信息、管理支付方式与开票设置这几项属于管理员，并用一个警告框强调普通成员不能购买额度也不能访问账单信息，与额度相关的请求要联系组织管理员。

顺带说一个相邻但不同的机制：个人账户里的合格额度可以自己转入组织，路径是 Settings > Credits 里选择转入组织、挑选符合条件的组织、确认金额后完成转移。但这条路有几个官方明写的限制：走发票或欠款计费的组织不能接收转入的额度，因为它们不是预付额度余额模式；新加入的组织成员要满足一定的任职时长要求，组织才能接收转移；一个刚接收过转移的组织再次接收之前还有冷却期。至于反方向从组织转回个人，官方文档里没有给出自助路径；文档在额度转移一项上给的是发邮件联系支持提出转移请求。

要强调的是，转移不是退款的替代方案。它只是把额度换个归属，钱并没有回到你的支付方式，至于转移动作与退款窗口之间是什么关系，官方文档没有说明。

最容易栽的坑，其实在充值那一刻

把上面这些串起来会发现，OpenRouter 的退款设计留给你的操作空间很窄：窗口短、只退未使用部分、手续费不退、加密支付直接出局。这不是可以靠事后补救的东西。

真正有效的做法是把决策前移。第一次接触这个平台，先用官方给新用户的那点免费额度把链路跑通，确认模型、参数、账单口径都符合预期，再谈充值；确定要充的时候，选一种保留退款可能的支付方式；充值之后的头一天，如果发现平台不合用，那是你唯一还能自己按按钮的时间段。等过了这一天，剩下的问题就只剩「怎么把已有额度用完」，而不是「怎么把钱要回来」。

另外，账单和账户类的问题官方指定的联系方式是支持邮箱；官方把 Discord 的用途限定为提交 bug 报告与变更请求。搞错渠道，等待时间会白白拉长一轮。