openclaw - 💡(How to fix) Fix [Bug]: Google provider models fall to 200k context fallback due to empty discovery cache [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

All Gemini models resolve to a 200k context window instead of their actual 1,048,576 token limit because the Google extension does not register a provider catalog, leaving models.json empty for Google and causing resolveContextTokensForModel() to fall through to DEFAULT_CONTEXT_TOKENS (200,000).

Steps to reproduce

1. Configure a Google provider with GEMINI_API_KEY (no explicit contextWindow in config).
2. Start an agent session using google/gemini-3.1-pro-preview.
3. Run /status or check session context token limit.
4. Observe context limit reported as ~200k instead of ~1M.
5. Confirm by checking ~/.openclaw/agents/<agentId>/agent/models.json — no google provider entry exists.

Expected behavior

Gemini models should report a context window of 1,048,576 tokens, matching the Google API's inputTokenLimit for Gemini 3.x models. Other provider extensions (anthropic-vertex, openrouter, mistral, minimax) correctly populate the discovery cache via their provider-catalog.ts files.

Actual behavior

All Gemini models report a ~200k context window. Sessions compact at 160-180k instead of the available ~900k. The discovery cache (models.json) contains no Google provider entries. The resolution chain in resolveContextTokensForModel() (src/agents/context.ts) exhausts all lookup paths and falls through to fallbackContextTokens, which defaults to DEFAULT_CONTEXT_TOKENS = 200_000 (src/agents/defaults.ts).

OpenClaw version

2026.4.2

Operating system

macOS 15.4

Install method

npm global / pnpm dev

Model

google/gemini-3.1-pro-preview

Provider / routing chain

openclaw -> google (direct API key)

Additional provider/model setup details

Google provider configured via GEMINI_API_KEY environment variable. No explicit contextWindow override in openclaw.json models.providers.google. Agent uses google/gemini-3.1-pro-preview as primary model.

Logs, screenshots, and evidence

# Discovery cache shows no Google provider entry:
$ cat ~/.openclaw/agents/<agentId>/agent/models.json | jq '.providers | keys'
["ollama", "openai-codex"]
# Google is absent despite being configured and functional.

# Google API confirms 1M context support:
# gemini-3.1-pro-preview inputTokenLimit: 1048576

# Resolution chain (src/agents/context.ts):
# 1. contextTokensOverride -> not set
# 2. context1m param -> Anthropic-only, skipped
# 3. resolveConfiguredProviderContextWindow -> no explicit config entry
# 4. lookupContextTokens (discovery cache) -> no Google entry in models.json
# 5. fallbackContextTokens -> DEFAULT_CONTEXT_TOKENS = 200_000  <-- lands here

# Root cause: extensions/google/index.ts registers resolveDynamicModel
# and other runtime hooks but no catalog. Compare with extensions that
# work correctly (e.g., extensions/minimax/index.ts which registers catalog).

Impact and severity

• Affected: All users of Google Gemini models via API key or Gemini CLI OAuth
• Severity: Medium — sessions work but waste ~80% of available context
• Frequency: Always (100% of Gemini sessions without explicit config workaround)
• Consequence: Premature context compaction at 160-180k instead of ~900k; reduced session continuity and quality for long conversations

Additional information

Workaround: Add explicit contextWindow to the model config in openclaw.json:

{
  "models": {
    "providers": {
      "google": {
        "models": [
          { "id": "gemini-3.1-pro-preview", "contextWindow": 1048576 }
        ]
      }
    }
  }
}

This works because resolveConfiguredProviderContextWindow() (step 3 in the resolution chain) fires before the discovery cache lookup. However, it requires manually listing every Google model used and does not scale.

Proposed fix direction: Add extensions/google/provider-catalog.ts following the established pattern used by all other provider extensions (minimax, openrouter, anthropic-vertex, mistral, etc.). This would populate the discovery cache at startup with correct contextWindow values for known Gemini models. The existing resolveDynamicModel forward-compat resolver would continue handling unknown future model IDs at runtime.