Summary

When google/gemini-3.1-pro-preview returns 429 RESOURCE_EXHAUSTED due to the monthly billing-account spending cap, OpenClaw's failover ladder retries google/gemini-2.5-flash and google/gemini-2.5-pro even though all three Gemini models share the same Google billing account and therefore the same cap. Each sibling model's attempt produces additional RESOURCE_EXHAUSTED lines for a billing condition that is structurally guaranteed not to recover by switching siblings.

In a real-world cascade I observed across a 7-day window, this produced 15 RESOURCE_EXHAUSTED lines per failed run, repeated across 26 distinct runs over ~10 hours, for a total of ~390 cascade-amplified events from a single billing condition. The actual primary failover target — OpenAI — would have had a chance to handle the conversation if it weren't for a separate replay bug (filed separately).

Reproduction

1. Configure two or more Gemini models from the same billing account in the failover chain. Example:

   model_stack:
     - google/gemini-3.1-pro-preview
     - openai/gpt-5.4
     - google/gemini-2.5-flash
     - google/gemini-2.5-pro

2. Trigger sustained traffic that pushes the Google billing account past its monthly spending cap.
3. Observe failover ladder behavior in the gateway journal.

Observed

Embedded agent failed before reply: All models failed (4):
  google/gemini-3.1-pro-preview: 429 RESOURCE_EXHAUSTED [monthly spending cap] (rate_limit) |
  openai/gpt-5.4:                <separate format error, see related issue> |
  google/gemini-2.5-flash:       429 RESOURCE_EXHAUSTED [monthly spending cap] (rate_limit) |
  google/gemini-2.5-pro:         429 RESOURCE_EXHAUSTED [monthly spending cap] (rate_limit)

Failover decisions for all three Gemini siblings carry reason=rate_limit despite the underlying error being RESOURCE_EXHAUSTED + "monthly spending cap" (a separate classification issue worth tracking on its own; see PR #74120 for in-flight billing classification work that targets LiteLLM-style budget errors but doesn't yet cover Google's native shape).

Expected

The failover ladder should be aware of billing-account scope: when one model on a billing account hits a cap, sibling models on the same billing account should be considered "same failure class" and skipped without contacting the API. Possible shapes:

• A billingAccount field on each provider entry (default = inferred from provider+account-id), with a "skip same-billing-account siblings on RESOURCE_EXHAUSTED / billing-class errors" policy.
• A simpler heuristic: when a model returns a billing-class error (after PR #74120 ships native Google classification), set a short-lived provider+account cooldown that suppresses sibling attempts for the rest of the run and a host-level cooldown of N minutes (overlaps PR #64127's circuit breaker work).

Why filing

This is a defect-class bug — the failover ladder produces guaranteed-to-fail attempts whose only effect is journal noise and (transient, until cap kicks in) extra API hits. It's adjacent to but distinct from:

• PR #64127 (provider circuit breaker for quota exhaustion) — host-level circuit breaker; would suppress runs but not the within-run sibling attempts.
• PR #78086 (state-aware failover and lane suspension) — session-level suspension; same scope concern.
• PR #74120 (classify budget-exceeded as billing) — fixes classification of LiteLLM proxy errors; doesn't address sibling scope.

None of these address the structural "siblings share billing account" insight, hence this issue.