openclaw - 💡(How to fix) Fix Feature request: surface auth profile-rotation settings (auth.cooldowns.*) in the UI / configure wizard [1 comments, 2 participants]

Summary

OpenClaw already implements per-provider auth-profile rotation under auth.cooldowns.rateLimitedProfileRotations and auth.cooldowns.overloadedProfileRotations (both default 1). The runtime correctly tracks per-profile cooldown state in auth-state.json under usageStats.<profile>.cooldownUntil / cooldownReason, and the embedded provider runtime (pi-embedded) honors the configured rotation limit before escalating to model fallback.

What's missing is UI/UX exposure. Users have to either (a) hand-edit openclaw.json and know these specific keys exist, or (b) hit a rate-limit, observe the fallback fire, and grep the source to figure out why their second OpenAI Codex profile didn't get tried.

What I'd like to see

In the openclaw configure wizard and/or the dashboard settings screen:

1. Profile rotation count — a numeric picker for rateLimitedProfileRotations and overloadedProfileRotations, with the per-provider profile count alongside (so the user sees "You have 2 openai-codex profiles registered; rotation limit set to 1 — bump to 2 to try both before falling back").
2. Per-profile cooldown indicators in the auth/profiles screen — surface usageStats[<profile>].cooldownUntil and cooldownReason next to each profile, so users can see "[email protected] — rate-limited until 22:33 EDT" without opening the JSON.
3. "Clear cooldown" button per profile (mirrors what users currently have to do by editing auth-state.json or restarting the gateway).
4. Inline help for each rotation knob explaining the cascade order: same-provider profile rotation up to N times → next entry in agents.defaults.model.fallbacks → next provider entry.

Why this matters

The pattern of "two OpenAI accounts to extend usable Codex runtime" is now common (Codex CLI / VS Code Codex extension / OpenClaw / Hermes side-by-side, with weekly-quota plans). Users who add a second profile through the model wizard reasonably expect it to be USED on rate-limit, but the rotation limit defaulting to 1 means a third or fourth profile (if added later) is silently skipped. There's no signal in the UI to indicate this.

Also related to the cascade-failure incident filed at #80040 — last night during my own incident, both my profiles ended up cooling down within minutes of each other, and the rotation logic correctly tried to advance, exhausted, and escalated to fallback. But the UX during the failure was opaque: I had to read trajectory diagnostics + auth-state.json to see why. Surfacing rotation/cooldown state in the UI would have shortened that diagnostic loop substantially.

Environment

• OpenClaw 2026.5.7 (gitSha b8fe34a)
• Code references: runtime-schema-OL6hE5dN.js (auth.cooldowns.rateLimitedProfileRotations, auth.cooldowns.overloadedProfileRotations), pi-embedded-Bcz04p2i.js (overloadProfileRotationLimit, rateLimitProfileRotationLimit, advanceAuthProfile, maybeEscalateRateLimitProfileFallback)

Related

• #80040 — original cascade-failure report; the auth-rotation cascade fired correctly during that incident, just without UI visibility
• Filed in parallel to NousResearch/hermes-agent#22916 — same UI-exposure ask for Hermes's credential_pool_strategies (which already exists at the config level)