openclaw - 💡(How to fix) Fix Bug: Model failover not working when primary model hits billing error

Environment

• OpenClaw version: 2026.5.12
• Config:

  "agents": {
    "defaults": {
      "model": {
        "primary": "deepseek/deepseek-v4-pro",
        "fallbacks": ["minimax/minimax-M2.7"]
      }
    }
  }

Problem

When sessions_send is called, if the primary model (deepseek/v4-pro) returns a billing error (402 insufficient credits), the failover mechanism does not proceed to the fallback model (minimax/minimax-M2.7). Instead, the operation throws a FailoverError:

FailoverError: deepseek (deepseek-v4-flash) returned a billing error — your API key has run out of credits

Expected Behavior

According to the Model Failover documentation, when a provider is exhausted with a failover-worthy error, OpenClaw should move to the next model candidate in agents.defaults.model.fallbacks.

Expected chain:

deepseek/v4-pro (billing error) → deepseek/v4-flash (same provider) → minimax/M2.7 (fallback)

But instead, the entire operation fails with FailoverError without ever attempting minimax.

Analysis

1. Billing backoff starts at 5 hours and grows exponentially, capping at 24 hours
2. Billing errors disable the auth profile, not just the specific model
3. deepseek/v4-pro and deepseek/v4-flash share the deepseek:default auth profile
4. When billing error occurs, the entire deepseek provider is disabled

The issue appears to be that the billing error triggers a provider-wide auth profile disable that blocks the entire failover chain from proceeding to the next provider (minimax).

Questions

1. Is it intended behavior that a billing error on one model prevents the fallback chain from trying models from other providers?
2. Should the failover mechanism distinguish between "this model/provider is disabled" vs "try a completely different provider as fallback"?
3. Is there a configuration option to make billing errors use short retry cooldown instead of long billing disable?

Impact

• Users with a billing-disabled primary model cannot send messages via sessions_send even when a working fallback model is configured
• The configured fallback chain is ineffective as a resilience mechanism

Thank you for investigating.