免费额度用完即停

很多人第一次用免费额度跑 Demo，跑着跑着就忘了限额这件事——结果要么请求开始报错、任务中断，要么后台悄悄从余额里扣钱。这篇不堆数字，只讲两种停机逻辑的差别、动手前要确认的几项设置，以及一份可以照着走的排查顺序，帮你把「额度用尽」这件事变成可控状态。

很多人第一次用免费额度跑 Demo，跑着跑着就忘了限额这回事——结果要么请求开始报错、任务当场中断，要么后台悄悄从余额里扣钱。这篇不堆数字，只讲两种停机逻辑的差别、动手前要确认的设置，以及一份能照着走的排查顺序，帮你把「额度用尽」这件事变成可控状态。

先明确一点：停机机制不是平台通用标准，同一个厂商的网页版、API、编程客户端，甚至经过第三方中转，行为都可能不一样。所以下面的判断标准都要落到你自己那一路入口上去核对，别拿一个入口的经验套另一个。

先分清两种停法：硬停和降级

硬停指的是额度归零后请求直接被拒，返回配额类错误，任务当场断掉，不再产生任何费用；降级指的是额度用尽后系统自动转成付费档、按量计费，或者切到慢速、低优先队列，表面还能用，但要么开始烧钱要么明显变慢。这两种体验差异很大，判断错了后面每一步都会走偏。

判断标准很简单：先去后台看计费模式那一栏写的是什么。写「订阅含额度」的，通常硬停，用起来心理负担小；写「按量计费」的，基本就是降级，哪怕标了免费额度，也要按「随时会转付费」来对待。

• 硬停：额度归零请求直接被拒，任务断掉，不产生费用，适合拿来试水的账号
• 降级：额度用尽自动转付费档、按量计费或慢速队列，能用但开始烧钱或变慢
• 同一平台不同入口（网页版、API、客户端、中转）停法可能不一样，要分别确认
• 核心判断标准：看后台计费模式写的是「订阅含额度」还是「按量计费」，前者通常硬停，后者基本降级

用之前先做四件事，花五分钟

这四件事的价值在于把「事后补救」变成「事前设定」。多数意外账单不是平台偷偷扣的，而是默认开关一直是开着的，用户没去看。动手前逐条过一遍，后面就能睡个安稳觉。

1. 确认额度单位与重置规则在后台的用量或配额页，看清免费额度是按 token、按次数还是按时间窗计算，以及时间窗多久重置一次。重置规则直接影响你的排期，别默认「每月一号清零」。
2. 检查自动扣费开关找到「自动充值」「余额不足自动升级」「超额继续调用」这类选项，确认它是关的。不要假设它默认关闭，很多平台默认是开的。
3. 设一个用量告警阈值把告警定在额度的七八成位置，给自己留出反应时间。只靠肉眼盯用量，批量任务一跑起来根本来不及。
4. 确认中转渠道的计费口径如果走的是中转站，先在其平台页面上看清计费方式与限速说明，再动手接线。渠道规则和官方口径常常不一样，参考时要认准渠道自己的说明。

这四步做完，你对「会不会被扣钱」这个问题基本就有答案了。拿不准具体额度数字和档位，可以到 /price-watch价格追踪 核对当时的数字，但判断逻辑还是上面那套。

额度真用完之后，实际会看到什么

最常见的表现是请求返回配额或欠费类错误码，或者客户端直接提示额度不足并停止本次任务。麻烦在于，这类报错经常被误判成「网络问题」或「模型挂了」，于是有人开始反复重试、换节点，白白浪费时间。

正确的第一步永远是先查错误码和后台余额，排除额度因素，再去查网络和链路。顺序反了，排查时间会翻好几倍。批量任务和长链路 Agent 还要特别注意：中断可能发生在中途，已经产生的部分费用照常计，不会因为你没跑完就免掉。

被停机之后怎么接上，顺序别乱

恢复的顺序比恢复的手段更重要。先分清是额度耗尽还是被限速卡住——限速场景下直接重发只会让情况更糟，而额度耗尽重发多少次也没用。判断清楚之后再决定下一步动作。

• 先确认是额度耗尽还是限速被卡，这两件事处理方式完全不同，别直接重发
• 按成本和交接难度排序接续手段：换同平台另一个入口、切到别的模型、或改用自备 API
• 给长任务脚本加一层前置检查：开跑前先读一次余额或额度，剩余低于阈值就不启动
• 把这次中断记进用量日志，下次估算消耗速度时有依据

# 长任务开跑前的前置检查示例（伪代码）
# 读取当前剩余额度，低于阈值就退出
remain=$(check_quota)
if [ "$remain" -lt "$THRESHOLD" ]; then
  echo "额度不足，跳过本次任务"
  exit 1
fi
run_task

这段检查的意义是把「跑到一半断掉」变成「开跑前就知道跑不了」。前者会浪费已消耗的部分，后者最多浪费一次判断。具体阈值怎么定，取决于你任务的单次消耗量，可以先跑一次小规模任务量一下。

这套办法什么时候不适用

前面讲的都建立在「后台开关决定一切」这个前提上，但有几类情况不成立，硬套会得出错误结论。

• 企业合同、预留算力、包年订阅走的是合同结算，超额处理方式由协议约定，不由后台开关决定
• 聚合平台和中转渠道的规则由渠道自己定，和官方口径可能不同，参考时要认准渠道自己的说明
• 已经开着的自动续费想靠调开关止损，只能减少后续扣费，已经产生的部分一般不能退回
• 面向团队的共享账号，额度归属和扣费主体可能和你以为的不一样，动手前先确认账号谁在管

所以这套排查顺序适合个人开发者和自助注册的小团队账号；一旦涉及合同、共享账号或中转渠道，正确做法是直接问渠道或管理方，而不是照着自助后台的开关去推。哪些中转渠道的计费口径写得清楚，可以到 /sites站点导航 对照着看。