OpenClaw merged PR #151133, a runtime fix for prepared isolated completions that hit quota, rate-limit, or billing failures.
The bug affected tool-free background completions whose prepared authentication plan already included a healthy backup account. If the first account returned a quota-style failure as an assistant error-valued message, OpenClaw could accept that terminal-looking result before validating it and never try the backup profile.
What Users Get
After this change, completions using prepared profiles can recover through an eligible backup account when the first account fails with a returned quota, rate-limit, or billing error.
Explicit account selections still stay pinned. The PR is careful about that boundary: if a user or caller explicitly selected the first account, OpenClaw does not silently jump to a backup. The change also avoids cross-model fallback and does not add new profile planning to the separate host-only single-credential path.
In other words, the repair applies where the system already prepared a multi-profile plan and has authority to continue within it.
Why The Old Path Failed
The existing profile loop handled thrown failures, but the problematic case was a returned assistant message that represented an error. Because it was returned rather than thrown, it could be accepted before the loop classified it as recoverable.
PR #151133 moves classification into that loop, preserves the failure cause, and shares one inference budget across attempts. Before using another credential, OpenClaw rechecks caller authority and cancellation. Terminal output and tool-bearing output do not authorize replay.
That last constraint is subtle but important. Retrying an empty or rejected completion is one thing. Replaying after tool-bearing output would cross a very different safety boundary.
Verification
The PR includes a shipped-CLI proof using a registered plugin that calls the public host-prepared isolated completion route against a loopback OpenAI-compatible HTTP provider.
The reported scenarios are direct. On the old main path, the first account returned HTTP 429 with usage_limit_reached; OpenClaw made one request and returned a rejected completion without trying the backup. On the candidate path, the first account returned the same quota error, the backup account returned HTTP 200, and the caller received the expected recovered response.
The explicit-pin case still made only one request and did not use the backup. Focused verification covered 67 tests across isolated completion, resource ownership, prepared and native-auth contracts, cancellation, retired callers, shared deadlines, exhausted profiles, and terminal/tool-bearing output.
Why It Matters
Prepared profiles exist to give OpenClaw a controlled recovery path. If the runtime already knows a healthy backup is eligible, a returned quota error should not strand the completion on the first account.
PR #151133 makes that recovery path work without turning it into a loose fallback system. Authority is checked again, explicit pins are respected, and replay is limited to the safe class of failed isolated completions. That is the kind of boring precision provider-runtime code needs.