[Bug]: Default fallback chain includes models that fail the minimum context-window check, making them effectively unusable

[perlowja]

Summary

The default agents.defaults.model.fallbacks chain ships with google/gemma-4-31b-it (contextWindow: 8192 per modelsConfig), but the agent enforces a minimum of 16000 tokens before it will use a model. So when fallback fires (e.g. primary returns 429 RESOURCE_EXHAUSTED), the chain advances to gemma-4-31b-it which is immediately rejected, the entire chain exhausts, and the user sees a generic All models failed error with no usable recovery.

Reproduction

Easy on any container with the default config when the primary key is rate-limited:

$ docker exec openclaw-demo-typhon openclaw agent --to "+177..." --message "Show me my holdings" --timeout 90
[model-fallback/decision] decision=candidate_failed requested=google/gemini-flash-latest \
  candidate=google/gemini-flash-latest reason=rate_limit \
  next=google/gemma-4-31b-it \
  detail=Resource has been exhausted (...). RESOURCE_EXHAUSTED

[agent/embedded] low context window: google/gemma-4-31b-it ctx=8192 (warn<32000) source=modelsConfig
[agent/embedded] blocked model (context window too small): google/gemma-4-31b-it ctx=8192 (min=16000) source=modelsConfig

[model-fallback/decision] decision=candidate_failed requested=google/gemini-flash-latest \
  candidate=google/gemma-4-31b-it reason=unknown \
  next=none \
  detail=Model context window too small (8192 tokens; source=modelsConfig). Minimum is 16000.

FallbackSummaryError: All models failed (2): ...

So the user-visible behavior on hitting the primary rate limit is the agent dying immediately rather than recovering on the configured fallback.

Why this matters

The fallback chain's purpose is to absorb provider failures. Right now the default chain has a single fallback (gemma-4-31b-it) that can't absorb anything because of the ctx-window enforcement. Effectively the agent has no fallback at all — and the configured fallback creates a misleading log trail that obscures the real root cause (the primary's rate-limit error gets buried two levels down in the FallbackSummaryError aggregate).

Suggested fix (any of)

1. Filter the default fallback chain at config-load time: drop any model whose contextWindow is below the agent's enforced minimum, with a clear log line so operators know.
2. Replace gemma-4-31b-it with a fallback that has ≥16000 ctx in the shipped default (groq/llama-3.3-70b-versatile is already a configured provider in the same default config and has 131K context — would be a drop-in).
3. Soften the minimum to match the smallest-ctx model in the default chain, with a per-call check that skips ctx-bound prompts to that model.

(2) is probably cleanest for ergonomics; (1) is the most defensible / future-proof.

Adjacent

• Feature: Trigger model fallback on context length exceeded #9986 covers the triggering of fallback on context overflow — this issue is about executability of an already-triggered fallback, so they're complementary.
• [Bug]: Session file lock errors cascade through model fallback chain #66646 is the session-lock cascade I just commented on — when both this and [Bug]: Session file lock errors cascade through model fallback chain #66646 happen on the same call, the user-visible error is genuinely confusing because both contribute to the FallbackSummaryError without either being the root cause.

Versions

• openclaw-demo:latest container, OpenClaw 2026.4.24
• Default config shipped with the container (no operator override)

[clawsweeper]

Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Current main no longer ships the reported unusable default fallback chain. The Google onboarding/default path now writes only google/gemini-3.1-pro-preview as the primary model, with tests asserting that shape, while the 16k context-window guard remains in place. The same default is present in the v2026.4.26 release tag, newer than the reported 2026.4.24 environment.

Best possible solution:

Close this as implemented for current main and v2026.4.26. Keep the current Google default behavior; if maintainers want automatic cleanup of already-persisted 2026.4.24 configs, track that separately as a narrow doctor/migration follow-up.

What I checked:

• Google default model implementation: applyGoogleGeminiModelDefault sets the Google default to google/gemini-3.1-pro-preview through the provider onboarding helper; it does not add google/gemma-4-31b-it or any fallback list. (extensions/google/onboard.ts:6, 7120f5b25487)
• Regression coverage for default shape: The Google default-model test asserts that an unset config becomes { primary: GOOGLE_GEMINI_DEFAULT_MODEL }, with no fallback array in the expected value. (extensions/google/default-model.test.ts:6, 7120f5b25487)
• Context-window guard still enforces the reported minimum: The embedded runner still blocks models below the 16,000-token hard minimum, so the current fix is that the shipped default no longer points fallback at an 8k-context model. (src/agents/context-window-guard.ts:5, 7120f5b25487)
• Release tag contains the fixed default: The v2026.4.26 tag already contains the same Google default implementation and test expectation, so the fixed default shipped after the reported 2026.4.24 version. (extensions/google/onboard.ts:6, be8c24633aaa)
• No current shipped default references the bad fallback: An exact search for gemma-4-31b-it on current main found only model parsing/compatibility tests and comments, not the Google onboarding/default config path or docs for shipped defaults. (7120f5b25487)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 7120f5b25487; fix evidence: release v2026.4.26, commit be8c24633aaa.

[perlowja]

Thanks @clawsweeper — verified independently against ghcr.io/openclaw/openclaw:2026.4.26. The Google default no longer ships gemma-4-31b-it in the fallback chain (per extensions/google/onboard.ts + the extensions/google/default-model.test.ts regression coverage), and the 16k context-window guard in src/agents/context-window-guard.ts remains. Original issue rationale and current behavior both confirmed; closure is correct.

(Heads-up for the maintainer thread: separately filed a 4.26 image-side packaging regression on the xai + browser extensions' typebox bundles — different surface, just noting for cross-link.)