openclaw - 💡(How to fix) Fix Slow /models command with LiteLLM model catalog appears to use full catalog refresh path [1 pull requests]

Summary

/models is very slow when OpenClaw is configured with a LiteLLM provider that exposes many models. This does not appear to be container-specific: I have observed the same behavior on a host install and inside a Fedora-based container. I am not 100% certain about the exact root cause yet, but the measurements below point to the /models command path using the heavy/full model catalog path instead of the fast read-only/catalog-cached path.

This has been happening for a while, and I also see it when models.mode is merge.

Environment

• OpenClaw package version: 2026.5.18
• Provider: LiteLLM/OpenAI-compatible endpoint
• Configured LiteLLM models: about 410
• Observed both on host and in a container, so this is likely not caused by container filesystem/runtime behavior.

Symptoms

Telegram /models can take around a minute before it replies.

Example from logs:

23:20:19 [telegram] Inbound message ... (6 chars)
23:21:21 [telegram] sendMessage ok ...

So the response took about 62 seconds.

The WebSocket/Gateway model list path is much faster. I saw browser/Gateway calls like models.list complete in under one second, so the slowdown does not seem to be caused by rendering 400 models or by Telegram send latency.

Measurements

Direct CLI:

openclaw --version      ~0.24s
openclaw help           ~0.30s
openclaw models list    ~15.2s

Direct module timing inside the same environment:

loadModelCatalog({ config })                  ~21s, 1364 catalog entries
loadModelCatalog({ config, readOnly: true })  ~34-190ms, 416 catalog entries, including the 410 LiteLLM models

With OPENCLAW_DEBUG_INGRESS_TIMING=1, the slow part appears before the catalog is actually read:

[model-catalog] stage=models-json-ready elapsedMs=19738
[model-catalog] stage=pi-sdk-imported elapsedMs=19769
[model-catalog] stage=catalog-deps-ready elapsedMs=19775
[model-catalog] stage=auth-storage-ready elapsedMs=20164
[model-catalog] stage=registry-ready elapsedMs=20183
[model-catalog] stage=registry-read elapsedMs=20186 entries=1353
[model-catalog] stage=complete elapsedMs=21369 entries=1364

The local models.json in the default agent dir was small and did not contain the 410 LiteLLM rows; it only had a few built-in/provider rows:

/root/.openclaw/agents/main/agent/models.json 109K
providers: litellm=1, xai=3, x-ai=3

Also, within one Node process, full catalog load is cached after the first call:

same-process-full 1 24540ms 1364
same-process-full 2 0ms     1364
same-process-full 3 0ms     1364

Read-only is fast from the start:

same-process-readonly 1 191ms 416
same-process-readonly 2 63ms  416
same-process-readonly 3 39ms  416

The auto-reply /models command path was slow when called directly:

/models                 ~69s
/models litellm         ~28s
/models list litellm    ~32s
/models list litellm all ~0.2s after the cache was warm

Current suspicion

The /models command path seems to use loadModelCatalog({ config }), which triggers ensureOpenClawModelsJson() and the full Pi/provider registry discovery path. For a read-only listing command, that looks much heavier than necessary, especially because the Gateway models.list path already has a fast read-only/timeout behavior.

Possibly /models should use a read-only catalog path, the Gateway catalog cache, or otherwise avoid refreshing/writing models.json on a simple browse/list command.

Again, I am not 100% certain this is the whole story, but the timing strongly suggests the full catalog/model-json refresh path is the bottleneck, not LiteLLM itself and not the number of models rendered.

Expected behavior

/models should respond quickly, roughly comparable to the Gateway models.list path, even when a LiteLLM provider exposes hundreds of models.