Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The /models slash command and openclaw models list CLI take 3-4 seconds to respond in v2026.6.1 with ~60 configured models across ~12 providers, compared to near-instant response in v2026.5.27. The --all flag takes 10+ seconds.

Steps to reproduce

1. Configure ~60 models across ~12 providers (xiaomi, alibaba, deepseek, volcengine, handai, minimax, google, claude-cli, freemodel, etc.) with agents.defaults.models using provider-wide provider/* entries.
2. Upgrade from v2026.5.27 to v2026.6.1.
3. Run time openclaw models list — observe ~3.4s response time.
4. Run time openclaw models list --all — observe ~10.8s response time.
5. Compare with v2026.5.27 where the same command responds in under 1 second.

Expected behavior

/models default view should respond in under 1 second for typical configurations with fewer than 100 models, consistent with v2026.5.27 behavior.

Actual behavior

openclaw models list takes 3.4s (default), 4.5s (--plain), 5.0s (--json), and 10.8s (--all). The /models slash command in webchat exhibits the same latency. The delay appears to come from provider catalog discovery and model metadata loading happening synchronously on the request path.

OpenClaw version

2026.6.1 (2e08f0f)

Operating system

Linux 6.6.87.2-microsoft-standard-WSL2 (x64)

Install method

npm global

Model

xiaomi/mimo-v2.5

Provider / routing chain

openclaw -> xiaomi/mimo-v2.5 (primary), deepseek/deepseek-v4-flash, alibaba/deepseek-v4-flash (fallbacks)

Additional provider/model setup details

Benchmark results on v2026.6.1:

$ time openclaw models list
3.40s total, 60+ models returned

$ time openclaw models list --all
10.84s total, 100+ models (includes unauthenticated providers)

$ time openclaw models list --json
4.99s total

$ time openclaw models list --plain
4.45s total

Providers configured: xiaomi, alibaba, deepseek, volcengine, handai, minimax, minimax-portal, volcengine-plan, google, claude-cli, freemodel, tencent, zai (~12 providers).

agents.defaults.models uses provider-wide entries like "xiaomi/*": {}, "alibaba/*": {} etc.

Logs, screenshots, and evidence

Impact and severity

Affected: All users with multi-provider model configurations using /models slash command or openclaw models list CLI.
Severity: Annoying (degraded UX, not a workflow blocker).
Frequency: 100% reproducible.
Consequence: 3-10s wait every time the model list is requested; noticeably slower than v2026.5.27.

Additional information

Regression range: last known good v2026.5.27, first known bad v2026.6.1.

Related issues:

• [Performance] Model Picker UI very slow in v2026.5.28 #90403 — same symptom reported in v2026.5.28, still open
• [Bug]: Provider-qualified default model resolution eagerly builds alias index and can block gateway event loop ~80s #86635 — alias index blocking event loop (~80s with 97 models), closed in v2026.5.27

v2026.6.1 changelog notes that may contribute:

• Added MiniMax M3 model support and more catalog rows (feat(minimax): add MiniMax M3 support #88860)
• OpenRouter SQLite model caching (Google Gemini chat model routes to openai-responses transport (401), native @google/genai transport never selected #88480)
• Google/Vertex catalog fixes (fix: resolve google provider default API to google-generative-ai #88512)
• models list now falls back to synthetic rows "after a short wait" then discovers in background

The delay likely comes from increased model metadata volume and provider catalog enumeration happening synchronously on the listing path. Consider lazy-loading catalog metadata (only on --all or provider filter), caching the default list between invocations, and avoiding full alias index builds for simple list requests.