API 免费额度到期会扣钱吗？试用余额、免费模型与付费切换核对
分清赠送余额、免费请求次数和订阅试用，核对到期时区、抵扣范围及付费回退，并用分账算例检查自动充值和续费风险。
免费额度到期，不足以判断下一次调用会不会收费。需要同时确认三件事：失效的是哪一种权益、请求能否改扣付费余额、账户是否开启自动充值或订阅续费。只关闭自动充值，也不意味着已有付费余额不会继续被消耗。
本文解决“已经拿到试用机会，怎样控制它的使用边界”。不提供未经核验的免费平台名单，也不承诺注册必送。资料核对日期为 2026-10-24；OpenRouter 官方文档仅用于说明具体机制，不能套用到所有中转站。文中账本为本地算术模拟，没有调用真实付费 API。
1. 先分清余额、次数和订阅试用
| 页面上的说法 | 实际需要确认的权益 | 不能据此推定 |
|---|---|---|
| 赠送 10 额度 | 可抵扣哪些消费的余额，单位及有效期 | 等于 10 元现金、任意模型可用 |
| 每日免费调用 | 请求次数窗口及单次限制 | 可以兑换成余额，或无限重试 |
| 免费模型 | 精确模型 ID、渠道、功能与附加费用 | 同系列所有模型及工具都免费 |
| 会员免费试用 | 特定产品的限时访问权与续订约定 | 独立 API 账户也自动获得额度 |
例如，OpenRouter 的 Limits 文档把账户/密钥的消费额度与免费模型请求限制分开说明；免费变体使用 :free 后缀，存在分钟和每日次数限制。[1] 这不是“给任意模型一笔免费现金”。FAQ 也说明了免费模型和免费路由入口；自动选择免费模型的路由，不能替代对某个固定型号的质量验收。[2]
对于适用该计数限制的 OpenRouter 账户，文档列出的 free_model_daily_requests 包含已用、上限和剩余请求次数，窗口按 UTC 日；它不是现金余额，也不包含每分钟限额。[1] UTC 零点对应北京时间 08:00，不能想当然地等到本地零点就反复重试。其他平台的重置时间须另查，不沿用这个时区。
免费次数、剩余金额和可调用权限要分别记录。某个数大于零，只说明对应那一栏尚有余量，不保证下一条请求一定成功。
2. 把宣传语填成一张权益表
从已确认的服务商官网进入活动说明与控制台，保存规则链接和查阅日期。不要只保存搜索摘要或群聊中的“免费”二字。填写下表时，没有证据的项写“未确认”，不要默认为没有限制。
| 字段 | 应写到什么程度 |
|---|---|
| 归属与资格 | 哪个账户、工作区；注册、领取或首充是否是前提；后台是否实际到账 |
| 权益类型与单位 | 余额、请求次数或订阅；金额是否为站内单位；不可相互直接相加 |
| 生效与失效 | 起算事件、精确截止时间及时区；是绝对日期还是领取后若干天 |
| 适用范围 | 精确模型 ID、分组、接口和功能；网页试玩是否与 API 共用权益 |
| 消耗顺序 | 赠送与付费余额谁先扣；不足时是否允许拆分抵扣 |
| 排除项 | 搜索、文件处理、存储等实际启用的服务是否另收费或不参与抵扣 |
| 用尽后的行为 | 拒绝请求、改用付费余额、换模型，还是进入订阅收费阶段 |
官方一般条款、活动条款和你账户中的记录应一起核对。例如 OpenRouter FAQ 写明，平台保留对购买一年后未使用 credits 设置到期的权利。[2] 这不是“所有试用金统一一年有效”，也不代表后台一定精确在周年日自动清零；赠送权益必须查它自己的条件。
如果领取本身失败或奖励未到账，处理的是活动资格和入账问题。先用订单或领取记录定位，不要通过不断调用模型来“试出”权益。若已经到账却仍提示额度不足，转到账户、密钥与分组的额度排查，本篇不重复通用报错流程。
3. 分开关闭三条可能的付费路径
路径一：同一请求改扣付费余额。 试用金额不足、到期或不适用于目标模型后，平台可能拒绝，也可能按约定改扣钱包。先找资金来源设置、模型允许名单与服务端硬限制。客户端把模型写成“免费”只是选择配置，不能替代服务端的计费规则。
路径二：钱包低余额触发自动充值。 OpenRouter FAQ 明确区分手动充值与低于设定阈值后自动补充余额的 auto top up。[2] 如不希望试用带来新付款，应核对该设置、付款授权、待处理订单及关闭后的状态。关闭它不会自动撤销已经发生的消费或已受理付款。
路径三：试用订阅转为续费。 若活动属于订阅，查账单页的下一次收费日期、金额、取消期限及取消确认。API 钱包自动充值和订阅续费可能是不同开关，停用 API Key 也不能推定订阅已经取消。
另查客户端与网关的备用模型：免费路径失败时是否会改走付费路径。可参考自动模型回退的范围与验收。只想验证免费权益时，不要为提高成功率临时放开所有模型或启用未知备用渠道。
如果平台无法提供“禁止付费回退”的可核对限制，就不能把这次测试称为零付费风险。可以先完成文档和本地模拟检查；确需真实调用时，由使用者另行决定可接受的付费上限。不要把 Key 限额填成 0 就视作安全：有的界面用零表示禁用，有的实现可能另有语义，必须核对该平台说明及实际保存值。
4. 用分账记录验证抵扣，不用总余额猜顺序
下面采用完全虚构的规则：赠送余额 12 单位，付费余额 50 单位；赠送仅适用模型 A、截止前有效；先扣赠送，允许不足部分扣付费；每次合格请求最终费用固定为 8 单位。没有其他请求、附加费用、充值、退款或结算延迟。单位不是人民币、美元或真实报价。
| 场景 | 赠送余额变化 | 付费余额变化 | 能说明什么 |
|---|---|---|---|
| 截止前，模型 A 第一次请求 | 12 → 4 | 50 → 50 | 在本规则下，8 单位全由赠送抵扣 |
| 紧接着第二次相同请求 | 4 → 0 | 50 → 46 | 允许拆分时，4 单位转为付费消费 |
| 独立对照：从初始状态调用不适用的模型 B | 12 → 12 | 50 → 42 | 赠送尚未用完，仍可因范围不符而付费 |
| 独立对照：从初始状态等到赠送到期后调用 A | 12 先到期归零，调用时仍为 0 | 50 → 42 | 到期失效 12 与本次消费 8 是两笔事件 |
算例已在本地验证。若平台禁止付费回退，第二种场景不应直接套用这张表：在“必须全额覆盖才能受理”的假设规则下，应拒绝请求，保留赠送 4、付费 50。若平台支持部分生成、预扣或其他结算方式，结果仍需按其规则核验。
真实核对时，先暂停其他应用和自动重试，记录请求前的分项余额与时间，固定模型和分组，再在已确认授权与预算内执行一个最小任务。等待请求结算，按请求编号核对费用、抵扣来源、到期扣减和付费扣减。不要为了测到期，故意连续用光所有余额。
总余额减少不能独自证明“先扣赠送”：并行消费、到期清零和延迟结算都可能混在里面。账单不显示来源时，请服务商解释这一笔抵扣，不要用多次付费请求反推后台规则。计划试用需要多少预算，可另看按 Token 与调用次数估算首次预算。
5. 试用完成后，分别写下三种结论
先写权益结论：领取是否到账、哪些模型和功能适用、剩余量与失效时间、消费顺序是否有证据。再写功能结论：本次小任务是否完成，失败发生在哪一步。最后写费用结论：有没有付费消费、新充值或订阅订单，哪些账目仍待解释。
这三项不能互相替代。免费请求成功一次，不能证明正式付费渠道长期稳定；未看到银行卡扣款，也不能证明已有付费钱包没被消耗；免费余额还在，更不能证明它适用于下一次任务。
结束测试后停掉测试队列、撤销不再使用的临时 Key，复核自动充值、订阅状态和仍在途的请求。保存脱敏的规则、账户标识、时间及时区、模型与请求编号、分账变化和客服答复，不保存完整密钥。若资金来源或续费条件仍不明确，先不要扩大调用规模。
参考资料
- [1] OpenRouter：Credit Limits and Rate Limits：免费变体请求限制、UTC 日计数、账户与密钥消费限制的区分。
- [2] OpenRouter FAQ：免费模型入口、自动充值机制和购买 credits 的有效期说明。具体活动与账户适用条件需单独确认。