和普通的限流/超时不同，账单/信用额度类故障通常不是临时性问题——本文基于官方文档详解 OpenClaw 如何区分这类"大概率短期内不会自愈"的故障，以及对应的 Backoff 退避策略。
计费故障 vs 普通故障：处理方式不同
账单/额度类故障（例如"insufficient credits"/
"credit balance too low"）同样会触发故障切换，
但它们通常不是临时性的
因此 OpenClaw 不会给一个短暂的冷却时间，
而是直接把该 Profile 标记为"禁用"（disabled），
并使用更长的退避时间，然后轮换到下一个 Profile/Provider
这个设计逻辑很合理——如果账户余额不足，几分钟或几十分钟后大概率依然不足，用短冷却反复重试没有意义，不如直接标记禁用、用更长的退避周期，同时把流量导向其他可用的账号或模型。
状态记录格式
json
{
"usageStats": {
"provider:profile": {
"disabledUntil": 1736178000000,
"disabledReason": "billing"
}
}
}这个字段存储在 auth-profiles.json 中，disabledReason 明确标注了禁用原因是 "billing"，方便排查时快速定位——如果你发现某个账号突然停止被使用，检查这个字段能立刻知道是不是余额问题，而不用去猜测。
默认退避参数
计费退避从 5 小时起步，每次计费故障翻倍，
最高封顶 24 小时
如果一个 Profile 连续 24 小时没有再次失败，
退避计数器会重置（可配置）
"过载"（Overloaded）类重试允许 1 次同 Provider 内的
Profile 轮换，然后才会走 Model 降级
过载重试默认使用 0 毫秒退避（即立即重试）
对比一下三类故障的处理力度差异会更直观：
故障类型 初始退避 增长方式 典型场景
认证/限流错误 1分钟 指数递增至1小时封顶 临时性限流
过载错误 0毫秒 - 短暂过载,立即重试
计费/额度错误 5小时 翻倍至24小时封顶 余额不足,长期问题
可以看到官方对这三类故障的处理力度是刻意分层的——计费问题给最长的退避周期，因为它最不可能在短时间内自然恢复；过载问题给最短的退避，因为这类错误往往转瞬即逝。
Model 降级的触发条件
如果一个 Provider 下所有 Profile 都失败了，OpenClaw 会
切换到 agents.defaults.model.fallbacks 中配置的下一个模型
适用场景：认证失败、限流、以及耗尽了 Profile 轮换次数的超时
（其他类型的错误不会推进降级流程）
过载和限流错误的处理比计费冷却更激进——
默认情况下，OpenClaw 允许 1 次同 Provider 的
Auth Profile 重试，然后直接切换到下一个已配置的
Model 降级，不需要等待
可调优参数：
auth.cooldowns.overloadedProfileRotations
auth.cooldowns.overloadedBackoffMs
auth.cooldowns.rateLimitedProfileRotations
有模型覆盖时的降级终点
当一次运行以模型覆盖（Hook 或 CLI 指定）开始时，
降级流程在尝试完所有配置的 fallback 之后，
最终会落到 agents.defaults.model.primary
这意味着即便你临时用 Hook 或命令行强制指定了某个模型，一旦这个模型和它的所有 fallback 都失败了，系统最终还是会兜底回到配置文件里定义的主模型，而不是彻底失败退出。
相关配置项一览
auth.profiles / auth.order
auth.cooldowns.billingBackoffHours
auth.cooldowns.billingBackoffHoursByProvider
auth.cooldowns.billingMaxHours
auth.cooldowns.failureWindowHours
auth.cooldowns.overloadedProfileRotations
auth.cooldowns.overloadedBackoffMs
auth.cooldowns.rateLimitedProfileRotations
agents.defaults.model.primary / agents.defaults.model.fallbacks
agents.defaults.imageModel 路由
实战建议
1. 多账号部署时，为每个 Provider 至少准备一个备用账号，
避免单账号余额耗尽导致整条 Provider 直接不可用
2. 排查"某账号突然不被使用"问题时，先查
auth-profiles.json 里的 disabledReason 字段，
billing 原因和限流/超时原因的处理方式完全不同
3. 如果对某个 Provider 的计费退避周期不满意（比如账户
实际恢复更快或更慢），用
auth.cooldowns.billingBackoffHoursByProvider
针对该 Provider 单独调整，而不是改全局默认值
4. 配置好 model.fallbacks 是应对"整个 Provider 都不可用"
这种极端场景的最后一道防线，生产环境建议不要留空
总结
计费类故障和普通的限流/超时故障在 OpenClaw 里被刻意区分对待——前者用更长的退避周期承认"这大概率不是短期问题"，后者用短退避快速重试。理解这套分层设计，能帮你更快定位"为什么这个账号突然不干活了"这类生产问题，也能指导你为多账号部署配置更合理的退避参数。
来源：Model Failover - Billing Disables — OpenClaw 官方文档