openclaw - 💡(How to fix) Fix Gateway startup warmup is slow for inline configured primary model [1 comments, 2 participants]

Summary

Gateway startup can spend ~45 seconds in prewarmConfiguredPrimaryModel() even when the primary model is already explicitly configured inline in openclaw.json under models.providers.<provider>.models[].

This was observed on a normal Linux/systemd user service, not Android/proot.

Related PR: #60027

Environment

• OpenClaw: 2026.4.26 (be8c246)
• Runtime: systemd user service
• Node: v22.21.1
• Primary model: openai-codex/gpt-5.5
• Config shape: openai-codex/gpt-5.5 is already declared inline in models.providers.openai-codex.models[] with provider/model API metadata

No secrets or API keys are needed to reproduce the shape of the issue.

What I measured

Using gateway startup tracing plus temporary local timing around sidecars.channels and prewarmConfiguredPrimaryModel():

So the slow part was not channel startup, TTS, memory, or markdown/workspace scanning. It was the eager primary-model warmup path.

Additional local tracing split resolveModel() further and showed the slow work came from provider/auth/catalog discovery and suppression/runtime hook paths, even though the selected primary model was already present inline in config.

Actual behavior

On startup, OpenClaw enters the PI primary-model warmup path and runs:

1. ensureOpenClawModelsJson(cfg, agentDir)
2. resolveModel(provider, model, agentDir, cfg, { skipProviderRuntimeHooks: true })

This can add tens of seconds to gateway startup even when the primary model could be resolved directly from inline models.providers config.

Expected behavior

If the resolved primary model is already explicitly declared inline under models.providers.<provider>.models[], startup should avoid the expensive eager registry/provider discovery pass when possible.

Runtime can still perform normal model resolution/validation on first use; this startup warmup already behaves as best-effort and logs warnings rather than failing startup.

Local workaround tested

I tested a local dist-only workaround that returns early from prewarmConfiguredPrimaryModel() when the resolved primary model is present in inline models.providers with explicit model/provider transport metadata (api/provider api/baseUrl).

Result:

CPU also settled normally after startup.

Possible fix directions

• Keep #60027's OPENCLAW_SKIP_MODEL_WARMUP as an explicit escape hatch.
• Also consider an automatic fast path in prewarmConfiguredPrimaryModel():
  • resolve configured primary provider/model;
  • if it is already available in inline models.providers.<provider>.models[] with enough transport metadata, skip the eager ensureOpenClawModelsJson() + registry discovery warmup;
  • preserve the current discovery behavior for providers/models that rely on dynamic provider catalogs.

This would avoid a repeated expensive discovery pass for fully configured primary models while keeping dynamic-provider startup behavior unchanged.