API key profile
像普通钥匙，拿 key 直接开门。
Concepts 导读
模型请求失败后，OpenClaw 如何自动切换？
OpenClaw 的故障处理分两层：先在同一 provider 内轮换 auth profile，再按 `fallbacks` 列表降级到下一个模型。最容易搞错的是：降级时只持久化模型选择字段，不会保存整个 session；另外，auth profile 的轮换顺序默认按类型（OAuth 优先于 API key）和最后使用时间排序，而非配置顺序。
先讲这一页到底在解决什么
模型请求失败后，OpenClaw 如何自动切换？
OpenClaw 的故障处理分两层：先在同一 provider 内轮换 auth profile，再按 `fallbacks` 列表降级到下一个模型。最容易搞错的是：降级时只持久化模型选择字段，不会保存整个 session；另外，auth profile 的轮换顺序默认按类型（OAuth 优先于 API key）和最后使用时间排序，而非配置顺序。
第一站
🗝️ 同一个 provider 下面可以有多把钥匙，OpenClaw 会先试着换钥匙
这里的钥匙就是 auth profile，既可能是 API key，也可能是 OAuth 登录。
OAuth profile
像带时效的通行证，能和 API key 并存。
auth-profiles.json
像钥匙盒，真正的秘密材料都放这里，不放在公开配置说明里。
Profile ID
像钥匙标签，例如 provider:default 或 provider:user@example.com。
第二站
🔄 轮换顺序不是乱抽签，而是先看你有没有手工指定，再看系统排班
所以“为什么它这次换到另一把钥匙”通常是有规则可追的。
auth.order[provider]这像你手写的优先排班表。写了它，系统先听你的。
Round-robin
没手写排班时，系统会自己轮换。官方还偏向 OAuth 先于 API key，然后再看谁最近更少被用。
Cooldown / disabled
这些像“暂时休息的钥匙”，会被排到队伍后面，不会先推上去挡枪。
Fallback models
如果同 provider 的钥匙都不行，才轮到下一扇备用模型门出场。
第三站
📌 Session stickiness 像“这段对话先用同一把钥匙”，别每句话都换门卫
这能保缓存，也让同一会话更稳定。
自动锁定
一旦系统为当前会话挑了一把钥匙，会尽量一直用它，直到重置、压缩后重开、或这把钥匙进冷却。
/model …@<profileId>这像你亲手指定“这次就用这把”。手动钉住后，系统不会随便帮你换成别的 profile。
为什么 OAuth 像丢了
如果你同时有 OAuth 和 API key，而又没锁定，会轮换，看上去就像“刚刚那个登录怎么不见了”。
🎈 最后记一句
Failover 的路线是：先换同门钥匙，再换备用模型门，不是上来就满场乱跑。