openclaw - 💡(How to fix) Fix Timeouts should mark auth profiles as failed to trigger faster model fallback [1 comments, 2 participants]

Problem

When the primary model provider times out (e.g. OpenAI Codex outage), the failover loop retries for the entire agents.defaults.timeoutSeconds budget (default 600s) before falling back — even though the provider is clearly down.

Root cause: In the model selection loop, timeouts are explicitly excluded from marking profile failures:

// model-selection-CU2b7bN6.js
const maybeMarkAuthProfileFailure = async (failure) => {
    const { profileId, reason } = failure;
    if (!profileId || !reason || reason === "timeout") return; // ← timeouts skipped
    ...
};

Because timed-out profiles never enter cooldown, advanceAuthProfile() keeps cycling through them as "available". The loop only terminates when runLoopIterations hits the hardcoded cap:

const BASE_RUN_RETRY_ITERATIONS = 24;
const RUN_RETRY_ITERATIONS_PER_PROFILE = 8;  // 24 + N*8 iterations
const MIN_RUN_RETRY_ITERATIONS = 32;
const MAX_RUN_RETRY_ITERATIONS = 160;

With 3 profiles: 24 + 3×8 = 48 max iterations, each burning ~60s on a timeout = potentially 48 minutes of useless retries (capped only by the 600s turn timeout).

Observed behavior

OpenClaw v2026.3.13, Anna agent with openai-codex/gpt-5.4 primary and 3 OAuth profiles:

12:44:27 embedded run agent end: isError=true error=LLM request timed out.
12:45:20 embedded run agent end: isError=true error=LLM request timed out.
12:46:17 failover decision: decision=rotate_profile reason=timeout
12:47:06 embedded run agent end: isError=true error=LLM request timed out.
12:47:57 embedded run agent end: isError=true error=LLM request timed out.
12:48:50 embedded run agent end: isError=true error=LLM request timed out.
12:49:47 failover decision: decision=rotate_profile reason=timeout
12:50:35 embedded run agent end: isError=true error=LLM request timed out.
12:51:26 embedded run agent end: isError=true error=LLM request timed out.
12:52:19 embedded run agent end: isError=true error=LLM request timed out.
12:53:16 failover decision: decision=fallback_model  ← finally, after ~10 min
12:53:36 model fallback: candidate=anthropic/claude-sonnet-4-6 → succeeded in 20s

Proposal

One or more of these would fix the issue:

1. Count consecutive timeouts toward profile cooldown — e.g. after 2 consecutive timeouts on a profile, put it in short cooldown (30-60s). This lets the system exhaust all profiles faster and reach fallback_model sooner.

2. Add a configurable model.maxFailoverSeconds — a separate timeout that caps the total time spent retrying the primary provider before falling back, independent of agents.defaults.timeoutSeconds (which also covers legitimate long-running turns like deep research via subagents).

3. Add model.maxRetriesBeforeFallback — explicit cap on how many times the primary model is retried before escalating to the fallback chain.

4. Per-agent timeoutSeconds — allow individual agents to have different timeout budgets, so a chat agent can have 120s while a research agent keeps 900s.

Why agents.defaults.timeoutSeconds alone doesn't solve this

Lowering the global timeout would also kill legitimate long-running turns (e.g. subagent deep research that takes 15+ minutes). There's no per-agent override, so you can't set a short timeout for the chat agent without breaking the research agent.

Related issues

• #45589 — same 10-min unresponsiveness symptom (Discord + Gemini)
• #32533 — failover doesn't escalate on overload errors
• #36576 — retry with backoff for transient provider errors